Problems with MAME (update: SOLVED)

| #books |

You might remember I’m writing an update to the NFG pixel art book. Remember, the one that’s selling on Amazon for seven thousand dollars? Ridiculous.

Anyway, I’m having trouble with MAME and I’m desperate for assistance.

UPDATE: The problem is known, according to a MAME developer. Details on the bug are here.

The problem: I’m getting stray pixels in screenshots. The three images below illustrate the problem.

The process: MAME 64-bit, version 0.152. Fresh install into an empty folder. Run the following command: mame64 sisv2 to launch a game of Space Invaders, and when the game starts, I press F12 for a screenshot. This is a crop of the resulting image:

Now that looks pretty good, until you try and remove the background (which I need to do a -lot- for the book). I use the magic wand tool to select all pixels of the same colour, in this case black (which is R0, G0, B0). This is what I get:

That’s… not quite right. It has avoided selecting some pixels around the invaders. If I now remove that black background, you can clearly see a lot of leftover pixels:

Now, in this case the pixels are all one above zero on each RGB channel: R1, B1, G1. In other games I get a different result, such as this screenshot from R-Type where the same process as above was repeated:

These pixels are one above zero in different channels.

Things I tried:
– Fresh install of MAME64
– Running in direct-draw mode (-video ddraw )

I have had someone in messdev send me a screenshot that was unmolested by these pixels, using the same version of mame, so it seems either unique to me, or it’s at least an uncommon problem. It’s causing me a significant amount of grief. I can’t count colours reliably (2nd comment below shows an example, and what is 108 unique colours in a RAINE screenshot is 366 colours in MAME).

If you can suggest anything, please do!

[ Mar 9 2014 ]



Mar 9 2014

Would it be easier just to remove them in post? An imagemagick script could replace black and almost black with transparent pretty easily.


Mar 9 2014

Yeah, but it’s not always black. Check out this selection made on the title screen of 1944 Loop Master:

The top one is from RAINE, the bottom from MAME. Notice how it’s failing to grab adjacent identical-looking pixels? They’re off by one too. They should be R154 G171 B188 but are instead R153 G171 B188. The blue channel is down by one. These two images count 10 colours (including black and white for the selection) in RAINE, and 20 colours in MAME.


Mar 9 2014

The other thing that makes this a problem is counting colours. The RAINE screenshot counts 108 colours, the MAME one is a ridiculous 366.


Mar 9 2014

The select by colour tool in GIMP allows you to set a threshold to pick up similar colours.

Still, it’s an intriguing effect. I would like to know what causes it. A sub-pixel anti-aliasing filter by your video driver perhaps?


Mar 10 2014

Yeah, I can adjust the tolerance too, but that runs the risk of selecting similar colours (even if the chance of that actually happening are close to zero), and still doesn’t solve my colour counting problem.

The screenshots should be saved before they’re filtered and drawn on the screen, it should be pure mame at this point. Nothing my system does should have any effect.

In theory. In reality, well, I’m the only one with the problem. Story of my life. =/


Mar 10 2014

MAME developer here, what you’re describing is a problem specific to 64-bit MAME builds, caused by a bug in some SSE2 code used (among other things) to generate screenshots. Solution is to use a 32-bit build to take screenshots for now. The bug has been fixed in current SVN and will be gone in 0.153, whenever that is released.


    Mar 10 2014

    That’s outstanding, Thanks AWJ. This one’s been bugging me for a very long time.

Got something to add?

Your Comment