Catalogue of Arcade Emulation Software - the Absolute Reference

Valid XHTML 1.0! Valid CSS!



Large CAESAR Logo

Tenth Degree (prototype)

0.91u1 [Aaron Giles]

HardDisk required


- 0.103: Fixed number of players and added 'Unknown0080' dipswitch.

- 0.102u5: Aaron Giles fixed subtle bug in the MIPS3 recompiler that prevented Tenth Degree from working.

- 21st December 2005: Aaron Giles - 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,$1. In the old dynarec core, that was translated as: mov eax,[r3.lo]; mov edx,[r3.hi]; sub eax,1; sbb edx,0; shr edx,31; mov [r2.hi],0 and mov [r2.lo],edx. 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 eax,[r3.lo]; mov edx,[r3.hi]; dec eax; sbb edx,0; shr edx,31; mov [r2.hi],0 and mov [r2.lo],edx. 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. 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.

Romset: 544 kb / 3 files / 3.29 zip

Harddisk: 3074.9 MB (Heads: 255, Cylinders: 392, Sectors: 63 - Compressed: 735.8)