![]() Because the wrong dsdx value a transparent pixel is displayed. Vertically, all 61 are meaningful pixels. Horizontally, 8 have meaningful pixels, 8 are transparent. These texrects drawn in 1cycle mode, thus fraction part must be used. ![]() N64 texrect does not use fractional part of dsdx/dtdy only in copy mode. I have read the documentation and tried many things, with no success whatsoever. There might be some condition under which the N64 ignores the dsdx, dtdy values given by the display list and uses 1. You may run software plugin under debugger and see how it renders these texrects. Probably, N64 hardware just skips texels if texture coordinate goes behind tile bounds. I tried to force texture clamp in my code, it does not help. Textures wrapped because texture coordinate slightly larger than necessary because of that bias above 1.0 in dsdx/dtdy. As you may see, the glitches are result of texture wrap. I'm afraid the problem is on hardware side. Thus, even if these values are wrong, N64 hardware can handle them correctly. However, I'm sure that software plugin gets the same values. I agree, the dsdx, dtdy values look suspicious. Software plugin renders this scene without glitches and hacks. I don't understand _getTexRectParams() What's your opinion on this regard? This would mean that the w2 and w3 are wrong, which I believe they come from the display list. For some reason the plugin has wrong dsdx, dtdy values.Unless this mask is specified by a register and be chosen by the game designer, it doesn't seem likely to be happening. However, paper mario needs at least the topmost 10 bits. use only the topmost 8 bits (s5.2 fixed point) and rest 0, to behave correctly. Those rectangles need a mask of 0xFF00, i.e. dsdx and dtdy might be supposed to be masked.There might be some condition under which the N64 ignores the dsdx, dtdy values given by the display list and uses 1.I have only seen this types on number for animations where a rectangle shrinks.Īs for why a N64 renders correctly, here are a few theories I can think of: Normally, a game designer would use integers or inverses of integers, so the value has a logical meaning (number of texture texel per number of screen pixel). I measured the dsdx and dtdy values in _TexRect(u32 w0, u32 w1, bool flip) in RDP.cpp. This makes me think that the problem lies with the texture mapping. The problematic textures are related to the text box (see first picture):Ģ - The big one in the middle, wrong color in the bottom.ģ - The small one on the right, the curve is slightly wrong.Ĥ - The triangular shaped one, the bottom is wrong.Īfter some testing, I noticed that if dsdx and dtdy are force to 1, the textures display correctly. GLideN64, with dsdx and dtdy values hacked. For additional information, read our data privacy statement.Ogre battle has a few texrects that are incorrectly displayed. This website collects basic user data to help improve the website. Most enemy unit, shop, and stronghold information was originally collected by CyricZ. Most neutral encounter information was originally collected by Red Maw. This map was ripped by Tropicon and originally uploaded to. Initial release: J| Last updated: July 23, 2022 ![]() ![]() Additional information will be added regularly. The Sleeping Goddess (Mount Keryoleth II) Gateway to Another World (Temple of Berthe II)
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |