CabMame

[southpaw13]

Does anyone know if CabMame 140 is available yet?
Thanks...

[WhereEaglesDare]

...  I wikied CabMame, but.....  what exactly is CabMAME and how well does it work?

Found this:  http://community.arcadeinfo.de/showthread.php?t=9555

Can you get any real noticeable performance boost?

[jtslade]

It would be great to See if it can solve the vaync sound studder problem...

[Gray_Area]

Download it. Try it out.

[WhereEaglesDare]

Does it work if i load that Diff and I use MKChamp's Hi Score Diff?

[Gray_Area]

Load it up. Try it out.

[WhereEaglesDare]

If I load one up anyone wanna try it out?  Im using a 140u1 romset, it isnt current to 140 yet...

PM me.  Im building it now.

[EvilDindon]

Man, yeah if you succeed i'd be very intersted of a 140u1 modded mame with the hiscore and the cabmame diffs.

Actually I tried the same as you, with the cabamame 0139 hacks, but i get an error while trying to make mame (compile error at the end of the process).

It seems that the render.c file which the frogger hack try to change has been changed so the 139 version of the hack cannot apply to mame > = 140

[WhereEaglesDare]

Man, yeah if you succeed i'd be very intersted of a 140u1 modded mame with the hiscore and the cabmame diffs.

Actually I tried the same as you, with the cabamame 0139 hacks, but i get an error while trying to make mame (compile error at the end of the process).

It seems that the render.c file which the frogger hack try to change has been changed so the 139 version of the hack cannot apply to mame > = 140

Yea I tried it three times and i keep getting errors.  I gave up 

[southpaw13]

Any luck compiling???

[ratsflif]

I am interested in getting cabmame diffs on 140 too.  Anyone get this going?

[bitbytebit]

This has the redraw and frogger patches ported to 140u2, you can apply this to a 140u2 patched with the hiscore patches already applied.  It's aimed at Linux but the Windows parts of those patches are also in this too.

http://groovyarcade.git.sourceforge.net/git/gitweb.cgi?p=groovyarcade/groovyarcade;a=blob_plain;f=overlays/games-emulation/mame/files/groovyarcade-0140u2.patch;hb=HEAD

(right click and save the link for the patch basically, it's in a GIT repository) 

[newmanfamilyvlogs]

I wonder if anything like the mode line generation from advance mame could be integrated into cab mame or another modern build?

[bitbytebit]

I wonder if anything like the mode line generation from advance mame could be integrated into cab mame or another modern build?

We have switchres doing that actually quite well now in Windows with the Radeon cards, others don't support dynamic modeline generation *yet* (if someone figures out how to do that in them perhaps in the future).  Basically you install Soft15Khz and then can put up to 60 "dummy" modelines of basic resolution sizes, which is a limitation Calamity is working on increasing to the needed 104+ ones to fit every game perfectly.  Then switchres will use those and can dynamically change the one that fits the game in HxW and make it use the right refresh rate (if monitor supports it of course).   Switchres is basically a wrapper for mame, you run 'switchres --monitor <type> <romname>', it also can use mess and run other emulators and setup the monitor to the right resolution from the game on the fly too.

So it's somewhat close to advanced mame, using Soft15khz and SwitchRes get you mostly a working setup.  In Linux it's able to pretty much perfectly match all resolutions on the fly with a Radeon card, we are still working on getting that perfected on all Radeon cards but it's able to get the refresh rate matched w/o tearing and hardware vsync/page flipping support plus nice modeline setups (I have a liveCD which is being worked on to make this all available, common Linux distros aren't up to date enough yet and I have patches for the kernel to support the arcade modes right).

Work is being done, so in the future hopefully it'll become even better but right now it's mostly working with Radeon cards.

[newmanfamilyvlogs]

I've been watching your switchres thread. Sounds like its time to start playing with it. Im using soft 15khz on a radeon hd, but I'm having a bad problem with tearing and input lag when vsynced.

[WhereEaglesDare]

ll build the 140u2 redraw/frogger/hi and let you guys know what happens.

[bitbytebit]

Sounds great, I'm working on adding in the rest of the cabmame patches into that patch, has been aimed/tested on Linux but sounds good to get this working for all systems (soundsync patch won't ever work in Linux but rest should be workable for all systems).  There's some big changes in how they do things which requires a few alterations in how things are done, so it's interesting but I think I can get the rest of them to work 140u2 hopefully in a day or two.   

[bitbytebit]

I've added the rest of cabmame patches to that diff except the changeres one, I'm going to do that later but nice to test each in parts too since I can't compile the Windows side here (no native windows compiler), but should be right since Linux side is compiling fine (sound sync fix should work, only part really that could possibly have errors).  So now the cleanstretch option, the soundsync option (only in windows), resolution patch and defaults patch from cabmame are in there.

Also a question, does cleanstretch not stretch the screen without hwstretch turned on?  Is it good just to have cleanstretch on all the time then I guess.  Just asking because in Linux there's unevenstretch which seems to do what hwstretch does in Windows, yet with cleanstretch it doesn't play well with unevenstretch and prevents the stretch from occurring.  I'm thinking that cleanstretch then in Linux should always be on unless hwstretch is wanted, or unevenstretch as it seems to be in Linux.

[Calamity]

I'll have to check that, but I believe that cleanstretch is only necessary when doing hwstretch using -video d3d, as direct3d softens the pixels when stretching. As I always use -video ddraw, I don't use cleanstretch as I believe it doesn't make any difference there (or at least I don't miss it), anyway I'll test that. In Linux maybe it's not necessary if unevenstretch behavour is similar to ddraw one. I don't think that using d3d provides any advantage when using arcade monitors (might be wrong), that's why I just default to ddraw and set the right options for that. Cleanstretch shouldn't make any difference when hwstretch/unevenstretch is not used (when stretching does not occur) so it doesn't make sense to have it activated there (I think).

Btw, if you can set the frequency for the sound buffer at least at the beginning, you could at least in theory precalculate the needed frequency ratio as you indeed know your (actual vfreq) / (target vfreq) when doing your own modelines. It might work more or less ok for vertical games like pacman or contra, that are way unsynced when using a CGA arcade monitor (not achieving 60Hz at all).

[bitbytebit]

I have added the changeres patch and so now the patch should include all cabmame patches for Windows and Linux now (changeres seems to already work under Linux without the patch, I think at least.  Otherwise it might be similar to the sound sync patch and require more work to figure out how to restart OpenGL/SDL correctly.  It seems though to have the code in the SDL part checking for resolution changes).  Please test compiling and running it in Windows, since I don't have a test setup, and report back success/failures so I can know if I need to change anything.  There was quite a bit of changes to the patches for the newer mame so not 100% sure the Windows side is exactly right on how to go about things now in the newer mame code of 140u2.

[WhereEaglesDare]

I have added the changeres patch and so now the patch should include all cabmame patches for Windows and Linux now (changeres seems to already work under Linux without the patch, I think at least.  Otherwise it might be similar to the sound sync patch and require more work to figure out how to restart OpenGL/SDL correctly.  It seems though to have the code in the SDL part checking for resolution changes).  Please test compiling and running it in Windows, since I don't have a test setup, and report back success/failures so I can know if I need to change anything.  There was quite a bit of changes to the patches for the newer mame so not 100% sure the Windows side is exactly right on how to go about things now in the newer mame code of 140u2.

I'll compile it tonight when I get home, I'll try it out and post it.  32Bit Single Core

[ratsflif]

Errors out when I try to compile...


Compiling src/osd/windows/video.c...
src/osd/windows/video.c: In member function 'virtual void windows_osd_interface::update(bool)':
src/osd/windows/video.c:228: error: 'window' was not declared in this scope
make: *** [obj/windows/mame64/osd/windows/video.o] Error 1
make: *** Waiting for unfinished jobs....
src/osd/windows/sound.c:196: error: prototype for 'void windows_osd_interface::update_audio_stream(running_machine*, const INT16*, int)' does not match any in class 'windows_osd_interface'
src/osd/windows/winmain.h:153: error: candidate is: virtual void windows_osd_interface::update_audio_stream(running_machine&, const INT16*, int)
cc1plus.exe: warnings being treated as errors
src/osd/windows/sound.c:152: error: 'void copy_sample_data(const INT16*, int)' defined but not used
make: *** [obj/windows/mame64/osd/windows/sound.o] Error 1
Finished!
0 Hours 11 Minutes and 4 Seconds Elapsed.

[bitbytebit]

Errors out when I try to compile...


Compiling src/osd/windows/video.c...
src/osd/windows/video.c: In member function 'virtual void windows_osd_interface::update(bool)':
src/osd/windows/video.c:228: error: 'window' was not declared in this scope
make: *** [obj/windows/mame64/osd/windows/video.o] Error 1
make: *** Waiting for unfinished jobs....
src/osd/windows/sound.c:196: error: prototype for 'void windows_osd_interface::update_audio_stream(running_machine*, const INT16*, int)' does not match any in class 'windows_osd_interface'
src/osd/windows/winmain.h:153: error: candidate is: virtual void windows_osd_interface::update_audio_stream(running_machine&, const INT16*, int)
cc1plus.exe: warnings being treated as errors
src/osd/windows/sound.c:152: error: 'void copy_sample_data(const INT16*, int)' defined but not used
make: *** [obj/windows/mame64/osd/windows/sound.o] Error 1
Finished!
0 Hours 11 Minutes and 4 Seconds Elapsed.

Thanks,  Try this patch on top of that and see if it fixes it...

Code: [Select]

diff --git a/src/osd/windows/sound.c b/src/osd/windows/sound.c
index 0a27dc8..5b1372e 100644
--- a/src/osd/windows/sound.c
+++ b/src/osd/windows/sound.c
@@ -105,6 +105,7 @@ static HRESULT              dsound_init(running_machine *machine);
 static void                    dsound_kill(void);
 static HRESULT         dsound_create_buffers(void);
 static void                    dsound_destroy_buffers(void);
+static void            copy_sample_data(const INT16 *data, int bytes_to_copy);
 
 
 
diff --git a/src/osd/windows/video.c b/src/osd/windows/video.c
index fcb2eea..e64dfcc 100644
--- a/src/osd/windows/video.c
+++ b/src/osd/windows/video.c
@@ -225,7 +225,7 @@ void windows_osd_interface::update(bool skip_redraw)
 
        // if we're not skipping this redraw, update all windows
        if (!skip_redraw)
-               for (window = win_window_list; window != NULL; window = window->next)
+               for (win_window_info *window = win_window_list; window != NULL; window = window->next)
                {
                        winwindow_video_window_update(window);
                        if (machine().redraw != 0)
@@ -262,7 +262,7 @@ void windows_osd_interface::update_hi(bool skip_redraw)
 
        // if we're not skipping this redraw, update all windows
         if (!skip_redraw) {
-               for (window = win_window_list; window != NULL; window = window->next) {
+               for (win_window_info *window = win_window_list; window != NULL; window = window->next) {
                        winwindow_video_window_update_hi(window);
                        if (machine().redraw != 0)
                        {
diff --git a/src/osd/windows/winmain.h b/src/osd/windows/winmain.h
index ec9c697..b5f5421 100644
--- a/src/osd/windows/winmain.h
+++ b/src/osd/windows/winmain.h
@@ -150,7 +150,7 @@ public:
        virtual void wait_for_debugger(device_t &device, bool firststop);
 
        // audio overridables
-       virtual void update_audio_stream(running_machine &machine, const INT16 *buffer, int samples_this_frame);
+       virtual void update_audio_stream(running_machine *machine, const INT16 *buffer, int samples_this_frame);
        virtual void set_mastervolume(int attenuation);
 
        // input overridables


Update: The main patch link is now also updated with these fixes too

[ratsflif]

1 error when applying the diff:

patching file ./src/osd/osdmini/osdmini.h
patching file ./src/osd/sdl/drawogl.c
patching file ./src/osd/sdl/osdsdl.h
patching file ./src/osd/sdl/sdlmain.c
patching file ./src/osd/sdl/sound.c
patching file ./src/osd/sdl/video.c
patching file ./src/osd/sdl/video.h
patching file ./src/osd/sdl/window.c
patching file ./src/osd/sdl/window.h
patching file ./src/osd/windows/drawd3d.c
patching file ./src/osd/windows/drawdd.c
patching file ./src/osd/windows/sound.c
patching file ./src/osd/windows/video.c
Hunk #2 FAILED at 255.
1 out of 2 hunks FAILED -- saving rejects to file ./src/osd/windows/video.c.rej
patching file ./src/osd/windows/window.c
patching file ./src/osd/windows/winmain.c
patching file ./src/osd/windows/winmain.h



Tried to compile anyway and received this:

Compiling src/osd/windows/sound.c...
src/osd/windows/sound.c:196: error: prototype for 'void windows_osd_interface::update_audio_stream(running_machine*, const INT16*, int)' does not match any in class 'windows_osd_interface'
src/osd/windows/winmain.h:153: error: candidate is: virtual void windows_osd_interface::update_audio_stream(running_machine&, const INT16*, int)
Compiling src/osd/windows/video.c...
cc1plus.exe: warnings being treated as errors
src/osd/windows/sound.c:152: error: 'void copy_sample_data(const INT16*, int)' defined but not used
make: *** [obj/windows/mame64/osd/windows/sound.o] Error 1
make: *** Waiting for unfinished jobs....
src/osd/windows/video.c: In member function 'virtual void windows_osd_interface::update(bool)':
src/osd/windows/video.c:228: error: 'window' was not declared in this scope
make: *** [obj/windows/mame64/osd/windows/video.o] Error 1
Finished!
0 Hours 11 Minutes and 7 Seconds Elapsed.

This is 140 with u1 and u2 then this patch applied, no other diffs.

Thanks for the help man.

[bitbytebit]

1 error when applying the diff:

patching file ./src/osd/osdmini/osdmini.h
patching file ./src/osd/sdl/drawogl.c
patching file ./src/osd/sdl/osdsdl.h
patching file ./src/osd/sdl/sdlmain.c
patching file ./src/osd/sdl/sound.c
patching file ./src/osd/sdl/video.c
patching file ./src/osd/sdl/video.h
patching file ./src/osd/sdl/window.c
patching file ./src/osd/sdl/window.h
patching file ./src/osd/windows/drawd3d.c
patching file ./src/osd/windows/drawdd.c
patching file ./src/osd/windows/sound.c
patching file ./src/osd/windows/video.c
Hunk #2 FAILED at 255.
1 out of 2 hunks FAILED -- saving rejects to file ./src/osd/windows/video.c.rej
patching file ./src/osd/windows/window.c
patching file ./src/osd/windows/winmain.c
patching file ./src/osd/windows/winmain.h



Tried to compile anyway and received this:

Compiling src/osd/windows/sound.c...
src/osd/windows/sound.c:196: error: prototype for 'void windows_osd_interface::update_audio_stream(running_machine*, const INT16*, int)' does not match any in class 'windows_osd_interface'
src/osd/windows/winmain.h:153: error: candidate is: virtual void windows_osd_interface::update_audio_stream(running_machine&, const INT16*, int)
Compiling src/osd/windows/video.c...
cc1plus.exe: warnings being treated as errors
src/osd/windows/sound.c:152: error: 'void copy_sample_data(const INT16*, int)' defined but not used
make: *** [obj/windows/mame64/osd/windows/sound.o] Error 1
make: *** Waiting for unfinished jobs....
src/osd/windows/video.c: In member function 'virtual void windows_osd_interface::update(bool)':
src/osd/windows/video.c:228: error: 'window' was not declared in this scope
make: *** [obj/windows/mame64/osd/windows/video.o] Error 1
Finished!
0 Hours 11 Minutes and 7 Seconds Elapsed.

This is 140 with u1 and u2 then this patch applied, no other diffs.

Thanks for the help man.

Ah interesting, it's missing the audio part of the diff to the patch.  I'll have to double check that.  Also you must also apply the hiscore patch from MKChamp first, before this one, so that might be one issue.  Also it's interesting, I see that compiler is saying that warnings are errors for the functions not being used, might just be from missing the hiscore patch though, will have to check after fixing the real errors.

That part that is failing, possibly just change it by hand since it's one simple alteration from a & to a * like this at line number 150...

Code: [Select]



--- a/src/osd/windows/winmain.h
+++ b/src/osd/windows/winmain.h
@@ -150,7 +150,7 @@ public:
        virtual void wait_for_debugger(device_t &device, bool firststop);
 
        // audio overridables
-       virtual void update_audio_stream(running_machine &machine, const INT16 *buffer, int samples_this_frame);
+       virtual void update_audio_stream(running_machine *machine, const INT16 *buffer, int samples_this_frame);
        virtual void set_mastervolume(int attenuation);
 
        // input overridables




Update:

Ah seems there's more, I'll post more when I figure out

[bitbytebit]

Ok I think I figured it out, the patch error is from missing the hiscore patch and might also be related to the other ones although might be from something else.  Download my patch again, and also get the newest hiscore patch for 140u2, and apply the hiscore one first then mine to a clean mame0140u2.  See what that gets, at least should clear up some of the errors I think, will have to look closer then possibly at why the compiler is complaining about warnings (if it still does), also check for sure that it compiles clean before the patching just to double check, although I'm guessing those warnings might be from the hiscore patch not being there first before my patch.  Thanks for testing this.

[ratsflif]

We are now in business.  Thank you much.  Now to compile it with the new PGM driver to get some cave shmup madness going.

Edit, it compiled correctly but the exe will not run.  Gives me an empty dialog box.  Will do some more testing

I tired running a few games from the command prompt and I get the error:

Unexpected boolean option unevenstretch queried

[Gray_Area]

If the refresh is matched/preserved, everything should run fine. I'm wondering if maybe you guys aren't going at it the hard way.

[bitbytebit]

We are now in business.  Thank you much.  Now to compile it with the new PGM driver to get some cave shmup madness going.

Edit, it compiled correctly but the exe will not run.  Gives me an empty dialog box.  Will do some more testing

I tired running a few games from the command prompt and I get the error:

Unexpected boolean option unevenstretch queried

Yeah that unevenstretch issue sounds like what I had done so that it worked on SDL with cleanstretch properly, tricky issue there since it's only an option in SDL for unevenstretch but in the common code I need to check for it since that's where cleanstretch code goes.  I look at that and try to figure out how to do that part better.  Not sure if the other issue is related to that, I'll look through the patch and see if I missed anything in the Windows OSD part.  Suspicious it's again the newer code changes in Mame which make the cabmame patch require altering some code methods to use classes instead of regular C.

[bitbytebit]

I updated the patch with a few fixes, should work better on Windows.  I also have a compiled windows binary now that seems to at least open up an OSD menu...

http://mario.groovy.org/GroovyArcade/MameWindows/

Let me know how either work, hopefully fixed the issues, basically same patches as cabmame in the build but with the MKChamp hiscore/nonag patches and Linux/SDL compatible.

Update:  This works only with ddraw, but I'm recompiling and think I figured out why.  Otherwise it seems to run  the same for me as cabmame does so seems like the patches are correct.  I think my compile environment being inside of cygwin messed up the d3d support, will see and post when I have a new Windows build.

[ratsflif]

I tried your binary and I can load the games fine with ddraw but the game just stays in a small window and does not go fullscreen, with or without hardware stretch.

[bitbytebit]

I tried your binary and I can load the games fine with ddraw but the game just stays in a small window and does not go fullscreen, with or without hardware stretch.

Yep, I fixed that and now have the patch updated which should work all as expected now.  Finally was able to compile and test it myself and found the bugs, was the changeres patch that I got wrong from mame changing so much for that part from 0140-140u2.  I also am going to have a binary of 140u3 uploaded and the hiscore + this patch do work fine on u3 too so can use that (oddly u3 has a bug in Linux compiling it for the SDL stuff I reported to the Mame developers).  The one difference in u3 is that it'll complain about one of the diffs is already there, just say 'n' to it being a recursive diff and just ignore it basically.  That's because mame u3 contains a fix I made that I sent to mame and they included it for that version .


Update: Working 140u2 version is up and also version 140u3

[bitbytebit]

If the refresh is matched/preserved, everything should run fine. I'm wondering if maybe you guys aren't going at it the hard way.

It depends on the monitor capabilities (and the amount of custom resolutions your video card supports) which most can't match all the games so Cabmame patches make up for that using sound sync/redraw/speed hacks.  If you have a d9800/Radeon plus switchres then sure it's mostly not necessary, although somewhat helpful for a few games using redraw like Tron which runs at 30Hz normally and galaxian/frogger with way out there resolutions in mame by default.  Also there's the change resolution patch, and it tweaks the defaults for arcade monitors.  With the cabmame patches in Linux with switchres and my d9800 there's hardly a game that needs throttle, in fact I can't really think of any with the cabmame redraw patch fixing ones like Tron.   

Also to match refresh is only one part, the second is to have mame actually be able to utilize that refresh which comes from the video card information about vblanking and page flipping, which together is how you can turn off throttle and have mame follow those interrupts from the video card.  That requires OpenGL in SDL or Linux mostly, it needs to work through that interface to talk to the kernel layer knowing the video cards interrupts.  In windows this happens I guess through both ddraw (basically 2D OpenGL/Mesa for SDL) and d3d (basically 3D OpenGL/Mesa for SDL). 

Hopefully that explains the motivation of the different aspects of working a bit different in Windows than in Linux/SDL because of how they approach the video driver differently and so the vsync/vblank ability is a bit trickier to get in Linux without patches and bleeding edge code which is new as of the last month or less.  Unifying the cabmame patch to both Linux and Windows is interesting, and also unifying switchres support for both too, since it's going to help make this more a out-of-the-box solution without much work to just run either mame+cabmame in either Linux/Windows and it'll work great on an Arcade monitor, add in Soft15Khz (for Windows) and switchres (and my Linux distro/build for Linux) and you hopefully can maximize the use of your arcade monitors capabilities (with a Radeon card for now, maybe others but like in Windows varies for how good it'll work compared to a Radeon).

[emphatic]

I tried this (u3, Windows) build and no matter what, I couldn't get full screen on my screen using d3d. With directddraw I could get fullscreen, but in slow motion. I'm running a WinXP machine in my cabinet that outputs 480x640@60 (vertical only) to my Ultracade Universal Video Converter (UVC). The UVC in turn gives med 24kHz on my mid res arcade monitor. I guess that I have to have either ArcadeVGA or a Soft15kHz enabled card to use this? I only have onboard Intel gfx unfortunately.

[bitbytebit]

I tried this (u3, Windows) build and no matter what, I couldn't get full screen on my screen using d3d. With directddraw I could get fullscreen, but in slow motion. I'm running a WinXP machine in my cabinet that outputs 480x640@60 (vertical only) to my Ultracade Universal Video Converter (UVC). The UVC in turn gives med 24kHz on my mid res arcade monitor. I guess that I have to have either ArcadeVGA or a Soft15kHz enabled card to use this? I only have onboard Intel gfx unfortunately.

Try it with -nochangeres which allows stretching to occur.  The cabmame patches really are for using soft15khz and an arcade monitor, but turning off changeres allows it to work decent for other setups.  That's at least what I've found testing it in my HDTV and looking at the code closer, changeres is enabled by default and turns off scaling.

[emphatic]

Thanks for explaining. I'm a bit stumped now though, because none of the settings I've tried out seemed to be used. I use a batch file that I edit,  but as the game always loads, I haven't had any errors.

[ratsflif]

Same thing here, even with the -nochangeres option it is still in a small window.

[bitbytebit]

Same thing here, even with the -nochangeres option it is still in a small window.

Do you have -hwstretch on, cabmame turns this off by default.  Also post the output of `mame -showconfig` so I can check and see if anything else might be preventing it from stretching, can test the config here and see what tweaks make it act the same as I'm getting it to run.  Sounds like -hwstretch not being set to 1 in the config though, or not enabled on the command line, although there might be something else.

Also try this command line...

mame <rom> -nochangeres -nocleanstretch -hwstretch -keepaspect

That might be better I think.

[emphatic]

I used this command line and got fullscreen 4:3:

mame0140u3 romname -nochangeres -nocleanstretch -hwstretch

If I use -keepaspect the game is vertically stretched 100% but not on the horizontal axis.

[bitbytebit]

I used this command line and got fullscreen 4:3:

mame0140u3 romname -nochangeres -nocleanstretch -hwstretch

If I use -keepaspect the game is vertically stretched 100% but not on the horizontal axis.

The keepaspect option will be useful with vertical games mostly which you won't want stretched wider, if using a horizontal monitor for them.  Also it depends on ddraw vs. d3d how it acts and ddraw shouldn't need it at all.  Looks like you'll be able to get what your looking for through those options, basically forcing cabmame to work on a normal SVGA monitor by tweaking the defaults but still getting some of the benefits of the other hacks in it to keep the game speed right with imperfect vertical refresh rates  on a normal computer monitor.