![]() ![]() ![]() Even if you clamp in the right place, you wouldn't get round edges in texture 3 with dsdx, dtdy != 1. It also explains why clamping is not working: tiles have garbage data too. This strongly suggests that dsdx and dtdy 1 should be used. Vertically, 12 pixels are meaningful, 1 is transparent and 4 contain garbage. Wrong dsdx goes unnoticed because it writes a transparent pixel. Horizontally, it has 11 meaningful pixels, 1 transparent and 4 garbage. With wrong dtdy value, garbage is shown in the bottom. Vertically, 61 are meaningful and 3 contain garbage. Wrong dtdy goes unnoticed because it clamps (or interpolates only with last pixel). 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. Ogre battle has a few texrects that are incorrectly displayed. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |