CabMame

[Gray_Area]

These parameters can be entered and saved in each game's ini file, and the entries should remain.

[EvilDindon]

These parameters can be entered and saved in each game's ini file, and the entries should remain.

Oh, I thought that the OSD options were saved to the .cfg file in the cfg folder ?

You mean that I set some of the video parameters I need for certain games in the ini file of the game ?

[bitbytebit]

I have 64 bit builds now too, just put up a new 32 and 64 bit build that also includes patches for reducing input lag that Calamity developed.  They are version 0141 of mame, since the 0141u1 seems to have bugs which make me not so happy with certain games like mario containing a terrible noise when he runs instead of the proper one.

[newmanfamilyvlogs]

http://mario.groovy.org/GroovyArcade/MameWindows/mame0141_64.7z

That makes me very happy. Thank you.

Will you continue with 64bit builds in the future?

[bitbytebit]

http://mario.groovy.org/GroovyArcade/MameWindows/mame0141_64.7z

That makes me very happy. Thank you.

Will you continue with 64bit builds in the future?

Yep, I now have an xp64 development and mame test system to allow building both.

[Gray_Area]

These parameters can be entered and saved in each game's ini file, and the entries should remain.

Oh, I thought that the OSD options were saved to the .cfg file in the cfg folder ?

You mean that I set some of the video parameters I need for certain games in the ini file of the game ?

No. They never have.

I think if savestates are enabled, video settings in the tab menu will be re-enabled on next game loading. '`' settings (brightness, gamma, etc) will not, regardless. They must be set in MAME ini, or each game's ini. Or you can use MAMEUI to set them without digging into file directories.....

[bitbytebit]

I compiled new 0141u1 executables containing a fix for the discrete audio issues in dkongjr/mario/asteroids/galaxian, both 64 and 32bit versions up now.

[ahofle]

Wow I can't believe I missed this.  How is this not stickied somewhere?!  It should have its own forum, ala PowerMAME!
I'm going to give this build a shot.  Thanks for your work.

[RVZ]

Thanks, will give the 64bit version a go.  Hopefully it will sort out my tearing issues...

[RVZ]

I tried the 64bit version now, but all the games are in a widescreen resolution, and the gamespeed is too fast.  Am I doing something wrong?

[bitbytebit]

I tried the 64bit version now, but all the games are in a widescreen resolution, and the gamespeed is too fast.  Am I doing something wrong?

It might be an issue with vsync not working on your card, setup, drivers.  It seems to not always work with every setup, you might want to try to enable triplebuffer for that.  The widescreen sounds like either stretching or d3d is enabled instead of ddraw?  Depends on the monitor/video card combination and what mame.ini says basically (might want to recreate a new mame.ini with this mame version if didn't already, the defaults are different in it).  Some one had an issue with vsync not working and it was the video card driver install or something and had to be re-installed a few times till the direct draw info said it had vblank/vsync capability.

[retrorepair]

Are you not releasing the diffs anymore? Would be useful since I need to also add the hack for guncons/wiimotes to work.

[bitbytebit]

Are you not releasing the diffs anymore? Would be useful since I need to also add the hack for guncons/wiimotes to work.

The diffs are all in the git repository, but I'm keeping this current from now on.  Don't use the last switchres.diff patch though, it's super alpha and will not work ;-).

http://mario.groovy.org/GroovyMame/

Hopefully in the next couple weeks I'll have it so mame can create modelines, and modify running modelines resolutions like how advanced mame did.  Well doing it like switchres does actually so more following standard system API/Soft15khz modelines, and possibly able to use powerstrip for non-radeon cards or ones newer than that hd4xxx series.  Right now though the switchres patch will not work, I'm working on that.

[retrorepair]

That's great, thanks. Thanks for picking this up too, cabmame is almost necessary for the psx games.

How do I disable soundsync though? I tried soundsync 0 in the ini but no dice.

[bitbytebit]

That's great, thanks. Thanks for picking this up too, cabmame is almost necessary for the psx games.

How do I disable soundsync though? I tried soundsync 0 in the ini but no dice.

That's a good question , I've noticed that before, no soundsync option and it's hardwired.  I had changed the froggerhack in this build to be able to turn off, I'll look into also having soundsync able to turn off.

[retrorepair]

That's great, thanks!

It pains me to hear gradius ii like that 

[bitbytebit]

That's great, thanks!

It pains me to hear gradius ii like that 

I've got a version 0141u3 up now, 32 bit windows build uploaded and 64 bit build in less than an hour, patches are up.  There's a difference with this patch, I've rewritten the cabmame patches to hopefully work a bit nicer and no longer need really any extra parameters plus work right into my switchres code if you have Soft15khz and a Radeon card. 

I now have the soundsync option able to turn off by -nosoundsync, all other cabmame options don't even need command line options anymore and enable themselves only if needed.  Also now for example the frogger/galaxian hack, allows the OSD to display on the screen properly, which is nice for the setup/configuration of those games.  I've basically redone the cabmame patches in this version completely, so they are now part of 'groovymame' and hopefully work really well with arcade monitors and ATI Radeon cards.

http://mame.groovy.org/0141u3/

Definitely a bit of a leap, big change, so looking for testing and bug reports on any issues with this.

[retrorepair]

Fantastic, thanks for this 

I'll get testing for you.

- Includes functionality for cabmame but completely rewritten to improve
   switchres ability.

Will this ever be able to use more than one core/hyper threading? Or would that involve some serious rewriting?

[bitbytebit]

Fantastic, thanks for this 

I'll get testing for you.

- Includes functionality for cabmame but completely rewritten to improve
   switchres ability.

Will this ever be able to use more than one core/hyper threading? Or would that involve some serious rewriting?

Yes, it should already be able to use all cores/hyperthreading (to the limits of mame of course) automatically even with waitvsync on.  It's got some changes to allow threading with vsync, and I enable multithreading  and vsync in these builds normally by default.

[retrorepair]

I mean with switchres since some games crash the system when using it with more than one core/hyperthreading (Tekken Tag for example)

[bitbytebit]

I mean with switchres since some games crash the system when using it with more than one core/hyperthreading (Tekken Tag for example)

Interesting, I didn't realize it did that, well hopefully it's working now with things all put into mame itself.  What is the rom name to use for that, I just tried tekken here and it works so maybe that's a good sign .  I'm not sure fully how the multithreading would break those, it might be the actual combination of command line args to mame it's using.  One thing to test would be to use the argument to switchres --verbose 5 and then check the command line /mame command being used, then launch it separately just running mame with the same args and just to see if that crashes.  Then proceed to remove some args, like -mt possibly is a candidate, and figure out what exactly causes it.  Hopefully though it works now  just fine, but I'll be checking into this more too since definitely sounds odd.

Thanks for letting me know about that.

[retrorepair]

No worries. I'll check it in a bit and let you know how I get on.

Gradius 4 also behaves very strangly when you put it in 15khz mode using switchres, but I'd assume that's because MAMEdev never added the support for it sine MAME shouldn't "officially" change modes on the fly. Odd if you ask me since lots of games do it, especially the PSX driver.

[retrorepair]

Hmm well Tekken no longer switches resolutions on the fly, nor any other psx game. I'm not sure off the top of my head which other games were an issue.

From your description it shouldn't need any changes to the ini or command line switches right?

[bitbytebit]

Hmm well Tekken no longer switches resolutions on the fly, nor any other psx game. I'm not sure off the top of my head which other games were an issue.

From your description it shouldn't need any changes to the ini or command line switches right?

Yeah there's some resolution switching issue it seems, I'm going to have to look at that, since I use Linux with SDL it can't switch anyways but in Windows the code seems to fail now on switching compared to how it acted before.  I'd like to get both working better in actually creating new resolutions for the resolution switches, which before it was just finding another close one and should be able to actually create the new ones just like the first one is created for a game.  Since I altered the way the  whole  cabmame patches work, I'm guessing it's related to that, which was partly due to the fact now with changes in mame 0141u3 the changeres part was really hard to do with changes to the mame options plus changeres always broke scaling for games requiring stretching and so I tried to get things closer to things working better but there's still work to do it seems.

[retrorepair]

Actually, it seems it's not patching a lot of the files when applying the groovymame diff. This is the first of many errors:

C:\mame source>patch -p0 -E <0141u3_groovymame.diff
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/makefile b/makefile
|index 2f7cd20..deda461 100644
|--- a/makefile
|+++ b/makefile
--------------------------
File to patch:

Is this maybe set up for your system and you forgot to change it? I am applying the diffs in the order you recommend.

[bitbytebit]

Actually, it seems it's not patching a lot of the files when applying the groovymame diff. This is the first of many errors:

C:\mame source>patch -p0 -E <0141u3_groovymame.diff
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/makefile b/makefile
|index 2f7cd20..deda461 100644
|--- a/makefile
|+++ b/makefile
--------------------------
File to patch:

Is this maybe set up for your system and you forgot to change it? I am applying the diffs in the order you recommend.

It's because the diffs need the -p1 option, instead of -p0.  That's probably the issue there, the build binaries' should be fine though, basically by default with a git repository it uses -p1 depth to do diffs and all the hi_score/mame patches always use -p0 so it requires a different -p option.  I probably should change this to use -p0, I'm right now just using the default git -p1 option which actually is the default.

[retrorepair]

Ah I see. I tried -p1 though and got:

C:\mame source>patch -p1 -E <0141u3_groovymame.diff
patching file makefile
Assertion failed: hunk, file patch-2.5.4/patch.c, line 343

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

Do I need anything added to mingw to compile this? Your previous patches worked fine by the way.

[bitbytebit]

Ah I see. I tried -p1 though and got:

C:\mame source>patch -p1 -E <0141u3_groovymame.diff
patching file makefile
Assertion failed: hunk, file patch-2.5.4/patch.c, line 343

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

Do I need anything added to mingw to compile this? Your previous patches worked fine by the way.

Ah strange, I'll have to look at that closer, not sure why it's having that error.  The binaries/builds I have up should be fine though for now in Windows and essentially be the exact same as any self-compiling (since in Windows there's no difference between systems/libraries, and my patches should all be comprehensive and no others should be added currently), I'm guessing it might be something todo with line ending differences or some other oddity like that between Linux and Windows end of line formatting stuff.  I'll have to do some tests and see if I can sort out why it's not patching properly in a Windows environment.

[retrorepair]

Fair enough, I only wanted to compile to add the support for raw direct input so I could use a guncon. I'll stick to the binaries for now then

[bitbytebit]

Fair enough, I only wanted to compile to add the support for raw direct input so I could use a guncon. I'll stick to the binaries for now then

I'll work on fixing them, odd how the patches this time came out kinda odd for Windows patching (work fine in Linux, and think they do technically work in Windows but there's something odd still preventing them from working without the exact right handling).  but where are these patches for guncon raw direct input?  I'd be interested in adding them possibly. 

[retrorepair]

It's in "osd/windows/input.c" and the label is "force_directinput". It's just a switch. It forces MAME to read raw direct input like it used to. Guncons (and maybe some other lightguns) won't work without it.

BTW I tested the new build, switchres works great and the options now show up in the ini as they should. FYI, dual core does work ok with this, but when enabling multithreading, it crashes mame upon resolution switch in certain drivers (it can hang your computer too so watch out )

soundsync still won't go away though. I see the option in the ini to disable it but it's defaulted to 0. I even tried to remove that completely but still no change.

[Calamity]

BTW I tested the new build, switchres works great and the options now show up in the ini as they should. FYI, dual core does work ok with this, but when enabling multithreading, it crashes mame upon resolution switch in certain drivers (it can hang your computer too so watch out )

Hi retrorepair, could you tell us which specific drivers were making mame crash? I'm interested to test that here to try to find the bug.

BTW, the problems you reported when applying the patches are the same I had, I'm using MameCompiler64 to build the binaries and applying patches. So I'm interested in applying the patches myself to be able to build groovymame here and maybe find out what's making it crash with resolution switching.

[retrorepair]

Just grab the binaries for now, the patches won't work for you at the moment.

The PSX drivers are definitely affected, I'm not sure what other games switch resolutions after boot though. I seem to remember R.Belmont saying it had something to do with a conflict with PPC type hardware but I can't find reference to it on mameworld forums anymore so I could be totally wrong.

[bitbytebit]

I just re-uploaded new patches, slightly done differently so now take  the -p0 option and also made sure I applied the hiscore_linux -> groovymame one in the same git tree.  I had them so they could be mutually exclusive of each other which might have caused the Windows patch program to not be able to handle applying.  They worked in Linux most likely because it's a newer version of patch which has better fuzzy logic at figuring out where to properly place the code, I suspect the Windows one is older or a different branch and isn't able to do that.  So I'm pretty sure these should work now in Windows, basically went through the exact same method I used before, didn't think about the patch program not being able to handle it.

Also, after checking, it's weird because soundsync should only be used if specified at the command line/ini file and if the vertical frequency is not able to be matched, otherwise it's forced off.  So sounds strange, not sure if possibly something else is happening, but from the code logic I can't see how it's occurring.  I did make a few changes here to try and double check it's always off by default, I'm reworking a few things, added dual monitor support now (where it'll now check and not make up for dual monitor games in the resolution anymore if you specified more than one screen with the numscreens option). 

Also should I enable the direct input all the time, or is that something that not everyone would want?  I saw a thread on mame world about it and seems it might be something I shouldn't enable by deafult, although it could in theory be turned into an option although not sure how 'intrusive' it'll be to do that and if it'll increase the work to keep up per mame versions or not and might be left I'm guessing set as is and changed manually at compile.

[Calamity]

Patches are working now, it's compiling...

I'm sure I was testing the soundsync option on/off and it was working as expected, at least here.

[bitbytebit]

Patches are working now, it's compiling...

I'm sure I was testing the soundsync option on/off and it was working as expected, at least here.

I think I found the possible issue with the soundsync option, I'm going to upload update patches here in awhile.  I am guessing it's from me not defining that arg for soundsync as boolean and probably wasn't able to turn it off possibly in all situations.

[bitbytebit]

Patches are working now, it's compiling...

I'm sure I was testing the soundsync option on/off and it was working as expected, at least here.

I think I found the possible issue with the soundsync option, I'm going to upload update patches here in awhile.  I am guessing it's from me not defining that arg for soundsync as boolean and probably wasn't able to turn it off possibly in all situations.

I updated the patches with the fix to the soundsync option, should behave properly now and is off by default.  Also by default changeres is off too and you have to turn it on yourself now so you can turn it off/on depending if the game can handle it.  I added the following options again, so now can toggle a few settings like in cabmame, except note the redraw option really only is either 0 for off or 2+ depending on if you want to double/triple the refresh rate.  Seemed best to leave it doing it that way, with the modeline enabled it automatically sets it.  All these options except changeres are like that and mostly don't have to be touched.  I'm going to go through and probably improve upon the way all that works, but at least this should allow soundsync to actually be turned off and also utilize the cabmame part even when the switchres/modeline part is turned off.

[retrorepair]

That's great, I'll get testing this later on 

Thanks again bitbytebit!

[Calamity]

Hi bitbytebit,

I'm testing a workaround for the changeres patch, it consists on replacing the patch in window.c with this one:

Code: [Select]

// Resolution change
if (window->machine->switchRes.resolution.changeres == 1) {
window->machine->switchRes.resolution.changeres = 0;
winwindow_toggle_full_screen();
winwindow_toggle_full_screen();
}

This change seems to do the trick for both multithreading on/off. I'm testing it here with ga2 and tgmj and it's working, I still need to test it on my cab to see if it has some side effect or not.

[Calamity]

I needed to add this so the changeres patch finally works properly. Before, it only worked when OPTION_MODELINE was not true, that's why it was working on my desktop computer but not on my cab where that option get's enabled automatically when it finds registry modelines, so the Switchres engine was forcing the resolution width/height options and then the ddraw pick_best_mode was always resulting in the initial resolution overriding the changeres option.

Code: [Select]

// Resolution change
if (window->machine->switchRes.resolution.changeres == 1) {
window->machine->switchRes.resolution.changeres = 0;
window->maxwidth = window->machine->switchRes.resolution.width;
window->maxheight = window->machine->switchRes.resolution.height;
window->refresh = window->machine->switchRes.resolution.refresh;
winwindow_toggle_full_screen();
winwindow_toggle_full_screen();
}

Of course there might be a better way of doing that.

Obvioulsy only first resolution modeline is actually calculated, for the second (usually the main one) and the next ones it will go to the default ddraw pick_best_mode, so one of the dummy modelines will be used probably with default 60Hz. But at least it doesn't crash any more and is pretty stable even with psx games for what I've seen.