MAME WIP News

[olaf]

Emu#dreams reports that Olivier Galibert and Aaron Giles have made progress in developing for MAME, the "Multiple Arcade Machine Emulator". Below is a quote from Arbee's WIP Emporium about Olivier Galibert's WIP news.

 

This is not my WIP, this is courtesy of Olivier Galibert. He’s figured out the A-bus protection used by ST-V Radiant Silvergun. Now, Haze requires me to tell you before you get all excited that it’s unbelievably slow right now, on the order of 10 FPS on my fast P4 (that’s why I’m not showing much gameplay, no patience. It really is there though). Mariusz may be able to speed-cheat it into a more reasonable state or he may not. Stay tuned

 

UPDATE: Haze, who clearly doesn’t mind playing sub-10 FPS shooters, has posted several more screens.

Below is a quotation of Aaron Giles' work-in-progress news post.

 

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,$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

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

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.

You can visit Arbee's WIP Emporium here and Aaron Giles' Home Page here.

Edited December 22, 2005 by olaf

[Agozer]

UPDATE: Haze, who clearly doesn’t mind playing sub-10 FPS shooters, has posted several more screens.

Haha, best development-related quote so far.