| << Newer | Article #141 | Older >> |
Viva (Las) Vegas
Been taking another look at the Vegas drivers again now that the Voodoo 2 emulation is working. Gauntlet Legends was working again in 0.102u4, which is a good sign. A couple more fixes and Gauntlet Dark Legacy was working again — at least as well as it had been before, which is to say fine until you actually got in-game, at which point all the environment graphics were drawn all-black.
Looking into this problem a bit more revealed that the Dark Legacy engine had added light maps to the rendering, using a multiplication between two textures to produce the final result. The Voodoo rasterizers support this just fine, but what was new is that they were now using a new mode in the Voodoo 2 which specifically selects the texture color rather than a color computed through other means. Since this mode didn't exist in the original Voodoo, the code was just using '0' for this case and producing a black background. Adding support for this made the graphics appear. Yay!
Next task was to figure out why Tenth Degree no longer worked.
It used to, and I was sure it was due to the Voodoo rewrite. I spent quite a bit of time looking into that, assuming I was returning an incorrect value from the status register or something. Turns out I was completely wrong. Instead, an "optimization" I had made to the MIPS dynarec core a while back had a subtle side effect. The problem was literally with the particular opcode:
slti r2,r3,$1In the old dynarec core, that was translated as:
mov eax,[r3.lo]The optimization I added was to convert code that subtracted 1 from a register to use the dec opcode instead, since it is more compact. So the new code was::
mov edx,[r3.hi]
sub eax,1
sbb edx,0
shr edx,31
mov [r2.hi],0
mov [r2.lo],edx
mov eax,[r3.lo]which is 4 bytes smaller, taking up less instruction/trace cache space. Multiply this over a lot of generated code and it has an impact. The problem is that dec eax is not quite the same as sub eax,1. Specifically, dec does not set the carry flag, meaning that the sbb instruction that followed would never "borrow" from the high word, messing up the math.
mov edx,[r3.hi]
dec eax
sbb edx,0
shr edx,31
mov [r2.hi],0
mov [r2.lo],edx
So with that, Tenth Degree is working again, and better than ever. One thing I discovered in my recent research is that if certain values (red, green, blue, alpha, Z, and W) overflow during triangle rasterization, they are allowed to wrap in a slightly odd fashion. For example, if the red component increases from $FF to $100 to $101 over the course of several pixels, you would expect it to wrap from $FF to $00 to $01. But the internal microcode in the Voodoo actually checks explicitly for $100 and clamps it to $FF, while allowing $101 to wrap to $01. So what you actually get is a transition from $FF to $FF to $01.
Why is this important? Well, let's say you are drawing a triangle such that the leftmost pixel has a red value of 0.0 and the rightmost pixel has a red value of 1.0. Converting these values to integers between 0-255 means the left value is $00 and the right value is $100. If the Voodoo allowed simple wrapping, that last pixel would be drawn as $00, showing up as an ugly black pixel right next to a bright red one. The simple clamping logic allows for a bit of slop of 1 on either the high or low side without producing artifacts.
The upshot is that if you run an old build of MAME and look at Tenth Degree, you'll see lots of artifacts — unsightly black or white pixels that shouldn't be there. Implementing this clamping logic turns out to fix these problems. Mace: The Dark Age also suffered from the same problem to a lesser degree. I bet the Tenth Degree engine was based off of the Mace engine.