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

[ultrastyle]

I'll throw my 2 cents into the ring. I was reading about the list of controls and that got me thinking. (please realize at this point the original link to the original d/l is gone, so I haven't seen what has been done so far.) what about a list of controls that is color coded, over a static image of your control panel. then all you need to do is drop colored circles over buttons to demonstrate what button goes where. I.E. Fire is red, Jump is Green, Turbo is blue, etc. the xy coordinates would always be the same, button 1 would simply change color according to what its used for. The list itself could be dynamic and the colors static. Which means you simply have to generate text over a static picture. Joysticks, I imagine are intuitive. If not, they wouldn't have gotten all of our quarters when we were kids. It's really button layouts your after here.

[Howard_Casto]

Because:

1.  That's what the viewer does for the most part.

2.  This is quite difficult to do in mame without extensive modification.  

3.  If you would have read the thread discussing this before I've already gone over the fact that Mame only supports a single, ugly font of the same font size.  There simply wouldn't be enough room on the screen to generate a viewable layout with such a large font.  

3a.  Mame doesn't allow you to position text, it is all done using one of two menu generating macros.  It would require core changes to position text.  

4.  That would still require the hacks budda is doing to implement static image support.  It's far far easier for me to make the viewer generate the image (which would actually be more accurate do to some of my special functions) than to struggle through doing it in mame.  



I'm all honesty that would probably be the best solution, but good luck finding someone willing to put in the tremendous effort and time required to make the engine.  

[Howard_Casto]

Ok,  I compiled it and it runs without a hitch.  I will package up a beta soon.  

I have some concerns about rotation though......  

It appears that mame wants the artwork files in whatever orientation the game is rendered.  That seems like a simple problem... just rotate all the verticals right?  Well not exactly..... render orientation apparently also involves the sync of the monitor as well..... mario bros for example.... it uses an inverse sync and thus the bezel has to be upside down.  Donkey Kong, I believe also uses an inverse sync AND it's vertical, so it has to be rotate 270 degrees.  

What this means to me is rotation might have to be determined on a per-game basis.  That could get ugly.  

[SirPoonga]

Yeah, I could have told you that since I've been working on the artwork fill edges hack.

I am also looking into what it would take to output a png over everything with a button push.  That won;t be simple inside of mame with how it figures the viewable area.  Might have to have something that stores the game's viewable areea and the controls viewable area and do a swap.  Could get messy.

[Buddabing]

Ok,  I compiled it and it runs without a hitch.  I will package up a beta soon.  

I have some concerns about rotation though......  

It appears that mame wants the artwork files in whatever orientation the game is rendered.  That seems like a simple problem... just rotate all the verticals right?  Well not exactly..... render orientation apparently also involves the sync of the monitor as well..... mario bros for example.... it uses an inverse sync and thus the bezel has to be upside down.  Donkey Kong, I believe also uses an inverse sync AND it's vertical, so it has to be rotate 270 degrees.  

What this means to me is rotation might have to be determined on a per-game basis.  That could get ugly.  

Hmmmmm. If it's easier to calculate the rotation angle within MAME, maybe I could add another parameter to the batch file that has either the angle (0,90,180,270) or 0,1,2,3 in it.

I really don't want the angle calculation per game. What would we do every time a game is added?

[Howard_Casto]

Yeah, I could have told you that since I've been working on the artwork fill edges hack.

I am also looking into what it would take to output a png over everything with a button push.  That won;t be simple inside of mame with how it figures the viewable area.  Might have to have something that stores the game's viewable areea and the controls viewable area and do a swap.  Could get messy.

Viewable area actually works pretty well....  The only issue I'm finding is like if you have bezel artwork turned on the controls.png is only displayed inside the bezel.  Your right, it really needs to use the physical screen aspect to calculate area rather than the game size, else when we do get vertical games working the image will be horribly squashed.  I think the quickest fix would be to check for orientation and alter the layout dimensions depending upon them.  

Example....... In horizontal games the aspect of both the image generated and the game are 4:3 so the coordinates of the artwork file are in 1:1 factors.  (I.E the full screen or a percentage of the screen matching the same ratio).  If it's vertical take those same coordinates and leave the width alone but take half off of the height.  That should fix the squashing.  This doesn't fix games with odd aspect ratios though, so I dunno about them.  


Regarding the rotation.....  Really even the rotation itself needs to be done in mame.  Mame has various devices to rotate and I think it would be faster.  

In theory figuring out the orientation shouldn't be that bad, I was just exaggerating to get my point across.  Afaik only nintendo games used inverse sync and that is easy to check for.  Also orientation and screen resolutions are stored in mame as well.  It's just all of this would depend upon the accuracy of mame, and we all know how that goes.  

[SirPoonga]

Ok, I hae learned some useful information since I have been working ont he artwork fill edges hack.  First, you don't want to be using the artwork system to display this in mame.  Mame will stretch the image upon keepaspect and hwstretch are on.

I know HowardC knows this but not sure about the rest.  The menu text in mame is actually converted to a bitmap.  This is all done in the usrintrf.c file.  However, everything in there puts everything to display into the screen bitmap.

Funny thing is this is done in artwork.c, you have this struct.
struct mame_bitmap *artwork_get_ui_bitmap(void)
{
   return uioverlay ? uioverlay : Machine->scrbitmap;
}

Then in mame.c you have a funtion updatescreen() which contains this line:
if (handle_user_interface(artwork_get_ui_bitmap()))

So, what's handl_)user_interface?  It's in usrintrf.c.  from what I can tell it setups of alot of what you see on screen including FPS, frameskip, handling keypress events that effect what is shown on screen, etc..

That is where you'd want to put a button press handle for the controls.png file to display.  However you wouldn't want to use the bitmap sent into the function.  You'd wnat to display it fullscreen.  That will require a new function built just to display that graphic.  Oh, in artwork.c there are some funcitons for loading graphics form png files that owuld be helpful in this cause.

Though for now I'd try displaying a controls.png to the bitmap sent into that function.  Just to see if you can get it to display.  Because making a special bitmap for that file might be a little more involved.  You want to start out with something a little more simple so why not use what is there for now.

If you note inside that function there are statements like:
/* if the user pressed F12, save the screen to a file */
   if (input_ui_pressed(IPT_UI_SNAPSHOT))
      save_screen_snapshot(bitmap);

   /* This call is for the cheat, it must be called once a frame */
   if (options.cheat) DoCheat(bitmap);
/* if the user pressed F4, show the character set */
   if (input_ui_pressed(IPT_UI_SHOW_GFX))
   {
      osd_sound_enable(0);

      showcharset(bitmap);

      osd_sound_enable(1);
   }

All you'd have to do is create your own keypress thing, like:
input_ui_pressed(IPT_UI_SHOW_CONTROLS)
whereever the IPT constants are defined.
Then make a function like
showcontrols(bitmap);
Put it together you have
if(input_ui_pressed(IPT_UI_SHOW_CONTROLS))
showcontrols(bitmap);

In the future then right before you call showcontrols(bitmap) you could make your own bitmap, then call the funciton, then display the bitmap.

I  might look into doing this after I get some other projects done, unless one of you want to try and tackle it.

If any of you want to try this but would like my help as I have been starting to get a good handle on what is going on in mame either PM me and I will give you my msn messenger account or we could talk int he byoac chat room.

[Buddabing]

Regarding the rotation.....  Really even the rotation itself needs to be done in mame.  Mame has various devices to rotate and I think it would be faster.  

In theory figuring out the orientation shouldn't be that bad, I was just exaggerating to get my point across.  Afaik only nintendo games used inverse sync and that is easy to check for.  Also orientation and screen resolutions are stored in mame as well.  It's just all of this would depend upon the accuracy of mame, and we all know how that goes.  

I looked at the code and it is trivial to find out what orientation to use. Once that is known, I can modify the existing artwork load routine to pre-rotate the controls.png image. So a rotated controls.png will load at the same speed as an unrotated one.

I'll make the necessary modifications for the rotation. You concentrate on generating a non-rotated image.

Controls.png will only display in the game area and not in the bezel area. I believe that is due to the way MAME sorts the various rectangles that it uses to calculate display regions.

[SirPoonga]

addition to what I said, actually you'd have to modify update_video_and_audio() in mame.c to to display the new bitmap.  Actually, I don;t think it would be too hard to do do, just need to really understand what is going on.

[Buddabing]

So we want to maintain the aspect ratio of controls.png regardless of the aspect ratio of the game, and display controls.png across the entire width of the screen, regardless of whatever artwork is already there?

That should be doable. I already got the rotation part working.

[SirPoonga]

yeah, I believe it is doable, you just can't use the bitmap everything else in mame is outputting too.  BTW Howard, I think this is also how you can do dual monitors.

[wj2k3]

Buddabing - Great Job! This is an excellent addition to the Mame program.  I have downloaded and compiled your changes and it is working great.  

This is already worhwhile, even if I had to go through and create each controls.png files manually.

I look forward to testing out Howard's program but in the mean time I have been creating some of my own control.png files for games in my cab.  To that end, I was wondering if it would be possible to make it so that you could add a flag to run Mame without launching the makectrl.bat file.  

The reason is because along with the layout of my CP, I have been including the image of the insturction card/bezel of some games in the controls.png file to make it even more useful.

If not, i can just rename/delete the .bat file when I don't want  my custom controls.png files to be overwritten.

Anyways, thank you both for a great addition to my cab.

-wj2k3

[Howard_Casto]

Agreed.....  a flag is need imho.  

budda, i'll send you the updated beta of the viewer before the end of the week.  I was hoping to wait until the big changes but considering the ctrlr file format is now royally ahem "different" than before that could be some time.  

[Tiger-Heli]

Agreed.....  a flag is need imho.  

budda, i'll send you the updated beta of the viewer before the end of the week.  I was hoping to wait until the big changes but considering the ctrlr file format is now royally ahem "different" than before that could be some time.  

Idealized Requests:

I know this can't be answered until the concept is figured out, but I am not sure I like the new MAME changes, and either way, I will probably be using older MAME versions for some time.

Could the viewer be made to support ctrl.ini files and ctrl.cfg files and/or could separate versions of the viewer be released so you pick the one that matches your version of MAME?

Could the MAME changes to display the images be released as a -diff file so they could be applied to (virtually) any MAME version?

Thanks!!!

[Buddabing]

I think two flags would be nice:

1) -nomakectrl will prevent the batch file from being called, but will still allow the controls.png to be displayed. This will allow "roll your own" controls.png files.

2) -noshowctrl will not show any controls.png files. I don't know if we should have this include -nomakectrl or make the two flags mutually exclusive, to disable both the viewer and the display code you would need to specify both flags.

A user could use the second flag if he wants to exclude certain games, for example if he knows how to play pacman and doesn't want the controls shown or if the aspect ratio makes his controls look funny.

Maybe a third flag would cause the display to be off by default and then the user could specify -nomakectrl
-showctrl to display his roll your own images or just
-showctrl to generate and display.

Future releases of the display code will be in patch form.

Unfortunately, a patch which is created with version X of mame probably won't work on version Y. Now, it probably wouldn't be too hard to create patches for old versions, since the code is frozen.

[Tiger-Heli]

I think two flags would be nice:

1) -nomakectrl will prevent the batch file from being called, but will still allow the controls.png to be displayed. This will allow "roll your own" controls.png files.

2) -noshowctrl will not show any controls.png files. I don't know if we should have this include -nomakectrl or make the two flags mutually exclusive, to disable both the viewer and the display code you would need to specify both flags.

A user could use the second flag if he wants to exclude certain games, for example if he knows how to play pacman and doesn't want the controls shown or if the aspect ratio makes his controls look funny.

Agreed on the two flags.  Not sure about the exclusive part.  I think there would be games where you might want to disable it all together, some where you want to display your own files, and some where you want to use the viewer.

Maybe a third flag would cause the display to be off by default and then the user could specify -nomakectrl
-showctrl to display his roll your own images or just
-showctrl to generate and display.

I don't think a third flag would be required.  Couldn't you just specify
-nomakectrl 1
-noshowctrl 1
in mame.ini and then set it to 0 in the gamename.ini if you wanted it off by default, but on for individual games?

Future releases of the display code will be in patch form.
Unfortunately, a patch which is created with version X of mame probably won't work on version Y. Now, it probably wouldn't be too hard to create patches for old versions, since the code is frozen.

Cool.

BTW, I liked the idea of having the Cntrls come up when Pause was pressed, rather than having a dedicated key, but I assume if I assigned the viewer hotkey to P and Pause to P it would work that way, correct?

[Buddabing]

Agreed on the two flags.  Not sure about the exclusive part.  I think there would be games where you might want to disable it all together, some where you want to display your own files, and some where you want to use the viewer.

The two flags are in and are mutually exclusive. I'm open to suggestions as to different names for them.

I don't think a third flag would be required.  Couldn't you just specify
-nomakectrl 1
-noshowctrl 1
in mame.ini and then set it to 0 in the gamename.ini if you wanted it off by default, but on for individual games?

That .ini stuff is pretty cool! I had never used it before. It works like a champ. That will work well for wj2k3.

BTW, I liked the idea of having the Cntrls come up when Pause was pressed, rather than having a dedicated key, but I assume if I assigned the viewer hotkey to P and Pause to P it would work that way, correct?

Currently it is set up to whatever pause is set to, not necessarily P.

[Tiger-Heli]

BTW, I liked the idea of having the Cntrls come up when Pause was pressed, rather than having a dedicated key, but I assume if I assigned the viewer hotkey to P and Pause to P it would work that way, correct?
Currently it is set up to whatever pause is set to, not necessarily P.

That's what I would prefer, but I thought SirP was looking for a dedicated key that it could be set to, separate from pause.  I might have misinterpreted, though.

[SirPoonga]

I think it shoud be its own key, not pause.  you can map the pause and this to the same key.  When I pause sometimes I am looking at the games, I wouln;t want something to get in front of it unless I told it so.

[Buddabing]

I have a new version of the display code.

New features:
- The image is displayed across the entire width of the MAME window.

- The last remnants of the old controls.art have been swept away, it is not used anymore.

- An attempt is made to display the controls in the proper aspect ratio. It is better than the previous version, but not exactly right.

- Two flags have been added to mame, -nomakectrl and -noshowctrl. The names of these flags are subject to change, so be aware. The function of the flags should be obvious.

- The orientation of the image is automatically adjusted. The program now expects a controls.png with the normal orientation.

To Do:
- Make an option to use a different key than pause to view the controls.

- Improve the aspect ratio correction.

Here's the link to the zip file containing the patches.

[SirPoonga]

How do you use the patch?  It's not your normal diff and patch that everyone else uses.

http://gnuwin32.sourceforge.net/packages/diffutils.htm

[Buddabing]

How do you use the patch?  It's not your normal diff and patch that everyone else uses.

http://gnuwin32.sourceforge.net/packages/diffutils.htm

These patches have to be applied with patch -R. When I ran diff I was in my altered source directory, with the original source in a v0.84 branch of the directory tree.

So,
1) extract patches
2) copy patch1.txt to (MAMEROOT)\v0.84\src
3) copy patch2.txt to (MAMEROOT)\v0.84\src\windows
3) cd to (MAMEROOT)\v0.84\src
4) patch -R < patch1.txt
5) cd to (MAMEROOT\v0.84\src\windows
6) patch -R < patch2.txt
7) cd back to (MAMEROOT)\v0.84
8. make clean
9) make

If that doesn't work PM me and I can email you the altered source files.

[SirPoonga]

Interesting.  I only asked because this is odd.  You have seperate patch files, not one.  And the format is differnt than most others I have seen.  Then for those you do this: patch -u -p 1 -i [diff file name]

Edit:  ok, I deleted the .o files of the files that changed.  Compiling now.  linking....

What would you suggest be the best way to test this?  Just start up a game like bloodbro?

[Buddabing]

Interesting.  I only asked because this is odd.  You have seperate patch files, not one.  And the format is differnt than most others I have seen.  Then for those you do this: patch -u -p 1 -i [diff file name]

I know very little about diff and patch and this was the easiest and fastest way for me.

Edit:  ok, I deleted the .o files of the files that changed.  Compiling now.  linking....

Warning: if you don't do a full compile (make clean first) then MAME will probably crash. This is because the mame.h was changed and it changed the size of the options structure.

What would you suggest be the best way to test this?  Just start up a game like bloodbro?

I have a test suite of 8 games:
zookeep (ROT0 with artwork)
pacman (ROT90 with artwork)
mario (ROT180 with artwork)
gorf (ROT270 with artwork)
gravitar (ROT0 without artwork)
astrof (ROT90 without artwork)
darkplnt (ROT180 without artwork)
bagman (ROT270 without artwork)

I also run each game in a window and full screen.

[SirPoonga]

Edit:  ok, I deleted the .o files of the files that changed.  Compiling now.  linking....

Warning: if you don't do a full compile (make clean first) then MAME will probably crash. This is because the mame.h was changed and it changed the size of the options structure.

Right, because if you change a .h but not the .c make won;t remake the .o file.  hence I deleted all the .o of that files that have been changed.  I'm on a slow machine, not going to recompile code that doesn't need recompiling  actually, sometimes you have to delete the entire root and windows folders.  But I wouldn't get rid of the driver and stuff, those don't have anything to do with this change

Anyway, I need a command-line zip.  suggestions?  Can winzip do commandline?

E:\mamedev\mamectrl>mame pacman
OK.
parsing puckman.ini...N/A
parsing pacman.ini...N/A
Using DirectInput 7
Keyboards=1  Mice=1  Joysticks=2 Lightguns=0
Mouse support disabled
Joystick support disabled
Keyboards=1  Mice=0  Joysticks=0
'zip' is not recognized as an internal or external command,
operable program or batch file.

-----------------------------------------------------
Exception at EIP=00484F14: ACCESS VIOLATION
While attempting to read memory at 00000000
-----------------------------------------------------
EAX=00000000 EBX=03630958 ECX=00000000 EDX=00000000
ESI=0022F9C4 EDI=00852060 EBP=00000005 ESP=0022F980

E:\mamedev\mamectrl>

[SirPoonga]

Ok, I got the commandline stuff for winzip, but it's evaluation so I ahve to press a key

Anyway, this is cool.

However there has to be a way to not use the artwork folder.  If you could just dump the pngs in a folder that would be the ultimate option.  That way an outside source creates the png file.

I know this is a proof of concept.  So it does show it is possible.

[Buddabing]

Anyway, I need a command-line zip.  suggestions?  Can winzip do commandline?

There is a free zip program here. I couldn't get on their web site when I tried it just now....

MAME should not crash if there is no controls.png in the zip file, or no zip file at all. So that is a bug.

[SirPoonga]

no, the crash is due to no zip command.

[Howard_Casto]

Ok, I got the commandline stuff for winzip, but it's evaluation so I ahve to press a key

Anyway, this is cool.

However there has to be a way to not use the artwork folder.  If you could just dump the pngs in a folder that would be the ultimate option.  That way an outside source creates the png file.

I know this is a proof of concept.  So it does show it is possible.

Open folders take priority over zip files.  My suggestion.... create the folder, dump the crap in it, upon exit delete the folder you created.  

[Buddabing]

I've improved my code to correct the aspect ratio on the display. So a square in the controls.png will appear square regardless of what game is being played. The code to do this is ugly, however.

Regarding the treatment of paths: MAME has a certain search order for artwork coded into it. It searches gamename.zip in the artwork directory and it searches the directory artwork\gamename. Changing the file path to the current directory or to a temporary directory is not easy. I want this patch to be as small as possible and I don't want to touch more source code files than I have to. Four files is more than enough. The average user will not care that there are many small zip files in his artwork directory.

I'm aiming for a code update tomorrow. I'll look again at the file handling, but if I can't do it in just a few lines of code then I don't want to do it.

Regards,
Buddabing

[SirPoonga]

My point is why use the mame artwork stuff to load the png.  Make a new load_png function, base it off the artwork stuff but modify it as needed.

[Buddabing]

My point is why use the mame artwork stuff to load the png.  Make a new load_png function, base it off the artwork stuff but modify it as needed.

IMO that is too much effort for not enough benefit. I'll look deeper into the code and I'll see what can be done.

[SirPoonga]

Well,  I just htink if this is done it should be done the right way.  This is possibly something that could get added into mame if done the right way.

I'm not saying I don't like what you are doing.  It's more than we have now.  But this should really be seperate from the artwork files as it's concept is different.

[Buddabing]

New version of display code as of 8-6-04 - I wanted to get this out so people could play with it over the weekend.

New features:
- The image is displayed across the entire width of the MAME window.

- The last remnants of the old controls.art have been swept away, it is not used anymore.

- The controls are displayed in the proper aspect ratio.

- Two flags have been added to mame, -nomakectrl and -noshowctrl. The names of these flags are subject to change, so be aware. The function of the flags should be obvious.

- The orientation of the controls.png image is automatically adjusted. The program now expects a controls.png with the normal orientation.

- You can use a different key than pause to view the controls. By default the show controls button is also set to P.

- No zip program is required anymore. The display code expects controls.png to be in the current directory.

Here is a link to the zip file containing the patches.

There are two patch files included, patch1.txt and patch2.txt. Patch 1 should be put into the src subdirectory and patched with the -R option.
Patch 2 should be put into the src\windows subdirectory and patched with -R.

I included a basic controls.png which I used to test the aspect ratios.

Once the patches are applied, make sure you "make clean"! Or else MAME will crash!

I hope that everyone enjoys this application. If you cannot apply the patches, PM me and I'll email you the complete source files.

Also let me know if there are any additional features you want.

Regards,
Buddabing

EDIT: Looks like the aspect correction only works if
-window is specified on the command line. Also the separate control doesn't appear to work right, so extract the mame.c which will make the controls appear when pausing.

[Buddabing]

New version of display code as of 8-6-04 - I wanted to get this out so people could play with it over the weekend.

EDIT: I fixed the problem with kick and dotron, which was that those games use a different orientation.

There are two bugs left that I know of. One is that MAME will crash if you turn on the controls display too close to resetting the machine. So don't do that!  

The other bug affects games that have hard-coded artwork. For example, Star Castle relied on colored overlays on the screen to show the colored rings, otherwise the screen would be black and white. Those games currently crash MAME.

There is also one weird orientation which affects only one game that I know of, solarfox.

Here is a list of the games that have hard-coded artwork, and thus crash MAME:
astdelux   avalnche   bzone   redbaron   starcas
tailg          sundance  solarq   circus    copsnrob
lazercmd   deadeye   gypsyjug   omegrace   sbrkout
geebee    sos   tinv2650

[SirPoonga]

You have vector games in that bunch, redbaron is, isn't it?  Mame handles the artwork slightly differently for those.

[Buddabing]

You have vector games in that bunch, redbaron is, isn't it?  Mame handles the artwork slightly differently for those.

Yep, that's one reason I had gravitar in my test suite. But tacscan, zektor, and starwars all work okay.

[Howard_Casto]

Ok as promised, a new viewer.  I decided to make it a public release as I'll have to rewrite most of it for the new xml-based ctrlr files and it could take quite some time.  But please don't everyone shout to the heavens that it's out.  It's still an early beta and not particularly user-friendly yet.  


http://www.oscarcontrols.com/lazarus/files/johnny5_0.7beta.zip

Note:  This build generates an image with the -justprint command and coupled with irfanview prepares the image for the mame hack.  

[Buddabing]

Ok as promised, a new viewer.  I decided to make it a public release as I'll have to rewrite most of it for the new xml-based ctrlr files and it could take quite some time.  But please don't everyone shout to the heavens that it's out.  It's still an early beta and not particularly user-friendly yet.  


http://www.oscarcontrols.com/lazarus/files/johnny5_0.7beta.zip

Note:  This build generates an image with the -justprint command and coupled with irfanview prepares the image for the mame hack.  

I downloaded the viewer and tried it. A .BMP image was generated and I can view the image with Gimp. Unfortunately, it looks like Irfanview doesn't do batch processing correctly. It just launches and displays johnny's .bmp file. Converting the image with Gimp should work but is much more complicated since there is a whole scripting language for it.

EDIT: I found a free conversion package calledImageMagick

Johnny5 clears the screen even when -justprint is specified, it probably shouldn't do that.

Here's the makectrl.bat I'm using.
@del controls.png
johnny5.exe -justprint %1 -clone %2
convert controls.bmp controls.png

It looks like it runs the first time through mame, but gives a run error 9 after that.

Running the batch program makectrl.bat from the command line works pretty well, except for the clear screen thing.

[Howard_Casto]

Irfanview works just fine..... you install it somewhere  (anywhere is ok)  and then you copy the exe and only the exe to the j5 folder, making sure it is named to match the name given in the docs.  The viewer does the rest, you don't use any command line options to convert.  

Also your bat file doesn't copy over the controls.png so that might be part of your error.  J5 can't be in the same folder as mame as it needs full read and write access to both controls.bmp and controls.png and vb is a tad slow with releasing it after the viewer exits.  

J5 doesn't clear the screen, it puts up a black window to hide the viewer while the bmp is being rendered behind it.  It's supposed to do that.  In a front end you would be shown a blank screen, as opposed to.... a blank screen.  So what exactly is the problem with that part?  

[Howard_Casto]

My Bat File:


%echo off

cd\
g:
cd "\Development DON'T ERASE\sources\Controls Viewer2\"
johnny5.exe %1 -clone %2 -justprint
copy "g:\Development DON'T ERASE\sources\Controls Viewer2\controls.png" "e:\mame\controls.png"
e:
cd\
cd mame\
zip -q artwork\%1.zip controls.png

Of course your bat would use different paths.

[Buddabing]

My Bat File:


%echo off

cd\
g:
cd "\Development DON'T ERASE\sources\Controls Viewer2\"
johnny5.exe %1 -clone %2 -justprint
copy "g:\Development DON'T ERASE\sources\Controls Viewer2\controls.png" "e:\mame\controls.png"
e:
cd\
cd mame\
zip -q artwork\%1.zip controls.png

Of course your bat would use different paths.

I see. Johnny calls irfanview directly. In that case, copying irfanview into  the Johnny directory should be part of installing Johnny, right? The docs should say "Make sure you install Irfanview first!" Also, it would probably be best if Johnny was automatically installed into a MAME subdirectory, then the makectrl.bat could be simplified:

@echo off
del controls.png
cd johnny5
johnny5 %1 -clone %2 -justprint
copy controls.png ..
cd ..

The viewer works great with this batch file when the iview32 is copied into the johnny subdirectory. If johnny is installed somewhere else, perhaps the makectrl.bat could be generated or modified by johnny.

The blanking of the screen is annoying when running mame from the command line, especially in windowed mode. Can't you render to a window that isn't visible? People running frontends probably don't want to look at a blank screen during the second or two that Johnny takes to generate the image. I'd rather see the frontend's "loading game..." message, that way the image generation process is more transparent.

I would like the viewer to dim out or optionally remove controls that are not used in the current game. For example, if I'm playing Gorf I don't want to see the trackball.

Does the viewer put labels on or near the buttons? I would like to see "High Punch" displayed on whatever button High Punch is mapped to. That is IMO the most important feature of the viewer. This is not on the default layout.

I see that the font size and type is selectable, that's a good thing since people with small screens may have a problem reading the text in the default layout.

I'm looking forward to finishing this project and putting it on my cab!

[Howard_Casto]

So let me get this straigh budda... you went to all this trouble and haven't even tried the viewer before.  Pass me over some of that crack you are on.  

Answering your questions:

Notice the word beta in the zip file... this isn't a public release.  Also if you read the notes in the docs it discusses the fact that you must place irfanview in the j5 folder.  


The blanking of the screen isn't annoying to me. Presently it can't be removed either.  Although I can make the screen invisible, it has trouble scaling the image when I do so (why I have no clue, I'm looking into it.)  

That's not how the viewer works..... I'm not about to change the way it works at this point.  However, before the major mame changes I was adding support for control specific layout files.  In theory you could dim out the controls that way by using a different image for each layout with unused controls dimmed.  

I'm not sure what you mean..... the labels are placed directly over the buttons with the default layout.  

That is assuming:

A.  You are using ctrlr files and only ctrlr files to remap buttons (pre 84 ctrlr files at this point).  

B.  When you when into the viewr options you set the ctrlr sub folder to the one you actually use.

C.  You right clicked over top of p1 button 1 in the layout editor and changed the default key to which ever key you normally use.  Alt should never, ever, ever be used as a gaming key in a windows environment and thus by default I have it mapped to the key I use ("V").  

Should I change that?  Probably... but a side result of leaving it this way is users are forced to play around in the layout editor and thus learn more about how the viewer works, and thus less questions for me.  

[Buddabing]

So let me get this straigh budda... you went to all this trouble and haven't even tried the viewer before.  Pass me over some of that crack you are on.  

I tried a previous release but it didn't work on the background image I was using.

Answering your questions:

Notice the word beta in the zip file... this isn't a public release.  Also if you read the notes in the docs it discusses the fact that you must place irfanview in the j5 folder.  

The only documentation I see has something about "Fudging".

The blanking of the screen isn't annoying to me. Presently it can't be removed either.  Although I can make the screen invisible, it has trouble scaling the image when I do so (why I have no clue, I'm looking into it.)  

That's not how the viewer works..... I'm not about to change the way it works at this point.  However, before the major mame changes I was adding support for control specific layout files.  In theory you could dim out the controls that way by using a different image for each layout with unused controls dimmed.  

The viewer assembles image pieces from somewhere, right? So have an equivalent image source that is dimmed and if a control is in the layout but not in the game get it from the dimmed image source.

I'm not sure what you mean..... the labels are placed directly over the buttons with the default layout.  

That is assuming:

A.  You are using ctrlr files and only ctrlr files to remap buttons (pre 84 ctrlr files at this point).  

All default options right out of the box. When a general release is done some kind of text should appear on the buttons.

B.  When you when into the viewr options you set the ctrlr sub folder to the one you actually use.

I haven't launched the viewer application, and thus have not set any viewer options.

C.  You right clicked over top of p1 button 1 in the layout editor and changed the default key to which ever key you normally use.  Alt should never, ever, ever be used as a gaming key in a windows environment and thus by default I have it mapped to the key I use ("V").  

I haven't used the layout editor on this release, I'm using all default options.

Should I change that?  Probably... but a side result of leaving it this way is users are forced to play around in the layout editor and thus learn more about how the viewer works, and thus less questions for me.  

I think the net effect will be that people won't use your viewer.

[Howard_Casto]

I think you are getting a bit defensive in your comments.  I really appreciate your help but I think I need to make a few things clear.  

J5 is beta, very beta, so the docs aren't the best in the world, however if you are familair with any of my apps you would know that nothing works out of the box.  Besides a little common sense is required... the viewer reads ctrlr files.  How is it supposed to know where your ctrlr files are or which ones you use without pointing to them?  There is a readme btw... it's called readme.txt and its' in the root folder.  

I expect users to play around with things just a tad before they start asking questions.  

No the viewer doesn't assemble an image.  The image is pre-rendered with labels overlayed on top of it.  Again, I can't believe you went to all of this trouble without experiencing the viewer yet.  By the sound of what you are wanting as opposed to what the viewer does you might find out that you don't like it that well.  I'll stress again how much I appreciate it, it just worries me a little that you made something work for an app without ever really using the app.  

As I said... default options never work.  As a matter of fact default options never work on nearly every complex application in the history of computing.  


I'm sorry you feel that having to change a single control will keep people form using the viewer, but nothing could be further from the truth.  Judging by feedback and comments I get pretaining to this application it's seconded in popularity only by dragon king itself.  And keep in mind, it's beta and has never had an official public release.  
This type of applicaiton simply can't be a "turn key" solution because there are far too many variables.  If it was set and forget then it would lose a great deal of functionality.  

The controls viewer shows the real layout you have set, not some genric overlay based on mame defaults.  If you remap some keys for a particular game (in ctrlr files of course)  those changed will be reflected on the layout and thus a lot of info needs to be gathered about your particular mame setup.  

I really appreciate your feedback though.  

I won't bother to update the docs until much later when the viewer is made public and new ctrlr format is supported though as virtually every part of the backend will need to be changed.  

[wj2k3]

HowardC

Is it possible to have the viewer use different background images depending on the "*Display Control Info P1" entry?

I have a 2-player cpanel but I use a close-up image of just the player-1 controls for this application so that it is easier to view.  I would like to use an image of the whole CP (showing both joysticks) for games such as Crazy Climber.  I could also have different images for Joy+2Button vs Joy+3Button (etc.) and dim out the buttons that are not used.

Thanks for the great work. (along with Buddabing).  This has been a great addition to my cab (once I figured out to set  artwork_resolution so that I could actually see something besides a big blur. )

-wj2k3

[Buddabing]

I've uploaded a new release. The patches are here.

Hopefully you should be able to apply the patches with "patch < patch1.txt" and "patch < patch2.txt". If that doesn't work, LMK and I'll email you the complete source files.

I removed support for changing the button that displays the controls independent of pause. Now the only way to display the controls is to pause.

I also changed the behavior of the -nomakectrl flag. If the flag is turned on, then the game will expect your home-grown artwork in the artwork\gamename.zip file.

The game calls makectrl.bat which is expected to be in the same directory as mame.exe. The controls.png which is generated by makectrl.bat is also expected to be in that directory.

The aspect ratio correction is not perfect and shows mostly on vertical games that are very skinny, such as bagman.

These patches are for version 0.84. I will create a version 0.85 patch when the code is more stable.

You will get better results if you add artres 2 to your mame.ini, if you have one. I just learned that.

Sorry it's been so long since the last release. I was sick for a few days last week and I also lost a bit of time playing Doom 3.

Regards,
Buddabing

[wj2k3]

buddabing,

Video games!  Who has time for playing games!

Glad you are feeling better.  

I agree that Pause is the only way to go.

Yes, I too just learned about artwork_resolution=2.  Makes a world of difference.  

Could you please send me the source files to compile.  I am still ignorant when it comes to 'patch'ing.  I will message you with my e-mail.

Thanks again (HowardC too)
-wj2k3

[2600]

Ok, I've integrated the patch.  I'm using .83 btw and I don't think I needed to change anything.

Here's feedback if you are looking for it, I'll try to post some more if interested:

1. Probably isn't good  to have mame crash if the files aren't present
2. Maybe I'm just tired, but why does Bezel artwork need to be turned on for it to work.  Can it just be artwork turned on instead?
3. Speaking of Bezel,  haven't done extreme testing or looked heavily into the source, but it the game has a bezel the controls don't get squashed.  If they don't have a bezel, the controls are squashed.

These are just some quick notes.  Still fine tuning my configuration for Johnny5, so won't post that yet.  BTW, Howard, Johnny5 is still going to support the old ctrlr files not just the new ones, correct?

Have to say it's very cool to have the controls up during pause.

[Howard_Casto]

2600 has a point..... why not simply use the completely unused flyer or marquee slots?  They were put in for expansion, well, we are expanding.  

Weather or not I will also support the old ctrlr format in future versions is unknown.  Mind you I would like to, but I wasn't finished with the whole parsing hierarchy when the format changed and thus the old format is only 80% complete.  I don't really see myself wasting my time working on a dead format when users could simply upgrade and not have to worry about it.  


Fact of the matter is, ctrlr files are pretty new and thus you won't see any real speed decreases between using the new versions of mame over the older one's that still had ctrlr support.  I've also released a ini to cfg converter, so re-authoring your ctrlr files isn't an issue either.  I honestly can't see any reason not to upgrade, considering mame now handles mice and joysticks better, which would be a good reason to upgrade for any mamer that uses more than sticks and buttons.  

[SirPoonga]

2600 has a point..... why not simply use the completely unused flyer or marquee slots?  They were put in for expansion, well, we are expanding.  

Why not just make a new layer called controls.

[SirPoonga]

I've also released a ini to cfg converter, so re-authoring your ctrlr files isn't an issue either.

Actually it is.  Unles you make it an option for the viewer to auto configure itself via the mame.ini file.   As that will be point to the ctrlr folder with the ini format.  You;d need to be able to specific a different folder OR possibly a different extention in the same folder.

[Buddabing]

Ok, I've integrated the patch.  I'm using .83 btw and I don't think I needed to change anything.

Here's feedback if you are looking for it, I'll try to post some more if interested:

1. Probably isn't good  to have mame crash if the files aren't present

Definitely true. I'll fix that.

2. Maybe I'm just tired, but why does Bezel artwork need to be turned on for it to work.  Can it just be artwork turned on instead?

I'm not sure what you mean. You can selectively turn on artwork layers with a command line switch?

I put the controls artwork in the bezel layer only because it didn't work when I put it in the artwork layer. I suppose I could try putting it in the other layers.

3. Speaking of Bezel,  haven't done extreme testing or looked heavily into the source, but it the game has a bezel the controls don't get squashed.  If they don't have a bezel, the controls are squashed.

Actually, the more that the aspect ratio of the game differs from the aspect ratio of the physical screen, the more that the controls artwork will be stretched or squashed. The games that have bezels are set up so that the total area of bezel plus game has the 4:3 aspect ratio.

These are just some quick notes.  Still fine tuning my configuration for Johnny5, so won't post that yet.  BTW, Howard, Johnny5 is still going to support the old ctrlr files not just the new ones, correct?

Have to say it's very cool to have the controls up during pause.

Thank you for your feedback. I will be releasing a v0.85 patch soon. I'm glad to know that v0.83 will work with the patch.

[SirPoonga]

Actually, the more that the aspect ratio of the game differs from the aspect ratio of the physical screen, the more that the controls artwork will be stretched or squashed. The games that have bezels are set up so that the total area of bezel plus game has the 4:3 aspect ratio.

This is partially correct.  The bezel does not have to be 4:3.  The game area int he bezel doesn't have to be 4:3.  Mame is try to make the game screen fit the bezel mask area AND stretch the bezel image and game area to make the game area the correct ratio if hwstretch and keepaspect are on.  However mame isn't always successful at this as the discusion from my artwork fill edges hack have found out.

I tmight be possible to not stretch a single layer. The way the code is setup in mame it goes through each layer and adjusts it accordingly.  I wonder what would happen if you skipped over a laye.

[2600]

Doh, sorry about that Howard, completely forgot about your conversion tool.  Even if I don't upgrade, I could use that or make some xml files so not a big deal.

Concerning the Bezel topic, I was a little bit quick on that just because I don't like using the bezels.  Sorry about that, I should get off my ars and just delete the bezels since I don't use them.

I'm not sure if you can fix the aspect ratio easily, but a quick hack is to have a blank or black bezel for the game.  I used the vertbezels on retroblast as a starting point if you want to give it a try.  It's a hack, but may help if there isn't a better way in the code.

[Buddabing]

Bugfix: MAME crashes if there is no viewer installed. Here is a quick fix, it's just changing one line of code.

Search for code in artwork.c that looks like this:

if (piece->layer >= LAYER_BEZEL && piece->intersects_game && piece->visible) /* Buddabing */

Inside the final paren add this little snippet:
      && piece->prebitmap!=NULL
      
I'll put out a revised patch for v0.84 and a new patch for v0.85 today.

I'll also try 2600's black bezel idea.

[Buddabing]

New patches with MAME version 0.85 support. These patches will allow images created with the Johnny5 viewer application to be displayed in MAME when pause is pressed.

The v0.85 patch is here

The v0.84 patch is here

This version should not crash if there is no viewer.

Please post feedback to this thread. If you would like me to email you the patched source files, PM me.

Regards,
Buddabing

[2600]

I know it's still a WIP, here's a couple more comments:

Buddabing
 - I'm sure you know, but the patch worked concerning crashing.  Tested a bunch of different ways.
 - I'm having trouble with the -nomakectrl command.  It's not making the control, but I can't get it to display.  Could you do a quick test on this? I placed a controls.png in the artwork\gamename.zip and a few other variations, but still not getting it displayed unless of course I have a controls.png in the mame directory.

HowardC
- Under the options for the viewer.  Is it possible to make the ctrlr folder a path instead of the folder name?  Same with any mame folder you need to access.
- The few games I've tested work fine, but I can't seem to get ikari to show the 8-way direction.  Anything I'm doing wrong or known issue?
- Also, when you generate the controls.png file is the file generated to the resolution that the game is running at or the resolution before the game is launched?

SirPoonga
Figure while I'm here I'll ask you so you don't get the shaft.  I can post a seperate topic elsewhere if you want, but What would the correct way to enter kchamp into the database.  It's one of those games where controls and commands are coupled together.

[SirPoonga]

SirPoonga
Figure while I'm here I'll ask you so you don't get the shaft.  I can post a seperate topic elsewhere if you want, but What would the correct way to enter kchamp into the database.  It's one of those games where controls and commands are coupled together.

I will get back to you on this soon, I am busy the next couple of day.  Post a message ont he controls.dat forum so HowardC and I can look at the issue.  Off hand I can't remember what that game used.

[Howard_Casto]

- Under the options for the viewer.  Is it possible to make the ctrlr folder a path instead of the folder name?  Same with any mame folder you need to access.
- The few games I've tested work fine, but I can't seem to get ikari to show the 8-way direction.  Anything I'm doing wrong or known issue?
- Also, when you generate the controls.png file is the file generated to the resolution that the game is running at or the resolution before the game is launched?

SirPoonga
Figure while I'm here I'll ask you so you don't get the shaft.  I can post a seperate topic elsewhere if you want, but What would the correct way to enter kchamp into the database.  It's one of those games where controls and commands are coupled together.

No it's not possible, but why exactly would you want to?  You pass the mame path and then it can "automagically" figure the rest out if you just give a folder name.  It's actually simplier that way.  

Nope it doesn't show up for me either.  I found a bug and fixed it and it's a biggie.  Thanks for your help!

The file is generated at the size of the screen prior to launch.  However you can specify any resolution you like.  When you write your bat, simply tack on a "-position 0,0,width,height" flag and the viewer will size prior to the generation.  

Heh, karate champ.  There is a reason sirp directed you towards me.  It's sirp's fancy database system (which is amazing and you should all thank him for regularly as it holds the project together) but it's my insaine data file format.  I usually do the hairy one's myself, so I went ahead and did it for you.  Check it out in the "games to be added" section and see if it's ok.  

[2600]

No it's not possible, but why exactly would you want to?  You pass the mame path and then it can "automagically" figure the rest out if you just give a folder name.  It's actually simplier that way.  

Nope it doesn't show up for me either.  I found a bug and fixed it and it's a biggie.  Thanks for your help!

The file is generated at the size of the screen prior to launch.  However you can specify any resolution you like.  When you write your bat, simply tack on a "-position 0,0,width,height" flag and the viewer will size prior to the generation.  

Heh, karate champ.  There is a reason sirp directed you towards me.  It's sirp's fancy database system (which is amazing and you should all thank him for regularly as it holds the project together) but it's my insaine data file format.  I usually do the hairy one's myself, so I went ahead and did it for you.  Check it out in the "games to be added" section and see if it's ok.  

Not a big deal, but here's why I asked.  It seems logical to me, but it's always logical when one does it themselves.  I keep my ini, roms, and ctrlr folders/files in one directory (ex. D:\emulators\mame\).  Then if I switch/try a different version I put it their own directory (ex. D:\emulators\mame83).  Then I just point the folders to the correct location in the mame.ini file.   Less copying and duplicating of files for me.

Position -  Just like in the readme.  Sorry.  On the other hand may have found a bug, when using the -justprint tag the image of the CP is correct but there is an extra black background that isn't sized correctly.  This doesn't happen if don't use -justprint.  I was originally asking because I was wondering if the picture quality would be better if it was made for the resolution it would be used for instead of scaling it down using -artres since that scales all artwork down.  Didn't know if buddabing could pass that argument to you.

Ikari and kchamp - Thanks, the kchamp one was a bit confusing.  Didn't know if it should be left or reverse or should you list the moves.  Glad it's in.

Definitely thank Sirpoonga and all of you, I know it's a lot of work and almost why I hate to post the bugs.  I know you all are busy and with typing it's not always clear that I'm not complaining and asking for things to be done, just trying to do some documenting and testing for you all.

[wj2k3]

Finally, I was able to use the patches to update the source code and compile it.  Thanks Buddabing for forwarding the update source files in the mean time while I was educating myself.

Patched and compiled the 0.85 code and everything seems to be working great except the -nomakectrl flag.  It prevents Mame from calling the batch file but it does not look for art in the artwork zips.  It does display the control.png file (if present) in the Mame directory.  And iif no file is present, it does not crash.

The Johnny5 viewer is working great too.  This project should certainly increase contributions to the Controls.Dat project.

Thanks you two for the great work.
-wj2k3

[SirPoonga]

Heh, karate champ.  There is a reason sirp directed you towards me.  It's sirp's fancy database system (which is amazing and you should all thank him for regularly as it holds the project together) but it's my insaine data file format.  I usually do the hairy one's myself, so I went ahead and did it for you.  Check it out in the "games to be added" section and see if it's ok.  

True, HC does the more difficult ones.  Since he understand how they should look and feel in the format he can figure out how to put it in the system  Also I have been way to busy lately with interviews and such that I just don;t have time right now.

[Buddabing]

I know it's still a WIP, here's a couple more comments:

Buddabing
  - I'm having trouble with the -nomakectrl command.  It's not making the control, but I can't get it to display.  Could you do a quick test on this? I placed a controls.png in the artwork\gamename.zip and a few other variations, but still not getting it displayed unless of course I have a controls.png in the mame directory.

A change I made didn't make it into my production patch.

In artwork.c, look for this code in function open_and_read_png:

/* open the file */
if (strcmp(filename,"controls.png")==0 && !options.nomakectrl)
        file = mame_fopen(gamename, filename, FILETYPE_NOPATH, 0);
else
        file = mame_fopen(gamename, filename, FILETYPE_ARTWORK, 0);
if (!file)
      return 0;

Add the bold faced part &&!options.nomakectrl

There are two places you can put your own artwork if you use -nomakectrl. One is where you tried, in the artwork\gamename.zip file. The other is in the gamename subdirectory of the artwork folder, e.g.
c:\mame\artwork\joust for joust. In this case, controls.png is unzipped. Uppercase/lowercase should not matter.

I'll be creating a patch for 0.86 soon and updating the patches for 0.85 and 0.84.

Sorry for any inconvenience.

Regards,
Buddabing

[wj2k3]

Buddabing,

No inconvenience at all and absolutely no apology necessary.  Like 2600 said, I am not complaining but just commenting to try to help.  

Any inconvenience?  Quite the contrary!  Before this project, I was headed down the path of trying to incorporate an LCD screen to display controls.  This is so much more convenient/easier/cheaper.  You could walk away from this project at anytime and I would be grateful as H. E. double hockey sticks for your contribution to the community.

And now for my contribution (if anybody wants it).  I actually like the code the way it is.  I have written a BAT file that runs as my executeable from MameWah and gives me several choices.

Choice one, takes my homebrewed filename.png from my controls_image directory and copies it to my MAME directory as controls.png.  That way when I hit Pause, my homebrew images are shown.  If there is no image for that filename yet, it launches johnny5 to create one.

Choice two (launched from Mamewah using the Extra Options #1 feature)  sends along the extra flag 'johnny5' as the variable %2 which causes the Batch file to run Johnny5 to create the controls.png file in the Mame directory.  

Choice three (via MameWah's Extra Options #2) sends the extra flag 'create' to the batch file which then runs Johnny5, copies the controls.png to the Mame directory as controls.png and to my controls_image directory as filename.png.  This is useful to replace a homebrew image that I no longer want (or is messed up) and want to start over with.

Look forward to the 0.86 version and trying out my new found patching skills.

-wj2k3

[Buddabing]

Update for version 0.86 is here. I've included a brief howto.

I have not updated the patches for 0.85 and 0.84. That will come later.

WJ2K3 - I will get the .86 source files out to you today. Do you still want the .85 source files?

As always, I appreciate your feedback.

Regards,
Buddabing

[wj2k3]

Bubba,

If u could send me the 0.86 files just incase.  I think I have got a handle on this patching, now that I have acquired the correct version of patch.  I was succesful with patching the 0.85 files but I would like to compare my 0.86 files to yours to make sure they came out right.

Again thanks for all the hard work.

The Bat files that I am using work great because the roms load so much faster.  I only have to wait for J5 to create the image the first time, or if I want to re-create/update it.  

HC, look forward to trying out the update J5 that can use multiple layouts depending on controls.

-wj2k3

-wj2k3