Proof-of-concept of Howard's idea

[Buddabing]

Hello,

I took the liberty of implementing part of Howard's idea of displaying a picture of the controls.

It's pretty rough, but you should get some picture of the process.

Here is a URL to the zip file containing the demo:

(EDIT: removed URL since the demo is no longer there)

The picture is set to display whenever pause is pressed. You'll need to extract the controls.art and the tiny.exe into the mame root directory, and extract the controls.png into the gorf subdirectory of the artwork directory.

Then run "tiny gorf".

Regards,
Buddabing

[Lilwolf]

does this create the image with updated controls?  or does this allow you to load an image in mame when paused (or both?)

And COOL!  (at work...cant test it right now:) )

[Buddabing]

does this create the image with updated controls?  or does this allow you to load an image in mame when paused (or both?)

And COOL!  (at work...cant test it right now:) )

All it does is displayed a canned image on top of the artwork when pause is pressed. Creating the image with the updated controls comes later.

[Howard_Casto]

i appreciate the effort, but I'm not sure this is proof of concept because:  

1.  Gorf is in black and white now.  

2.  The Image isn't displayed in the right orientation.  


Still, very good work.  

As you are seeing though, deailing with the artwork functions is far more complicated than it appears at first glance, that's why I said I would probably need a lot of help to get it running properly.  

[Buddabing]

I just hacked this together to demonstrate the concept. When I have the bugs out, I'll release the source code and we'll try to make it so that the picture is generated on the fly instead of loaded from a static png file.

[Howard_Casto]

Cool.....


It's possible since mame can externally launch other applications (chdman, xml2info).  Also it can't be easier since mame puts itself in the foreground the viewer can simply run underneath for a second, generate the image and then exit itself out.  

Also your approach to have an individual image for each game isn't necessary.  I can program the viewer to simply overwrite "controls.png" or whatever upon each pause.  It'd be a tad slower for showing the image, but it would probably be less coding on each end.  

[Tiger-Heli]

I just hacked this together to demonstrate the concept. When I have the bugs out, I'll release the source code and we'll try to make it so that the picture is generated on the fly instead of loaded from a static png file.

I just tried this out.  I was skeptical reading Howard's thread, but I REALLY like this idea now.  If this were like the output from Johnny5, it would be really cool.

Related ideas - Right now, I have the option to display Johnny5 output in MameWah prior to launching a game or in EmuLoader as a CP image after converting to a .jpg.

This has an advantage over either method:

EL - I might not want to scroll through the images to the CP layouts prior to playing the games.

MameWah - I might not want this for all games.  I can figure out how to play PacMan.  I would know how to play Tiger-Heli, but guests might not, so this would be helpful for this in that it pops up for games that I want it and doesn't pop up for games that I don't want it for.

One thing to watch out for - the image would need to be a specific size for this to work.  I found out with EmuLoader, if I use the Lanczos filter EL will scale the images nicely.  Otherwise, the text tends to get blocky/blotched.

Also, it would be nice if this could somehow be launched independently of MAME so it could work with other emulators and/or older MAME versions.

[Buddabing]

I made a couple of changes. It turns out that the game will display in black and white if the controls artwork is defined in the artwork layer, but will display okay if it is defined in the bezel layer. Also, MAME expects artwork to be rotated 90 degrees clockwise(see png files for gorf), so I rotated my default image and it is now displayed okay.

I uploaded the results to the same URL as before.

I would like the images to be generated offline. Given a choice, I feel it is almost always better to spend a little extra time on a project to get it to run faster. Someone can write a utility to generate the controls.png files and delete the unwanted ones. That way we satisfy Tiger-Heli's request for only selected games to have images.

Tiger-Heli, the problem with having this be emulator-independent is that this solution hacks into MAME's artwork display code, and therefore is not emulator-independent.

Another big problem is that this hack depends on changing a few lines within MAME, and thus won't be incorporated into new versions of MAME. Too bad TheGatesOfBill has stopped maintaining NoNameMAME, that would be ideal.

Tonight I'll do a general compile and I'll see if it runs with other games, especially ones without bezels and artwork. I'll also check out making the control popup independent of pause.

[Tiger-Heli]

I uploaded the results to the same URL as before.

Haven't tried the new image yet.

I would like the images to be generated offline. Given a choice, I feel it is almost always better to spend a little extra time on a project to get it to run faster.

Makes sense - Could be tough to keep up with, though.

Someone can write a utility to generate the controls.png files and delete the unwanted ones. That way we satisfy Tiger-Heli's request for only selected games to have images.

Actually, that was my request with the other options.  If the controls only pop up when I pause a game, then it would be good for all games to get this.

Tiger-Heli, the problem with having this be emulator-independent is that this solution hacks into MAME's artwork display code, and therefore is not emulator-independent.

I know it does now, but it might not have to.  Write the app into a frontend so when I am runnining blstroid and press P it displays C:\layouts\blstroid.jpg, for example.

Another big problem is that this hack depends on changing a few lines within MAME, and thus won't be incorporated into new versions of MAME. Too bad TheGatesOfBill has stopped maintaining NoNameMAME, that would be ideal.

Unless the devs agree to adopt it, or you make a .diff file so any later MAME can use it.

Tonight I'll do a general compile and I'll see if it runs with other games, especially ones without bezels and artwork. I'll also check out making the control popup independent of pause.

Actually, having it popup with Pause is the thing I likes, unless you just mean having a different key to make it pop-up.

[Howard_Casto]

Offline generation is a super bad idea the more I look into it.  The problem being if a game is updated in the latest build of the dat you might not generate.  It takes 5 secs tops to generate a image from the viewer.  If you don't have that much patience then I worry about you.   So generating the image from the viewer on the fly would be no problem.  

On the other hand 5 secs x1800 could take a while. (150 minutes)  5 secs x 4500 would take forever.  (375 minutes)  Now keep in mind if you wanted to keep the images accurate you'd have to completely regenerate the set with every dat revision.  That is the speed issue I was concerned about.  

Also we've run into another issue.  Although I could probably write code to rotate the image, I have no way of knowing which games need the image rotated.  So mame would have to rotate it, not the other way around.  It shouldn't be hard to determine from within mame....  Simpy match the aspect to the screen aspect, if it doesn't match rotate.  Or you could even automatically flip vertical games without the check.  

And finally tiger is right.  Having a small image that takes up only a portion of the screen is not an option. On an arcade monitor or tv the only way to actually read the text is to have a fullscreen image.  I didn't mention it before because you had other issues to work out, but since it was brought up.

[SirPoonga]

Also we've run into another issue.  Although I could probably write code to rotate the image, I have no way of knowing which games need the image rotated.  So mame would have to rotate it, not the other way around.  It shouldn't be hard to determine from within mame....  Simpy match the aspect to the screen aspect, if it doesn't match rotate.  Or you could even automatically flip vertical games without the check.  

It's easier than that   mame has a flag you can look at.  Going to use that in my next revision of artwork fill edges.

[Tiger-Heli]

. . .  in my next revision of artwork fill edges.

Any ETA on that???

[Lilwolf]

It shouldn't take that long to create an image.  I think.

don't you all want to do this.  Create a snapshot of your OWN control panel.  Mark the areas on the image that is for button 1 and joystick one...  Then paste text over the real image?  I thought that is what you where doing this for...  So the image is how to run the game on YOUR control panel.. not the original.

Or am I wrong one what you guys are trying to accomplish?

[Buddabing]

It shouldn't take that long to create an image.  I think.

don't you all want to do this.  Create a snapshot of your OWN control panel.  Mark the areas on the image that is for button 1 and joystick one...  Then paste text over the real image?  I thought that is what you where doing this for...  So the image is how to run the game on YOUR control panel.. not the original.

Or am I wrong one what you guys are trying to accomplish?

You are correct. IMO the image creation process is the hard part of this project, the display part is pretty easy.

[Tiger-Heli]

It shouldn't take that long to create an image.  I think.

don't you all want to do this.  Create a snapshot of your OWN control panel.  Mark the areas on the image that is for button 1 and joystick one...  Then paste text over the real image?  I thought that is what you where doing this for...  So the image is how to run the game on YOUR control panel.. not the original.

Or am I wrong one what you guys are trying to accomplish?

Lilwolf, there are about 3 projects going on -

Project 1 - Displaying button text over a real image of your control panel (like you mentioned).  This is Johnny5.exe from http://fe.donkeyfly.com/yabbse/index.php?board=10 - works fine in Win2k or XP, but only with certain frontends or outside of MAME.

Project 2 - This thread is about trying to display the output of Johnny5 in MAME, either from the Pause Menu, Tab Menu, or a dedicated key.  See also - http://www.arcadecontrols.org/yabbse/index.php?board=3;action=display;threadid=21830 REASON: Johnny5.exe is great, but if you bypass it or forget what the button assignments are (alcohol reduces attention span, etc.), it's a pain to quit the game to figure out what buttons to press.

Project 3 - I wanted to use the output of Johnny5.exe in EmuLoader, which doesn't support it, but I found out I can run Johnny5 full-screen, take a snapshot of it, and save it as a file that EmuLoader can view.  So there is debate over whether any of these options should generate dynamically or use canned snapshots.

Pros - Canned snapshots are faster, easier to implement, and supported by almost all applications.

Cons - Dynamic generation will automatically display the latest info if either a) Controls.ini is revised to add new information b) MAME is updated to change the inputs for a particular game, or c) the user updates the ctrl.ini file for a particular game.

Answering your initial question:  HC has stated that generating an image takes about 5 seconds tops and that seems pretty consistent with what I was noticing with Johnny5.exe.

My thoughts:  It would not bother me if I hit Pause in MAME (or a dedicated button) and after 5 seconds the controls graphic displayed.  It WOULD bother me if I always had to wait 5 seconds before starting a game for the graphic to display, or wait 5 seconds in my front-end to find out what the applicable controls are, but then agian, I disable ALL the nag screens and thought -skip_startup_frames was a great feature too, so . . .

[Buddabing]

Offline generation is a super bad idea the more I look into it.  The problem being if a game is updated in the latest build of the dat you might not generate.  It takes 5 secs tops to generate a image from the viewer.  If you don't have that much patience then I worry about you.   So generating the image from the viewer on the fly would be no problem.  

On the other hand 5 secs x1800 could take a while. (150 minutes)  5 secs x 4500 would take forever.  (375 minutes)  Now keep in mind if you wanted to keep the images accurate you'd have to completely regenerate the set with every dat revision.  That is the speed issue I was concerned about.  

Also we've run into another issue.  Although I could probably write code to rotate the image, I have no way of knowing which games need the image rotated.  So mame would have to rotate it, not the other way around.  It shouldn't be hard to determine from within mame....  Simpy match the aspect to the screen aspect, if it doesn't match rotate.  Or you could even automatically flip vertical games without the check.  

Due to this issue, I guess it is necessary to rotate the image within mame. For cross-platform compatibility, the image generation should be within MAME anyway. There is already code to generate png files. (screenshots)

And finally tiger is right.  Having a small image that takes up only a portion of the screen is not an option. On an arcade monitor or tv the only way to actually read the text is to have a fullscreen image.  I didn't mention it before because you had other issues to work out, but since it was brought up.

The controls.art file specifies how much of the screen the controls.png file occupies. MAME automatically stretches the image to fit the screen. So, if the image is created with a decent resolution, there won't be any problem displaying it on a large area of the screen.

[Tiger-Heli]

Also we've run into another issue.  Although I could probably write code to rotate the image, I have no way of knowing which games need the image rotated.  So mame would have to rotate it, not the other way around.  It shouldn't be hard to determine from within mame....  Simpy match the aspect to the screen aspect, if it doesn't match rotate.  Or you could even automatically flip vertical games without the check.  

This may or may not be a problem.  I know there are Vertical format games with the artwork rotated horizontally to the right (1943, etc), not rotated (clowns, astdelux, omegrace) and rotated to the left (pacman) and they all work, probably based on the .art file values.  I don't know how much of a problem it would be to have the controls layer rotated differently than the other art, but likely not much.

The controls.art file specifies how much of the screen the controls.png file occupies. MAME automatically stretches the image to fit the screen. So, if the image is created with a decent resolution, there won't be any problem displaying it on a large area of the screen.

Stretching an art image is not a big deal, stretching a text image might be (Try reading the text on the bezel artwork when it is displayed in MAME).  My point is EmuLoader does this well with the Lanczos filter turned on (I can take a -1024x768 screenshot and view it in a -600x480 window and it still looks good.).  However, neither EL without the filter nor Irfanview do a good job of resizing the image without the text getting blocky.  Johnny5 does resize well if I specify a different output size.

[Buddabing]

I've uploaded the source code to the changes I made to MAME in order to display controls.png whenever pause is pressed.

EDIT: removed dead link

I put in a hook so that you guys can work on creating the content. Whenever a game is launched, the batch file "makectrl.bat" is called if there is a subdirectory with the same name as the game in the artwork directory and if there is a valid controls.art file in the game name subdirectory. So if your MAME executable is in c:\emulators\mame and you want to create a controls.png file for joust, you should extract the makectrl.bat, the y.txt file, the controls.art file, and the controls.png file to c:\emulators\mame, you need to create directory c:\emulators\mame\artwork\joust, and copy the default controls.art file into c:\emulators\mame\artwork\joust. In this example, you can access the name "joust" via the %1 parameter to the batch file.

I'm not the toastmaster general so if the previous paragraph was as clear as mud to you, please ask for clarification.  

I'm aware of the potential problem regarding the rotation of the artwork. That will be addressed in a future release.

I will be out of town until Sunday the 25th attending my 20 year high school reunion, so you may or may not hear back from me before then.

Regards,
Buddabing

[Howard_Casto]

An update on my end of things:

I added a -justprint tag to the viewer.  Basically what this does is launches the viewer as normal and as soon as the entry is parsed it is saved to the root of the viewer folder as "controls.png"  

(it's not actually a png, but a bitmap atm..... i'll get around to fixing that eventually, but mame should read either one just fine if it's using the pnglib.)  


Also atm this only works in 2000/xp as the printwindow api doesn't work in 9x.  I need a developer to point me to a plugin or some code that will allow me to print a window in any os.  Before you ask blitting won't work, nor will print screen, nor will saving the "image" of the form.  Natively vb won't print labels and since the viewer is basically an array of labels this poses a problem.  print screen works but the window has to be on top.... since the viewer will never be on top this will never work.   (Hmm, maybe i could blit the label from a text box to the background.... I'll try it)


Also a suggestion:

You could modify the way you are using the artwork file to have the same controls.png be used as a transparency mask with a color key of magenta (rgb 255,0,255)  This way if people want the image to be displayed normally then no problem, but if they wish to make part of it transparent (like the background)  They can just make a layout file that uses a background image with magenta portions and launch it from j5 using the command "-lof translayout.lof"  Then poof!  only the buttons and captions are visible on top of the paused image of the screen!


I haven't tested this new src change yet.  I'll have to download the latest src of mame and complie it tonight.  As I am the only one with both parts of the puzzle (the viewer that prints and the mame mod) I guess it is resting on me for a few days.  


One more question.  What is the y.txt for?

Fantastic work btw, I'm sure glad someone else is figuring this out.  

[Lilwolf]

I know I'm asking stupid question in a real conversation..... but...

whats the chance that you want to do the work 100% in mame?

How hard is it to display the text in mame OVER a pasted image?

So what is created is a conversion of information from the controls.dat into an easier to parse singleton for the current game... And another file that has the x/y location for each button/joystick label?

So in the end, whats generated for each game is text (much faster) and the logic is then added directly after mame.

Seems like it would be a better solution to me if possible.  Especially since Howard doesn't have easy access to writing text in a generic fashion.  (one think I love about Java is creating images is done like displaying to the screen.  Same commands to a different graphic.  Too bad loading a JVM sucks for middleware pieces.)

[Howard_Casto]

I know I'm asking stupid question in a real conversation..... but...

whats the chance that you want to do the work 100% in mame?

How hard is it to display the text in mame OVER a pasted image?

So what is created is a conversion of information from the controls.dat into an easier to parse singleton for the current game... And another file that has the x/y location for each button/joystick label?

So in the end, whats generated for each game is text (much faster) and the logic is then added directly after mame.

Seems like it would be a better solution to me if possible.  Especially since Howard doesn't have easy access to writing text in a generic fashion.  (one think I love about Java is creating images is done like displaying to the screen.  Same commands to a different graphic.  Too bad loading a JVM sucks for middleware pieces.)

To answer a long question with a short answer.  Hell no!  

Believe it or not the humble little controls viewer is the most complex application i've ever written.  Ctrlr files are hard to parse and on top of that, once they are loaded into mame there is no way of accessing them again.  (I guess it's set and forget)  Also mame's text is blocky, ugly, and one size.  Varible sized, smooth scaling text is required to fit all of the data on the screen and actually have it readable on a tv or arcade monitor.  All of those things are easy to do outside of mame, but insainly difficult inside of mame.  Also you'd have to hack mame to support lof files for the skinning of the layout.  That would be hard, and unnecessarily polluting to the mame core imho.  

People seem to think mame is good with text and images just because it's seen in their favorite games.  Mame is good at the raw output of various sprites and that's about it.  So stuff generated on the fly is pretty much impossible in mame.  

[Howard_Casto]

Ok getting back on topic (sorry lilwolf)  

I got everything rigged up last night and it does indeed work.  But for it to be user friendly, Buddabing, I think you are going to have to change things around a tad on your end.  (The modifications that are requred on my end are almost complete in case anyone is wondering)  

Right now I modify your bat fle to launch the viewer and generate the appropriate image, saving it to the base of the viewer's folder.  Then I copy it into the folder using the part of the bat you made.  Now this works great but some of your choices are questionable.  

For one a folder has to be made for the game before it'll work.  Why would a person need that if the image is always gonna be controls.png generated by the viewer?  I suggest simply reading from the generic "default" or "mame" folder for each game.  The viewer will generate a "not found" image if the game doesn't have an entry anyway, so it would always work.  I know you mentioned you did it so that usesrs could choose which games they wanted to use it on but that would be better achieved with a simple "-[no]use_viewer_image" tag added to mame.  Since tags can be defined in ini files too (game specific i should say)  The user would still have full control over what games to use the viewer with.    

Also I'm not particularly found of the default layout you made, but that is completely editable in the art file so I won't complain.  


One last minor thing...... for the viewer to generate the most accurate layout it also needs the cloneof entry from mame. Would it be possible to add that to the bat as %2?  I can do it on the viewer end, but that would require generating a listxml file, converting it to listinfo and parsing the game.  Needless to say it'd add to the generation time.


Anyway keep up the good work!

I'd post a screenshot, but it's not all that impressive.  If your artwork resolution is set to high it looks exactly like a screenshot of the viewer on top of mame.  Which is a GOOD thing as that is what we want.  

[Paul Olson]

OK, I know absolutely nothing about writing code, so this may be a stupid idea.
I think that this is begging to work with (or like) the new IPAC software.  It is easy to set up the controls to look like your panel, and they can be tagged by imput and name.  

Paul

[SirPoonga]

Yeah, you can do that with HowardC's viewer AND if you use ctrlr files to define your control input.

[Howard_Casto]

Basically that's the whole point of the viewer.  

[Tiger-Heli]

Sounds good so far, I don't understand code, so these comments are from a user's perspective.

For one a folder has to be made for the game before it'll work.  Why would a person need that if the image is always gonna be controls.png generated by the viewer?  I suggest simply reading from the generic "default" or "mame" folder for each game.  The viewer will generate a "not found" image if the game doesn't have an entry anyway, so it would always work.

Agreed, I wasn't happy with the prospect of having to create 4700 folders for layout images.

As an option - could you maybe generate the image in the viewer's folder and have a new mame.ini option to tell MAME where the viewer is installed.

Otherwise Howard's suggestion seems like a good one.

 I know you mentioned you did it so that usesrs could choose which games they wanted to use it on but that would be better achieved with a simple "-[no]use_viewer_image" tag added to mame.  Since tags can be defined in ini files too (game specific i should say)  The user would still have full control over what games to use the viewer with.

Agreed, this would be a better solution.    

Would it be I'd post  screenshot, but it's not all that impressive.  If your artwork resolution is set to high it looks exactly like a screenshot of the viewer on top of mame.  Which is a GOOD thing as that is what we want.  

Quick suggestion - Would it be possible to change MAME to have a value for Viewer image resolution separate from artwork resolution, or always have the viewer resolution set to high separate from artwork resolution.

High bezel resolution makes a pretty big performance hit on some games on my XP 2800 Barton system, and I wouldn't want all games to use it, but if the performance wasn't as good when the game was paused, what would I care.

Final thought:  It might be good to have the mame part of the viewer have an option where the user could just use a canned image rather than launching the viewer.  (Although this is mainly based on the released version of Johnny not being able to handle game-specific .lof files, and since I think the unreleased WIP version handles this, maybe it's not necessary).

Canned images would also be useful for users wanting to view layouts in DOS or if the new viewer can't be compatible with Win98, as the user could create a bunch of .png images in a layouts folder (running the viewer under XP on a desktop system, for example) and then use the new code to display them in MAME.

Another usage for canned images - If I want information on the image which is not currently in controls.ini

[Lilwolf]

To finish off the subtopic...

Howard, I see your point with mames text sucking...

but other then that I don't see your point at all..  I was thinking of something like this.

file that doesn't change

joystick1_label = .23, .13   // for 23% on the x axis, and .13% of the y axis.
button1_label - xxx

so one time you define where each label will be displayed.

Then you create a new file for each game run... So it is just one game... easy to decode

joystick1_label = Player 1
button1_label = Fire

So all the logic mame would do is draw the image... and draw two pieces of text.

Of course... since mames fonts stink... The whole idea is useful...

[SirPoonga]

Does it have to be an image?  I've been thinking more along the lines of a text summary like history.day does.  It would be scrollable and such.

Ok, have you seen the report output for controls.dat
http://fe.donkeyfly.com/controls/report.php?theGame=mk
Almost everything above "Player 1:" you don't need to display, you can get that info inside the mame menus.  You do need MiscDetails.  Otherwise the rest could be summed up with text.

Does this not tell you what you need to know:

8-way Joystick
P1_BUTTON1=High Punch
P1_BUTTON2=Block
P1_BUTTON3=High Kick
P1_BUTTON4=Low Punch
P1_BUTTON5=Low Kick
P1_JOYSTICK_UP=Jump
P1_JOYSTICK_DOWN=Duck
P1_JOYSTICK_LEFT=Move Left
P1_JOYSTICK_RIGHT=Move Right

See, I still think the control panel image is a good idea, but in the frontend.  In the game you just need a reminder.

[Tiger-Heli]

Does this not tell you what you need to know:
8-way Joystick
P1_BUTTON1=High Punch
P1_BUTTON2=Block
P1_BUTTON3=High Kick
P1_BUTTON4=Low Punch
P1_BUTTON5=Low Kick
P1_JOYSTICK_UP=Jump
P1_JOYSTICK_DOWN=Duck
P1_JOYSTICK_LEFT=Move Left
P1_JOYSTICK_RIGHT=Move Right

No, it doesn't tell me what button on the CP is P1_BUTTON1

See, I still think the control panel image is a good idea, but in the frontend.  In the game you just need a reminder.

I disagree - in the Front-end, it requires an extra step before launching the game to view the controls, once the game is launched, I would have to exit back to the front-end if I forgot to check the button assignments.  I would much prefer to be able to pause the game and have the CP image and button assignments pop up.

[SirPoonga]

Does this not tell you what you need to know:
8-way Joystick
P1_BUTTON1=High Punch
P1_BUTTON2=Block
P1_BUTTON3=High Kick
P1_BUTTON4=Low Punch
P1_BUTTON5=Low Kick
P1_JOYSTICK_UP=Jump
P1_JOYSTICK_DOWN=Duck
P1_JOYSTICK_LEFT=Move Left
P1_JOYSTICK_RIGHT=Move Right

No, it doesn't tell me what button on the CP is P1_BUTTON1

See, I still think the control panel image is a good idea, but in the frontend.  In the game you just need a reminder.

I disagree - in the Front-end, it requires an extra step before launching the game to view the controls, once the game is launched, I would have to exit back to the front-end if I forgot to check the button assignments.  I would much prefer to be able to pause the game and have the CP image and button assignments pop up.

Take the two ideas in context with each other.  You would know what player 1 button 1 is on your ocntrol panel if the FE displayed the info before you started the game, and well, you built the cabinet

With the second part it would not be an extra step.  RIGHT NOW it is because the the only thing you have is the Johnny5 viewer.  But whatif FE devs started putting the control information directly into the FE?  Again, all you would need in mame is just a reminder.

My FE I am going to make for cabinet is just going to have icons of the controls used then the button labels listed (the buttons on the control panel will have 1, 2, 3, 4, 5,6 labelled)  So I will know before I start the game.  
Even if they weren't labelled you'd still probably know what button is button 1.

[Howard_Casto]

Sirp I'm disappointed in you, you should know the answer to why text-only output is useless.  

Button re-assignments!

Your button layout for mk2 is different than your layout for street fighter, or neogeo, ect.  How is a pos text file supposed to show you that?

If you re-define all of your keys via ctrlr files then the viewer shows each label on the proper layout.  Having a text file is pretty useless on complicated games like pole positon.  heck man, that is the reason I created the format!

duh.

[Buddabing]

Ok getting back on topic (sorry lilwolf)  

I got everything rigged up last night and it does indeed work.  But for it to be user friendly, Buddabing, I think you are going to have to change things around a tad on your end.  (The modifications that are requred on my end are almost complete in case anyone is wondering)  

Right now I modify your bat fle to launch the viewer and generate the appropriate image, saving it to the base of the viewer's folder.  Then I copy it into the folder using the part of the bat you made.  Now this works great but some of your choices are questionable.  

For one a folder has to be made for the game before it'll work.  Why would a person need that if the image is always gonna be controls.png generated by the viewer?  I suggest simply reading from the generic "default" or "mame" folder for each game.  The viewer will generate a "not found" image if the game doesn't have an entry anyway, so it would always work.  I know you mentioned you did it so that usesrs could choose which games they wanted to use it on but that would be better achieved with a simple "-[no]use_viewer_image" tag added to mame.  Since tags can be defined in ini files too (game specific i should say)  The user would still have full control over what games to use the viewer with.    

MAME's path to load .art and .png files is the artwork\gamename directory and the artwork\gamename.zip file. I can load controls.art from the main directory, but loading controls.png from there would require changes to more MAME source files.

I see four possible solutions.
1) I can write something to create the 5000 directories, which will be easy.
2) Add something to the makectrl.bat which will add or replace controls.png within the gamename.zip file, ie.
" zip gamename.zip controls.png "
3) Modify the directory searching routines for artwork files. This will be messy since we're getting into the OS-dependent code.
4) Add the zip manipulation code to MAME.

Also I'm not particularly found of the default layout you made, but that is completely editable in the art file so I won't complain.  

I put the controls.art in the artwork\gamename directory because I figured there would be many different settings, some for vertical games, some for games with larger viewing area, etc. If I put one central controls.art file we will lose this functionality.

One last minor thing...... for the viewer to generate the most accurate layout it also needs the cloneof entry from mame. Would it be possible to add that to the bat as %2?  I can do it on the viewer end, but that would require generating a listxml file, converting it to listinfo and parsing the game.  Needless to say it'd add to the generation time.

That is a simple change. If there is no clone there will be (NOTCLONE) (including the parentheses) in %2.

Anyway keep up the good work!

I'd post a screenshot, but it's not all that impressive.  If your artwork resolution is set to high it looks exactly like a screenshot of the viewer on top of mame.  Which is a GOOD thing as that is what we want.  

I was trying to use Johnny 5 but it gave me an error 481 when trying to use a background image. What is that?

[SirPoonga]

Sirp I'm disappointed in you, you should know the answer to why text-only output is useless.  

Button re-assignments!

Your button layout for mk2 is different than your layout for street fighter, or neogeo, ect.  How is a pos text file supposed to show you that?

If you re-define all of your keys via ctrlr files then the viewer shows each label on the proper layout.  Having a text file is pretty useless on complicated games like pole positon.  heck man, that is the reason I created the format!

duh.

True, BUT even the viewer can't do everything right now:)  Like I said, having a picture in the FE then a reminder in mame would probably be the best, and currently the easiest,  to implement.  BTW, You COULD output the right button assignments.  You would be in mame, you could poll mame for the button config.  

Mame will have parsed through the ctrlr files for you!  So you could handle the redefines.  You have to remember you'd be working inside of mame so you'd have access to ALL of mame's resources and objects.  And that way it would even handle hacks like my ctrlr file hacks

[Buddabing]

True, BUT even the viewer can't do everything right now:)  Like I said, having a picture in the FE then a reminder in mame would probably be the best, and currently the easiest,  to implement.  BTW, You COULD output the right button assignments.  You would be in mame, you could poll mame for the button config.  

Mame will have parsed through the ctrlr files for you!  So you could handle the redefines.  You have to remember you'd be working inside of mame so you'd have access to ALL of mame's resources and objects.  And that way it would even handle hacks like my ctrlr file hacks

If we implement adding the controls.png file to the artwork zip file, FEs could support displaying the controls.png totally independent of MAME. Also, if the user was to upgrade to a newer version of MAME that didn't support the viewer, the controls.png would still be there for the FE.

[SirPoonga]

Right, I understand that.  The main point I was making is that if done through text, like history.day, the display can alter if you have included hacks into your version of mame.  Like my ctrlr ini hacks.   The controls.png files will probably not take into account that as those will be most likely generated outside of mame.

[Howard_Casto]

Ok getting back on topic (sorry lilwolf)  

I got everything rigged up last night and it does indeed work.  But for it to be user friendly, Buddabing, I think you are going to have to change things around a tad on your end.  (The modifications that are requred on my end are almost complete in case anyone is wondering)  

Right now I modify your bat fle to launch the viewer and generate the appropriate image, saving it to the base of the viewer's folder.  Then I copy it into the folder using the part of the bat you made.  Now this works great but some of your choices are questionable.  

For one a folder has to be made for the game before it'll work.  Why would a person need that if the image is always gonna be controls.png generated by the viewer?  I suggest simply reading from the generic "default" or "mame" folder for each game.  The viewer will generate a "not found" image if the game doesn't have an entry anyway, so it would always work.  I know you mentioned you did it so that usesrs could choose which games they wanted to use it on but that would be better achieved with a simple "-[no]use_viewer_image" tag added to mame.  Since tags can be defined in ini files too (game specific i should say)  The user would still have full control over what games to use the viewer with.    

MAME's path to load .art and .png files is the artwork\gamename directory and the artwork\gamename.zip file. I can load controls.art from the main directory, but loading controls.png from there would require changes to more MAME source files.

I see four possible solutions.
1) I can write something to create the 5000 directories, which will be easy.
2) Add something to the makectrl.bat which will add or replace controls.png within the gamename.zip file, ie.
" zip gamename.zip controls.png "
3) Modify the directory searching routines for artwork files. This will be messy since we're getting into the OS-dependent code.
4) Add the zip manipulation code to MAME.

Also I'm not particularly found of the default layout you made, but that is completely editable in the art file so I won't complain.  

I put the controls.art in the artwork\gamename directory because I figured there would be many different settings, some for vertical games, some for games with larger viewing area, etc. If I put one central controls.art file we will lose this functionality.

One last minor thing...... for the viewer to generate the most accurate layout it also needs the cloneof entry from mame. Would it be possible to add that to the bat as %2?  I can do it on the viewer end, but that would require generating a listxml file, converting it to listinfo and parsing the game.  Needless to say it'd add to the generation time.

That is a simple change. If there is no clone there will be (NOTCLONE) (including the parentheses) in %2.

Anyway keep up the good work!

I'd post a screenshot, but it's not all that impressive.  If your artwork resolution is set to high it looks exactly like a screenshot of the viewer on top of mame.  Which is a GOOD thing as that is what we want.  

I was trying to use Johnny 5 but it gave me an error 481 when trying to use a background image. What is that?

About your solutions:

1)  For that matter I could get the viewer to do it or modify the bat to do it.  But we only need one art file and one controls.png.  Any adjustments an a per game baisis (odd aspect ratios, ect) need to be done by mame internally for each game imho.  

2)Yeah but that would remove the games real artwork, which is very bad, especially in the cases that the games need the artwork for gameplay, like lunar lander and gorf.  I haven't really tested, but the artowrk for the game does still work right?  If not then we are going down the wrong direction and need to stop and figure out how to do both.  

3)I still think 3 is the best choice.  Take a look at the mess code (console equivlent of mame) and you'll find that for each system they have a "default" piece of artwork you can add for each system.  Like right now I have a vetrex.zip in my vectrex artwork directory and whenever the overlay is missing for a game it is displayed.  I agree it is complicated, but os specific stuff shouldn't be a bother as the viewer only works in windows I can help some if you need it, I'm just bad at reading the mame code.

4)Huh? You lost me.


Regarding the different folders, individual settings shouldn't be necessary.  All controls.png images will be generated in the same aspect ratio and thus all settings will be identical.  Specific images for vertical games, ect should probably be handled on the viewer end.  That's why I suggested an alpha channel as we would only have to deal with one aspect ratio and "skinny" images would simply have a wider transparent border.  

About the %2 change... I appreciate you adding it but it would be better if the game simply displayed the parent name again if the clone isn't found.  It's not necessary at all, I can code for it, it's just all of my other apps use this standard and I'm a real a-hole about stuff like that.  



I hope I don't come off sounding demanding, I just figured I should be honest and tell you the way I would like to see it done.  But you are doing the hard part so feel free to ignore me if you wish.

[Buddabing]

About your solutions:

1)  For that matter I could get the viewer to do it or modify the bat to do it.  But we only need one art file and one controls.png.  Any adjustments an a per game baisis (odd aspect ratios, ect) need to be done by mame internally for each game imho.  

2)Yeah but that would remove the games real artwork, which is very bad, especially in the cases that the games need the artwork for gameplay, like lunar lander and gorf.  I haven't really tested, but the artowrk for the game does still work right?  If not then we are going down the wrong direction and need to stop and figure out how to do both.  

Zip wouldn't remove the artwork zip file. It would add controls.png to an existing zip file or it would create a zip file. So you would potentially have up to 5000 zip files in the artwork directory. I tested this and it is fast and seamless.

3)I still think 3 is the best choice.  Take a look at the mess code (console equivlent of mame) and you'll find that for each system they have a "default" piece of artwork you can add for each system.  Like right now I have a vetrex.zip in my vectrex artwork directory and whenever the overlay is missing for a game it is displayed.  I agree it is complicated, but os specific stuff shouldn't be a bother as the viewer only works in windows I can help some if you need it, I'm just bad at reading the mame code.

It is against the spirit of mame and open source applications in general to have this be a windows-only application. I am a dos-head and if I could only get the stupid sound drivers to work right my cabinet would be dos.

4)Huh? You lost me.

Option 4 is incorporating some of the info-zip source code into mame, instead of calling zip from the batch file.

Regarding the different folders, individual settings shouldn't be necessary.  All controls.png images will be generated in the same aspect ratio and thus all settings will be identical.  Specific images for vertical games, ect should probably be handled on the viewer end.  That's why I suggested an alpha channel as we would only have to deal with one aspect ratio and "skinny" images would simply have a wider transparent border.  

About the %2 change... I appreciate you adding it but it would be better if the game simply displayed the parent name again if the clone isn't found.  It's not necessary at all, I can code for it, it's just all of my other apps use this standard and I'm a real a-hole about stuff like that.  

Not a problem, I'll change it.

I hope I don't come off sounding demanding, I just figured I should be honest and tell you the way I would like to see it done.  But you are doing the hard part so feel free to ignore me if you wish.

I think #2 is the winner, so long as we only need one controls.art file.

My next release will have one controls.art file, which will be located in the mame directory. The makectrl.bat file will call the viewer, which will create controls.png in the current directory. Then, the batch file will call zip to add controls.png to artwork\gamename.zip. The %2 parameter to the batch file will be the name of the cloneof or the name of the game. I'll upload the revised source tomorrow.

[Buddabing]

Okay, the latest revisions are done.

EDIT: removed dead link

Changes:
-- one controls.art, located in the mame root directory
-- no directory needed for controls.png
-- makectrl.bat is called with two parameters, the first
   being the game name and the second being the
   parent game. If there is no parent game then the
   second parameter is also the game name.
-- I included a zip.exe executable (from info-zip)

[Howard_Casto]

Good to hear.....  I have recently ironed out all of the issues I was having generating the image on my end.  Generating an image is a clean process now. I just need to tweak a few things to get it perfect.  

I'll test it out later this week budda and if all goes well i'll send you a beta of the viewer and we can continue development.  

[Buddabing]

Bugfix: If no controls.png is present mame would crash. This would happen if the batch wasn't present, if whatever was in the batch didn't correctly create the controls.png, or if controls.png was not correctly added to the artwork .zip file.

(EDIT: removed link to outdated patch)

When this project is done maybe we can submit the patch to TheGatesofBill for inclusion in NoNameMAME.

Buddabing