Upcoming work going into MAME 0.245

[cuavas]

MAME development is as vibrant as ever. Here is a sneak preview of some of the work going into MAME 0.245.

DarkSoft, TeamEurope and our very own @rb6502 have been working on getting some Sega medal games up and running. They seem to be somewhat over-provisioned with most of the Sega System 24 video hardware:

@cracyc has been working on the Compugraphics Powerview MCS 10:

[cuavas]

It hasn’t all hit master yet, but @MooglyGuy has been working on Konami’s Polygonet hardware. It’s talking to the DSP and showing something that approximates 3D graphics:

[cuavas]

With some fixes to the rasteriser emulation, it’s looking better again:

[cuavas]

@MooglyGuy writes:

Turns out that some debug code from when I was first getting the span draw-er up and running, which was only accepting spans that didn't exceed the presumed clipping range of the framebuffer viewport, was biting me in the ass. This looks a lot more like Polygonet Commanders.

Still some DSP bugs lurking - those bent triangles on the front of the first-person tank are pretty suspicious - but if I can get Thursday off in addition to Friday this week, I'd say we have a damn good chance of getting this sucker finalized for 0.245.

[cuavas]

@MooglyGuy writes:

This video represents the present state of Polygonet Commanders in my MAME source tree, and is (at a minimum) how the game will look in the upcoming release of MAME 0.245, assuming my pull request is approved.

One of the consistently irritating issues that I kept circling back to was the apparently "missing" portions of the player's tank during the very beginning of attract mode, as well as the base portions appearing in front of the doors as they open.

The hardware is both old enough and simple enough to obviously not support depth buffering: Although it was a concept which was known in the computer graphics field for at least a decade prior, the necessary bandwidth and RAM was still out of throwing range for even the custom sort of hardware that could be found in arcades during their heyday. Moreover, based on getting the on-screen 3D to draw at all, it was clear that Konami's custom chips are little more than accelerated span fillers: Which is to say, the DSP56156 manages transforming the 3D vertices to "screen-space" vertices, i.e., 2D coordinates. It then simply emits a set of start/end coordinates for horizontal lines that, when filled, will form a flat-shaded polygon. By the time the hardware even knows about the polygons, there's no such thing as depth.

Finally, out of desperation, I tried treating the framebuffers themselves as a very limited depth buffer: If a pixel has already been filled, don't allow any spans later in the list to overwrite it until an entirely new batch is being drawn.

It turns out that this was the key, and makes sense in retrospect. While it would be awkward in actual silicon to iterate to the end of the span list and then work backwards, it would be fairly trivial to have framebuffer writes use a read-modify-write cycle that aborts the "modify" and "write" portions if the framebuffer contains a non-zero value at that point.

While I was in there, I also worked to square up the size and position of the framebuffer relative to footage from real hardware, kindly provided by MAME developer Phil Bennett.

As far as I can ascertain, the only significant graphical issue is that some geometry continues to drop out, but I believe this is still due to lurking DSP56156 issues. After inserting a significant amount of debug-drawing code, it would appear that when the player's own tank body disappears, it simply is just not there in any of the span lists.

[cuavas]

As most of you are probably aware, two very rare games that didn’t see widespread release have turned up: the original arcade version of Megumi Rescue, and a location test version of Marble Madness II. @davidhaywood has added both of them to MAME:

[ghost]

https://youtu.be/9DheRtm1YOo

I've also been doing a lot of refactoring of the MPU4 driver. Adders and Ladders now seems to be playable with correct sounds. (It already had a layout, where all important lamps seem present, and isn't using a lamp extender board)

Note, the 'free game' feature might appear to do nothing, but in reality it paid out some coins directly rather than putting them in the 'bank'

[cuavas]

I got a Mac II, and a SuperMac Spectrum/8 Series III video card, but I could only afford the 16" 832×624 monitor:

Creative use of 1-bit video with 24-bit palette entries:

Nice, but it’s looking crowded already:

If only we could do something useful with all that expensive VRAM…

Hey, where did my hard disk icon go?

Oh, it’s over here:

It’s gonna be a long trip to the trash can!

Lots more real estate, even if you can’t see it all at once:

Maybe we want to take a closer look at Susan Kare’s artwork:

That’s hardware zoom – no copying from an off-screen buffer.

Off-centre alerts are disconcerting:

[cuavas]

SuperMac Spectrum PDQ blitter is working now, too.

Before:

After

[cuavas]

That “before” screenshot is a little unfair – it was actually usable with glitches at 1152 horizontal resolution:

[cuavas]

@davidhaywood writes:

This is one of the less common Plug and Play units Radica put out. It's actually a licensed / localized version of one of the Japanese units put out by Takara, which goes a long way to explaining the higher than usual presentation values. In terms of the games, they're aimed at a very young audience, pre-gamers really, hence the 'Jr.' in the title. In runs on hardware based around the XaviX 'System on a Chip' solution from SSD. It should be supported in MAME soon. Thanks to Sean Riddle for dumping it.