CPMaker v0.88 - some major changes

[papaschtroumpf]

I may have found another feature: if I run a game with -noart the control panel isn't shown
Maybe that's how it's supposed to work but I'm not sure why.
Took me 3 hours to figure out why the panel stopped showing up, because I was testing with 1941 and I have an ini file that sets it to noart.  

[Buddabing]

I may have found another feature: if I run a game with -noart the control panel isn't shown
Maybe that's how it's supposed to work but I'm not sure why.
Took me 3 hours to figure out why the panel stopped showing up, because I was testing with 1941 and I have an ini file that sets it to noart.  

Here are the various artwork-related options. You can get a complete list by running mame -showusage.


-artwork_directory <string>    directory for Artwork (Overlays etc.)          
-[no]artwork / -[no]art        use additional game artwork (sets default for  
-[no]use_backdrops /           use backdrop artwork                            
-[no]use_overlays /            use overlay artwork                            
-[no]use_bezels / -[no]bezel   use bezel artwork                              
-[no]artwork_crop /            crop artwork to game screen only                
-[no]artcrop                                                                  
-artwork_resolution / -artres  artwork resolution (0 for auto)                
-[no]intmakectrl /             Use internal controls artwork generator        
-[no]extmakectrl /             Use external controls artwork generator        
-[no]noshowctrl /              Do not show controls artwork                    

[papaschtroumpf]

I'm still not sure how it related to CPMaker and doesn't answer my question:

if I run mame 1941 -nobezel, then I don't see the control panel when I pause the game, why does removing the bezel impact CPMaker?

[Buddabing]

I'm still not sure how it related to CPMaker and doesn't answer my question:

if I run mame 1941 -nobezel, then I don't see the control panel when I pause the game, why does removing the bezel impact CPMaker?

The control panel image is artwork, and, more specifically, bezel artwork. So if you disable artwork or bezels you will disable the CP image display. It was done that way in order to interface smoothly into the MAME code.

[papaschtroumpf]

I didn't realize that, although by now I had come to suspect it.
Is it possible to bypass the -nobezel flag? is it even advisable?

My cab is on the small side and only has a 17" monitor, so games like 1941 look tiny in the middle of a sea of black (since I don't have a 1941 bezel artwork) so I like playing it better with -nobezel.
Oh well, it's not like I need a cheat sheet for the controls on that one so I can always specify -nobezel in a dedicated ini file for this game and a few others like it.

Works great otherwise, we jsut need to fill in the controls.dat database.

[2600]

Buddabing,
I think I found a bug.  Not  really a big deal, but should work.

If you run mame with the -ftr command, i.e. mame pacman -ftr 100
you get the following error after mame runs:

libpng error: Call to NULL write function

[Buddabing]

Buddabing,
I think I found a bug.  Not  really a big deal, but should work.

If you run mame with the -ftr command, i.e. mame pacman -ftr 100
you get the following error after mame runs:

libpng error: Call to NULL write function

The bug is in the screen shot generator. -ftr makes a screen shot at the end of its run.

I'll fix it asap.

[2600]

Not sure if this is a bug or a new feature.

In the old patch, if you had a controls.png file in /artwork/romname/ the controls would display.  In the latest patch, this doesn't work.  If I recall, the controls.png in /artwork/romname/ took priority over the local  controls.png

Did you take this feature out?

[Buddabing]

Not sure if this is a bug or a new feature.

In the old patch, if you had a controls.png file in /artwork/romname/ the controls would display.  In the latest patch, this doesn't work.  If I recall, the controls.png in /artwork/romname/ took priority over the local  controls.png

Did you take this feature out?

No, it should still search the artwork directory. However, if you want it to do that you must have -nointmakectrl and -noextmakectrl set.

[2600]

Ahhh, works just like you said.  Thanks.

[2600]

Buddabing, been doing some thinking and poking and wanted your opinion since you've dug your hands in deeper than mine.

Using an art layer like the bezel is a performance hit.  Possibly a pretty substantial one.  Looking at the code I think it's possible and wouldn't be an impact on performance if the image is displayed like the UI menu or warnings are displayed.  I don't mean menu text based, but the way in which the UI layer in the artwork is displayed as compared to the way the bezel layer is displayed.

Any thoughts or am I a bit off track?

[Buddabing]

Buddabing, been doing some thinking and poking and wanted your opinion since you've dug your hands in deeper than mine.

Using an art layer like the bezel is a performance hit.  Possibly a pretty substantial one.  Looking at the code I think it's possible and wouldn't be an impact on performance if the image is displayed like the UI menu or warnings are displayed.  I don't mean menu text based, but the way in which the UI layer in the artwork is displayed as compared to the way the bezel layer is displayed.

Any thoughts or am I a bit off track?

I suppose it's possible to display the image like the UI menu. But why bother? Since the game is paused, I don't think the user will care if it takes 0.05 seconds to display the artwork (20 fps) or else 0.01 seconds (100 fps), or even 0.25 seconds (4 fps).

And I don't see a performance hit when the controls artwork is not being displayed.

The only reason I can see for the UI menu-like display would be to display for-sure accurate aspect ratios with the controls artwork. So I'll look at it and experiment a bit to see if it can be done.

[2600]

Sorry let me clarify a bit.   Bear with me a little and correct me where I am wrong.

A.  I'm not talking about how long it takes to display.  This doesn't bother me either.
B. I'm not talking about using the menuing system.

When you use the artwork "system" there is a performance hit.  The way I understand the artwork system is when a layer is implemented mame draws the screen and then has to layer and blend the artwork in.  Depending on your pc, You don't notice it because most of the games mame can easily run and you run at the games fps easily.  Other PC's may be barely running some games.  Adding the artwork layer makes a significant hit and since the viewer uses the bezel layer the performance hit is during the whole game not just during pause.

Try running with -nothrottle -noafs and let the game run for 10-20 seconds then esc.  You'll see the fps.  Now try it with -nothrottle -noafs -noart.  The fps is going to be double or more.  Now, I don't care that I can get 400 fps in Pacman, but the some people who are running a game like mk aren't going to be able to just by using the viewer.  This is because the viewer always has the bezel layer on.

Now the reason I brought up the UI and maybe that was the wrong comparison is because that isn't a performance hit.  I believe that all those messages are converted to a bmp and it just displays them when it needs to, i.e the gameinfo screen.  If not, it looks like their are calls that just display a bmp to the screen and that's what I was saying.

As a side benefit, it may be easier for you to write to the whole screen instead of be bound to the box the games is, i.e. pacman.  Which btw I have a pseudo patch for instead of my other hack so that the controls can be displayed on the whole screen for vertical games.

Does that make more sense or am I still off on my descriptions and thoughts?

[Buddabing]

Sorry let me clarify a bit.   Bear with me a little and correct me where I am wrong.

A.  I'm not talking about how long it takes to display.  This doesn't bother me either.
B. I'm not talking about using the menuing system.

When you use the artwork "system" there is a performance hit.  The way I understand the artwork system is when a layer is implemented mame draws the screen and then has to layer and blend the artwork in.  Depending on your pc, You don't notice it because most of the games mame can easily run and you run at the games fps easily.  Other PC's may be barely running some games.  Adding the artwork layer makes a significant hit and since the viewer uses the bezel layer the performance hit is during the whole game not just during pause.

Try running with -nothrottle -noafs and let the game run for 10-20 seconds then esc.  You'll see the fps.  Now try it with -nothrottle -noafs -noart.  The fps is going to be double or more.  Now, I don't care that I can get 400 fps in Pacman, but the some people who are running a game like mk aren't going to be able to just by using the viewer.  This is because the viewer always has the bezel layer on.

Now the reason I brought up the UI and maybe that was the wrong comparison is because that isn't a performance hit.  I believe that all those messages are converted to a bmp and it just displays them when it needs to, i.e the gameinfo screen.  If not, it looks like their are calls that just display a bmp to the screen and that's what I was saying.

As a side benefit, it may be easier for you to write to the whole screen instead of be bound to the box the games is, i.e. pacman.  Which btw I have a pseudo patch for instead of my other hack so that the controls can be displayed on the whole screen for vertical games.

Does that make more sense or am I still off on my descriptions and thoughts?

I see what you're saying now. I have been investigating writing directly to the screen with DirectDraw instead of going through the artwork system. However, this is not machine portable, which makes it not a preferred solution. I'll investigate the UI-hack method when I have some time.

[Buddabing]

Hello,

I have uploaded a new patch. Download it from here.

Here's what's new:

- Bugfix: screen shot crashed mame
- added textconstraint field to the .ini file
  usage: textconstraint,value,
  value=0: text is drawn as large as possible to fit the slot alloted, and as small necessary to fit. (default)
  value=1: text is drawn at the specified font size or smaller to fit the slot alloted.
  value=2: text is drawn at the specified font size no matter what
  value=3: text is drawn at the one largest font size so that all text fits the slots allotted.
- fixed text alignment issues.
- unused controls are dimmed now, not just unused buttons.
- added xmlcache file for tron, the controls.xml uses a joy8way which makes CPMaker draw the incorrect control, I changed it to be an analog stick.

[papaschtroumpf]

You do good work!
Thanks for the update.

Edit: di you fix the TfontSize thing in parsing johnny5 files?

[Buddabing]

Sorry let me clarify a bit.   Bear with me a little and correct me where I am wrong.

A.  I'm not talking about how long it takes to display.  This doesn't bother me either.
B. I'm not talking about using the menuing system.

When you use the artwork "system" there is a performance hit.  The way I understand the artwork system is when a layer is implemented mame draws the screen and then has to layer and blend the artwork in.  Depending on your pc, You don't notice it because most of the games mame can easily run and you run at the games fps easily.  Other PC's may be barely running some games.  Adding the artwork layer makes a significant hit and since the viewer uses the bezel layer the performance hit is during the whole game not just during pause.

Try running with -nothrottle -noafs and let the game run for 10-20 seconds then esc.  You'll see the fps.  Now try it with -nothrottle -noafs -noart.  The fps is going to be double or more.  Now, I don't care that I can get 400 fps in Pacman, but the some people who are running a game like mk aren't going to be able to just by using the viewer.  This is because the viewer always has the bezel layer on.

Now the reason I brought up the UI and maybe that was the wrong comparison is because that isn't a performance hit.  I believe that all those messages are converted to a bmp and it just displays them when it needs to, i.e the gameinfo screen.  If not, it looks like their are calls that just display a bmp to the screen and that's what I was saying.

As a side benefit, it may be easier for you to write to the whole screen instead of be bound to the box the games is, i.e. pacman.  Which btw I have a pseudo patch for instead of my other hack so that the controls can be displayed on the whole screen for vertical games.

Does that make more sense or am I still off on my descriptions and thoughts?

The UI text is displayed using the same code as the game sprites. In theory it should be possible to read in the controls.png file as one big sprite. This might be advantageous, after all we never see the game options and the other UI text stretched in one direction or the other. Memory used would be roughly the same as storing the controls.png as artwork.

The downside is that I'm unfamiliar with the sprite architecture. The sprites are pretty complicated, the code has to handle many different sizes and depths of sprites. I'm not saying it can't be done, it'll just require quite a bit of study. Unless, of course, you can figure it out.

You mentioned you had some kind of code to display the artwork on the whole screen. I would like to see it.

[Buddabing]

You do good work!
Thanks for the update.

Edit: di you fix the TfontSize thing in parsing johnny5 files?

Whoops, forgot that one.  

I fixed it for the next update.

[2600]

The UI text is displayed using the same code as the game sprites. In theory it should be possible to read in the controls.png file as one big sprite. This might be advantageous, after all we never see the game options and the other UI text stretched in one direction or the other. Memory used would be roughly the same as storing the controls.png as artwork.

The downside is that I'm unfamiliar with the sprite architecture. The sprites are pretty complicated, the code has to handle many different sizes and depths of sprites. I'm not saying it can't be done, it'll just require quite a bit of study. Unless, of course, you can figure it out.

You mentioned you had some kind of code to display the artwork on the whole screen. I would like to see it.

I'll look into the sprite thing, but it'll probably take some time as I just haven't used C in a long time.  Don't wait up for me if you get the time, and I'll let you know how it goes.

Displaying the artwork on the whole screen isn't hard and hopefully isn't too ugly.  Did you read or ever try the bezel hack I did:
http://www.arcadecontrols.org/yabbse/index.php?board=3;action=display;threadid=26727

Basically, it just doing that in the code.  In artwork.c you pretend to parse a controls.art.  So for vertical games you put the value's for left,top,right,bottom in there.   Then for vertical games I immediately returned from "adjust_controls_aspect_ratio".  I'd send you a patch, but was just doing testing and didn't put in the check for horizontal or vertical, just ran vertical games to prove the theory.  For horizontal games, you should do what you are currently doing.

I'll send you a patch if you want, though.

Edit: In English this is how I understand it.  You've defined the bezel layer as big as the game screen and as I mentioned before the bezel artwork layer is then enabed and always on.  If you read the top of artwork.c, they tell you how to enlarge that for bezels.  So adding this code or using the universal vertical bezel is enlarging that bezel area past the screen size.

[2600]

I just tried the updated patch on a clean source and got the following error.  Hopefully, it's not me being dumb.

Compiling src/cpmaker/magick/display.c...
Compiling src/cpmaker/magick/montage.c...
src/cpmaker/magick/montage.c:2442: redefinition of `CloneMontageInfo'
src/cpmaker/magick/montage.c:101: `CloneMontageInfo' previously defined here
src/cpmaker/magick/montage.c:2504: redefinition of `DestroyMontageInfo'
src/cpmaker/magick/montage.c:163: `DestroyMontageInfo' previously defined here
src/cpmaker/magick/montage.c:2555: redefinition of `GetMontageInfo'
src/cpmaker/magick/montage.c:214: `GetMontageInfo' previously defined here
src/cpmaker/magick/montage.c:2614: redefinition of `MontageUsage'
src/cpmaker/magick/montage.c:273: `MontageUsage' previously defined here
src/cpmaker/magick/montage.c:2723: redefinition of `MontageImageCommand'
src/cpmaker/magick/montage.c:382: `MontageImageCommand' previously defined here
src/cpmaker/magick/montage.c:4089: redefinition of `GetMontageGeometry'
src/cpmaker/magick/montage.c:1748: `GetMontageGeometry' previously defined here
src/cpmaker/magick/montage.c:4106: redefinition of `SceneCompare'
src/cpmaker/magick/montage.c:1765: `SceneCompare' previously defined here
src/cpmaker/magick/montage.c:4122: redefinition of `MontageImages'
src/cpmaker/magick/montage.c:1781: `MontageImages' previously defined here
MAKE: *** [obj/mamepp/cpmaker/magick/montage.o] Error 1

[papaschtroumpf]

It built cleanly for me, so unless the patch the post above links to has changed since it was posted, it must be operator error.

[Buddabing]

I just tried the updated patch on a clean source and got the following error.  Hopefully, it's not me being dumb.

Compiling src/cpmaker/magick/display.c...
Compiling src/cpmaker/magick/montage.c...
src/cpmaker/magick/montage.c:2442: redefinition of `CloneMontageInfo'
src/cpmaker/magick/montage.c:101: `CloneMontageInfo' previously defined here
src/cpmaker/magick/montage.c:2504: redefinition of `DestroyMontageInfo'
src/cpmaker/magick/montage.c:163: `DestroyMontageInfo' previously defined here
src/cpmaker/magick/montage.c:2555: redefinition of `GetMontageInfo'
src/cpmaker/magick/montage.c:214: `GetMontageInfo' previously defined here
src/cpmaker/magick/montage.c:2614: redefinition of `MontageUsage'
src/cpmaker/magick/montage.c:273: `MontageUsage' previously defined here
src/cpmaker/magick/montage.c:2723: redefinition of `MontageImageCommand'
src/cpmaker/magick/montage.c:382: `MontageImageCommand' previously defined here
src/cpmaker/magick/montage.c:4089: redefinition of `GetMontageGeometry'
src/cpmaker/magick/montage.c:1748: `GetMontageGeometry' previously defined here
src/cpmaker/magick/montage.c:4106: redefinition of `SceneCompare'
src/cpmaker/magick/montage.c:1765: `SceneCompare' previously defined here
src/cpmaker/magick/montage.c:4122: redefinition of `MontageImages'
src/cpmaker/magick/montage.c:1781: `MontageImages' previously defined here
MAKE: *** [obj/mamepp/cpmaker/magick/montage.o] Error 1

I think your patch went bad. Montage.c is only 2341 lines long. My guess is that your montage.c got doubled. See if the code repeats after line 2340 or so.

Do any other files spit out errors?