Games
Problems with MAME (update: SOLVED)
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!
--NFG
[ Mar 9 2014 ]
Next Post | Navigation | Previous Post |
---|
Comments
NFG
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.
NFG
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.
abznak
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?
NFG
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. =/
AWJ
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.
NFG
Mar 10 2014
That’s outstanding, Thanks AWJ. This one’s been bugging me for a very long time.
Name:
Email:
Website:
abznak
Mar 9 2014