MAME patch: mapping a video option to an input (keystroke)

[shock_]

Since my cocktail has asymmetric controls, sometimes I need the game video to rotate 180° so Player 1 is on the other side of the table.  Game by game, this can be achieved trivially in the video options menu, but ideally I'd like to map this to a keystroke rather than dig around in the admin functions, especially for guests.

Before I teach myself enough C to write the patch myself (ugh!) can anyone else remember somebody trying this before?

So to clarify, I thought the way to do it was to find in the source the video options rotate function, and find the UI stuff, create a function that rotates twice, then create a new input control, then in the GUI map that control to a button.

Thoughts?

[loadman]

Sorry I don't have the answer   

Before I teach myself enough C to write the patch myself

But C'mon...!   

You know you want to   

Download Free Visual C++   HERE


Have fun   

[shock_]

This could probably be handy for others if adapted as way to, say, toggle bezels or overlays. But for me, to be honest this is probably a stopgap until I finish switching ROM cfgs one at a time...

For the uninitiated I have a two-sided cocktail with a rotating monitor.  Spinner and 1 joystick on one side, trackball and two joysticks on the other.  Player 1 is toggled to be either on the first side, or the left joystick on the second side. Click my sig for more, or just look at a diagram   The true bottom of the screen faces the side with the two joysticks.

My ultimate goal here is:
 1. to have each game load in its correct orientation (horizontal or vertical)
 2. each game facing the correct panel for the controls required (eg. Arkanoid always rotated 180° to face the spinner side)
 3. for cocktail flipping to be enabled for games that support it - EXCEPT where spinner or trackball are used, since my panels aren't identical

Requirement 1 is achieved using mame.ini with the following:

Code: [Select]

#
# CORE ROTATION OPTIONS
#
rotate                    0
ror                       0
rol                       0
autoror                   1
autorol                   0
flipx                     0
flipy                     0

"rotate 0" prevents vertical games playing horizontally, thereby forcing guests to play Galaga full-screen and ensuring all that swearing and frustration I had in building a rotating cocktail wasn't for nothing

"autoror 1" makes each vertical game rotate clockwise - some people may be unaware, like I was, that some vertical games expected the monitor mounted the other way.  autoror forces all vertical games to rotate the same way, which is pretty critical for a monitor that only rotates 90° in one direction!

Requirement 2 can be achieved a few ways no doubt, and the two I've figured out are:

• manually hitting every paddle/dial game, rotating via video options which creates/updates the game's .cfg file
• using something like ROMLister to separate all horizontal AND spinner games, then move the ROMs to a new subdirectory, and using MaLa's excellent conditional command line capability to set up something like "If ROM path is "roms/horizontal-spinner" then execute MAME with the additional command line options "-flip x -flip y" - and something similar for vertical spinners etc.
  
  I've found that ROMLister doesn't work 100% for that, at least the way I'm querying it - because some games show up as 'dial control' when really they're rotating joysticks etc. eg. Ikari Warriors... But it's a good start.

Requirement 3 is the really interesting one.  See another thread for some discussion about the difficulty in easily enabling cocktail flipping across a large ROMset.  It's a game-by-game thing, since it is normally DIP switch controlled.  I've flipped plenty manually, just to get me by, but one day I still hope to make, or at least start, a definitive diff set for CFGs to help out some other cocktail owners.  I need to be careful though, since cockail flipping is UNdesirable for trackball or spinner games, eg. Centipede.

...So this whole question of a MAME patch is to facilitate requirement 2.  I have 30 people here next weekend, and I would rather say "hit those two buttons if you need to flip the screen around" than jumping in with my secret Shazaam! key combos to reach the MAME user interface and fixing game after game all night.

Before I teach myself enough C to write the patch myself

But C'mon...!   

You know you want to   

Download Free Visual C++   HERE

Yeah yeah, I haven't written any "real" code since some Pascal about 20 years ago (admitting that, now I know you're going to nag me to switch to Delphi and churn out some plugins).  I really should finish learning JavaScript and PHP first though, since those are directly applicable to my job

[MKChamp]

Here's a qucik way to assign a key to flip the screen...this is the 'easy' way out...not much 'patching' involved...but it gets the job done.
You want to add this in the ui.c file which will be in the src/emu dir.

First just add the following with the other includes at the top of the file:
#include "rendutil.h"

Then, scroll down and find a 'function' you won't be using...like toggle crosshair...for this we will use that. FYI, toggle crosshair is F1 key by default. Just make this section look like this:
/* toggle crosshair display */
if (input_ui_pressed(IPT_UI_TOGGLE_CROSSHAIR))
{
/*video_crosshair_toggle();*/
render_container_set_orientation(render_container_get_screen(0), orientation_add(ROT90, render_container_get_orientation(render_container_get_screen(0))));
render_container_set_orientation(render_container_get_ui(), orientation_add(ROT90, render_container_get_orientation(render_container_get_ui())));
}

And that is it. You can go into the configure menu and assign toggle crosshair to any key you want. If you want it to flip it 180 or 270 degrees with each keypress, just change the ROT90 to ROT180 etc.
Also, if you use toggle crosshair, just find some other one that you'd never use like /* toggle movie recording */ section...and just make it look like this:
if (input_ui_pressed(IPT_UI_RECORD_MOVIE))
{
render_container_set_orientation(render_container_get_screen(0), orientation_add(ROT90, render_container_get_orientation(render_container_get_screen(0))));
render_container_set_orientation(render_container_get_ui(), orientation_add(ROT90, render_container_get_orientation(render_container_get_ui())));
}

Make sure the render_container_set is all on 1 line...when I previewed this post, the (0)))); was on it's own line...but it is really a continuation on the above line...

I hope this is what you were asking for...I must be honest...I didn't read all of your 'long' post ;-)

[shock_]

That sounds fantastic!  I'll give it a go and recompile tonight. And re-using an existing irrelevant function is a good idea.

I hope this is what you were asking for...I must be honest...I didn't read all of your 'long' post ;-)

Hell - I wrote it and now that it is out there, it even bores me to look at it!

Thanks for your help.   

[shock_]

Well that works

The behaviour of the "rotate view" item from the video menu is to rotate the game a (further) 90°, and write to the game's .cfg.

This patchy/hack operates on the entire video system it seems, effecting the same change as a "-flipx -flipy". ie. even MAME's UI screens invert themselves.

I thought it might be handy to put in the .cfg write in there as well so it could be a "fix once" sort of thing, so I #included config.h and appended what I guessed as the right function:

Code: [Select]

if (input_ui_pressed(IPT_UI_RECORD_MOVIE))
{
render_container_set_orientation(render_container_get_screen(0), orientation_add(ROT180, render_container_get_orientation(render_container_get_screen(0))));
render_container_set_orientation(render_container_get_ui(), orientation_add(ROT180, render_container_get_orientation(render_container_get_ui())));
config_save_settings();
}

To my surprise, it compiled - but didn't seem to work.  Any further hints? 

[MKChamp]

Ok..so you wanted it to work more 'officially' ;-)
Here's what you need to do. This is all done in the ui.c file...

Add render_target *target; right under
static UINT32 handler_ingame(running_machine *machine, UINT32 state)
{

and before
int is_paused = mame_is_paused(Machine);

So it looks like this:
static UINT32 handler_ingame(running_machine *machine, UINT32 state)
{
    render_target *target;
    int is_paused = mame_is_paused(Machine);

Then change your section for record movie to look like this:
if (input_ui_pressed(IPT_UI_RECORD_MOVIE))
{
target = render_target_get_indexed(0);
render_target_set_orientation(target, orientation_add(ROT180, render_target_get_orientation(target)));
render_container_set_orientation(render_container_get_ui(), orientation_add(ROT180, render_container_get_orientation(render_container_get_ui())));
}

You don't need the config_save_settings() part...it will save automatically when exited.

[shock_]

 

Will give this a go later.  Thanks again - your code contributions are making my life and a bunch of other people's much much happier

[shock_]

Line 1231 in mameV122 (stable) is actually
static UINT32 handler_ingame(UINT32 state)

but the patch works just fine thanks very much

[MKChamp]

Line 1231 in mameV122 (stable) is actually
static UINT32 handler_ingame(UINT32 state)

but the patch works just fine thanks very much

Yea, I was using the u7 source...
Glad I could help...have fun!

[Popcorrin]

Mapping the rotate function to a single key is a great idea!  I would like to be able to do the same thing with the -view cocktail option but after looking at the source, the changes don't seem to be as clearcut as the rotate function.

I was wondering if MKChamp or someonce else would have any input on this?

Thanks

[MKChamp]

Mapping the rotate function to a single key is a great idea!  I would like to be able to do the same thing with the -view cocktail option but after looking at the source, the changes don't seem to be as clearcut as the rotate function.

They aren't ;-)
Ok...this isn't pretty...but it toggles between "Cocktail" and "Standard XX:XX" views. This is all done in the emu/ui.c file...and tested with 125u3 source(should work fine for any fairly new source). Like stated in earlier posts, I am 'reusing' code, so I pasted this in the record movie function...but you can paste it in any function you don't plan on using.

3 simple additions:

1) Add #include "rendutil.h" to the top with all the other includes

2) Add render_target *target; right under
static UINT32 handler_ingame(running_machine *machine, UINT32 state)
{
and before
int is_paused = mame_is_paused(Machine);
So it looks like this:
static UINT32 handler_ingame(running_machine *machine, UINT32 state)
{
    render_target *target;
    int is_paused = mame_is_paused(Machine);


3) Then change your section for record movie to look like this:
if (input_ui_pressed(machine, IPT_UI_RECORD_MOVIE))
   {
      char viewname[32];
      int viewnum;
      int curview;
      int switched;
      target = render_target_get_indexed(0);
      curview = render_target_get_view(target);
      strcpy(viewname, "Cocktail");
      switched = 0;
      /* find the view */
      for (viewnum = 0; viewnum < 1000; viewnum++)
      {
         const char *testname = render_target_get_view_name(target, viewnum);
         if (testname == NULL)
            break;
         if (!strcmp(viewname, testname))
         {
            if (viewnum != curview)
            {
               render_target_set_view(target, viewnum);
               switched = 1;
               break;
            }
         }
      }
      if (!switched)
      {
         strcpy(viewname, "Standard");
         for (viewnum = 0; viewnum < 1000; viewnum++)
         {
            const char *testname = render_target_get_view_name(target, viewnum);
            if (testname == NULL)
               break;
            if (0 == strncmp(testname, viewname,8))
            {
               render_target_set_view(target, viewnum);
               break;
            }
         }
      }
   }

And that is it!
A side note...in one of the 125u releases they changed the if statement from if (input_ui_pressed(IPT_UI_RECORD_MOVIE)) to
if (input_ui_pressed(machine, IPT_UI_RECORD_MOVIE))

Just use whatever is currently in your ui.c file.

Hope that is what you were wanting!

[Popcorrin]

That was exactly what I was looking for and it works perfectly. 
Thank you. 

[Popcorrin]

I noticed a couple of minor issues with the cocktail toggle. 

The first issue really has me baffled.  After playing a game for awhile the display switches from the cocktail view to the standard view and I haven't a clue why.  It seems like it happens about 10 minutes into a game or so.

The second issue is that after you toggle the cocktail mode on and exit a game and then reload the game the cocktail mode is active but if you exit the game again and then reload the game, the cocktail mode is no longer active. 

I personally would prefer that it didn't save the setting at all but if it is going to save the setting then I would prefer that it saves it until you toggle it off.   

[MKChamp]

I got your pm stating that the first issue was most likely due to your U360. As far as your second issue goes, I was unable to reproduce it using 126 source. I've attached the ui.c module (rename it from .txt). Compile with this and see if it acts the same or not. If it doesn't, try to diff the ui.c I posted with the ui.c you modified to determine what's up!
FYI...be sure to use the latest 126 MAME source...

[Popcorrin]

I compiled 126 with your ui.c file and it seems to work fine.
 I made the changes to 117 originally so I'm guessing that is why I got that behavior.  Is there anyway to change it so that it doesn't save the view setting in the cfg file?

Thanks

P.S.  Compiling hung on the ui.c file.  I had to comment out
video_frame_update_hi(machine, FALSE);

[MKChamp]

Sorry...I grabed it from my source(has hiscore support).
Just change video_frame_update_hi(machine, FALSE); to video_frame_update(machine, FALSE); and it will compile...

[Popcorrin]

I figured it had something to do with that.

Is there anyway to change the code so that it doesn't save the view setting in the cfg file?  That way everytime you load a game it would start in the standard view regardless of the state it was in when you exit the game.

[MKChamp]

I figured it had something to do with that.

Is there anyway to change the code so that it doesn't save the view setting in the cfg file?  That way everytime you load a game it would start in the standard view regardless of the state it was in when you exit the game.

This is done in the config.c module. I have attached it with the 2 code blocks you will need to add. Both blocks start and end with "MKChamp" so you can find them easily. Just copy and paste in the same same void routine for whatever source version you are using. What it does is set the view back to "Standard" before saving the cfg for the game. I hope this gets you going!

[Popcorrin]

Wow awesome.  Works perfectly. 

Thanks for taking the time to do this for me.

If I want it to save the view as "cocktail" instead of standard do I have to change much?

[MKChamp]

You're welcome.
If you want it to automatically save it as cocktail rather than standard, in the config.c file just replace:
"Standard"
     with
"Cocktail"

And that's it.

Have fun!