Voit lisätä twiitteihisi sijainnin, esimerkiksi kaupungin tai tarkemman paikan, verkosta ja kolmannen osapuolen sovellusten kautta. Halutessasi voit poistaa twiittisi sijaintihistorian myöhemmin. Lue lisää
This pear is the bane of my existence right now. Come, rubber-duck with me. For openers, I've added logging code to MAME, and created an offline viewer for those logs. One rather useful feature is that I can have it log commands that hit a specific pixel. (cont'd)pic.twitter.com/QMe0p6OuWv
In this case, the pear is drawn in 4bpp RGB mode, rather than using indexed color. In 4bpp RGB mode, an 8:8:8 shading value is dithered down to 1:2:1. Drilling down to one of the affected patches of bad color, we see an RGB triad of 0x64, 0x70, 0x0A. (cont'd)
Per the REX3 documentation, an 8-bit channel P[7:0] is dithered down to a 1-bit channel as follows: 1. S = P[7:3] - P[7:4] 2. if (S[3:0] > Bayer[x,y]) then D = S[4] + 1 else D = S[4] (cont'd)
Similarly, the 2bpp dither is: 1. S = P[7:2] - P[7:4] 2. if (S[3:0] > Bayer[x,y]) then D = S[5:4] + 1 else D = S[5:4] Okay, straightforward enough. Tough to get wrong. The problem is that after dithering to 1:2:1, we get RGB values of 0,1,0. Green, not yellow. (cont'd)
As far as I can tell at this point, the handling of the rendering itself is spot-on. About the one thing that I haven't ruled out is some sort of issue with the emulation of the R4600's FPU, which somehow affects only the software Z-buffering. (cont'd)
That's about the only guess that I really have. A CPU core emulation bug. Presumably, the affected patches of geometry are actually the back faces of the pear showing through. This would also explain the non-Z-buffered appearance of models in the "Powerflip" utility. (cont'd)
So, the real fun now is going to be to narrow down exactly what the affected FPU opcode *is*. The best I can do at this point is add some logging which can be toggled on in the MAME debugger, then enable logging only when the model redraws. Fingers crossed, ay?
Well, we've got a *fairly* short list of FPU ops that are hit during a redraw. In no particular order: MUL.S/D, ADD.S/D, NEG.S/D, SUB.S/D, DIV.S/D, ABS.S/D, MOV.S/D, TRUNC.W.S, C.EQ.S, C .LT.S/D, CVT.D.S, C.EQ.D, CVT.S.D, C.LE.S/D, CVT.W.S/D, C.OLT.S, and C.UN.D.
By pure principle we can rule out the major arithmetic operations as being faulty, as the pear would likely not be remotely correct. It's unlikely that the CVT (Convert) opcodes are faulty, for similar reasons. Perhaps something is amiss with the compare instructions.
Ooh, that would be super useful for N64 pixel pipeline debugging
Twitter saattaa olla ruuhkautunut tai ongelma on muuten hetkellinen. Yritä uudelleen tai käy Twitterin tilasivulla saadaksesi lisätietoja.
