Tried something crazy and it actualy worked.(Read)

[Howard_Casto]

Been thinking about the whole output problem in mame again, namely there isn't any way to control lights, displays ect from within mame.  I'm not talking about your lighted buttons on your control panel, I'm talking real hardware that was on real arcade machines (gorf rank lights, turbo's segmented displays, ect...)

Anyway.....


The new artwork system that Aaron made for mame is pretty powerful, and he just happened to update the turbo bezel, which has segmented displays and a 9-led "speedometer" so......

I made a new layout file that makes the speedometer section 1 pixel by 1 pixel at the very top-left hand corner of the screen.  I changed the 10 png images to single pixel swatches, with each png having a color value matching the speed displayed (0 is rgb(0,0,0) 1 is rgb(1,1,1) ect...)

Then I setup an external app that gets the pixel value of mame at 0,0 at 60 fps.  To my suprise I could accurately determine the speed of the car through my app!  What this means is with a bit of work, any light hooked up in mame's artwork system can be controlled externally.  The data can be sent to an ledwiz, the parallel port, ect.  These external scoreboards could also be re-created in the external app and displayed on a secondary screen.  Basically it makes the data available, and what you want to do with it is up to you.

Before you get all excited though:

There are some severe limitations to this method though. 

1.  Mame's screen brightness must be left at 1, or else all the pixels are tinted. 

2.  The game can't be ran at a resolution lower than the games native resolution.  This makes sense as a 1 by 1 pixel element can't be squashed any smaller.

3. Whenever you pause, obviously the readout is going to change as the screen will get darker. 

4.  The screen aspect of you monitor, the running resolution and the aspect and resolution of the game as well as orientation must be known by the app.  When a game is rotated 90 degrees, it's top left hand corner suddenly becomes it's top right.  And the position of multiple pixels for games with complex lights(like turbo which has a speedometer, a 7 segment score display and 4- 7 segment hi score displays) will have to be scaled based on the monitor resolution.  Vertical games shown on a horizontal monitor actually place a element assignd to 0,0 at the corner of the game play area, not your monitor, so a lot of calculations would be required to get this to work universally. 

5.  The "artwork"you've created to track the changes must be visible.  This isn't as big a deal as it sounds.  You can either make a 1 pixel black border around the screen, or move the art into an area of the screen that is always black.  As long as the values you are tracking don't get larger than 20 per element, you can easily use those rgb values and they will appear black to the naked eye. 


6.  This isn't going to be very responsive on a "puny"system.  Of course a puny system isn't going to have an led-wiz or tons of optional hardware hooked to it, so this shoudln't be an issue. 

7.  Oh and d3d only.  The new artwork system doesn't really work well with directdraw. 


Anyway, that's what I found out.... questions, comments ect are appreciated. 

[mahuti]

Pretty cool. I haven't even been keeping up enough with MAME to know about the new artwork system at all.

[headkaze]

Interesting concept, but not really a practical solution. Like you point out in the "memory sniping" thread regarding screen captures with Mame, due to stretching, rotation etc. you have no way to get a proper reading for all setups. And capturing at 60fps would create a slow down too much to be worth it. But it's cool that your experimenting and trying different things. It would be better if Mame has some sort of built in API that allowed external applications to interface with it.

[Space Fractal]

would be better if Mame has some sort of built in API that allowed external applications to interface with it.

This could been do it on the windows title name. Even it hidden, it pretty easy to get the info of it. This would override all limts, Coward as wrote.

The layout source code may so need to been changed, so it can been used it way. This could been a job to add into Powermame?

[Howard_Casto]

Interesting concept, but not really a practical solution. Like you point out in the "memory sniping" thread regarding screen captures with Mame, due to stretching, rotation etc. you have no way to get a proper reading for all setups. And capturing at 60fps would create a slow down too much to be worth it. But it's cool that your experimenting and trying different things. It would be better if Mame has some sort of built in API that allowed external applications to interface with it.

Actually none of that is an issue..... if a proper ini file was written for each game it's very easy to calculate the position of each pixel even when rotated.  And scaling is easy... as a matter of fact you can still do artwork files in percentage of the screen so the external app can simply read the layout file.   There's no slow down on any modern machine I've tried.  Remember, I'm not capturing the entire screen, just selected pixels of the screen.  Even complicated games like turbo only have 30 values to keep track of, meaning only 30 pixels have to be read.  Most games have 6 or less, which is nothing, even on a modest pc.  But let's say for the sake of argument that it did hinder performance.   The games that use lights generally aren't 1999 titles, rather 1984 ones.  It doesn't take a whole lotof horsepower to run pacman or digdug.  The only exception beign gorf, which uses samples and thus takes a bit of resources. What is an issue is the "effect" flag.  Luckily this can also be worked around as the new aw system allows you to point effect to an actual png file.  Just make the left hand pixel row of the png clear (white) and you are good to go.   

The reason I'm doing this is because mame is never going to have this api you speak of, at least not anytime soon.  Aaron would be the guy to do it and while he's open to the idea he doesn't seem to have much interest in it.  Anyone else you attempted to include it (myself included) would probably screw it up because several global changes to the mame core would be needed. 

What Space Fractal said is more realistic though.  If we could convince the devs to allow "broadcasting" (sending data by adding it to mame's capiton) then it could be retrieved just as easily. 

Power mame or any custom build isn't a solution though, rather a stop-gap.  Even with the best of intentions, most of these custom mame builds are either seldom updated or abandoned.  Powermame is already suffering a tad bit of neglect, which is understandable considering one guy is maintaining the whole build.