Main Restorations Software Audio/Jukebox/MP3 Everything Else Buy/Sell/Trade
Project Announcements Monitor/Video GroovyMAME Merit/JVL Touchscreen Meet Up Retail Vendors
Driving & Racing Woodworking Software Support Forums Consoles Project Arcade Reviews
Automated Projects Artwork Frontend Support Forums Pinball Forum Discussion Old Boards
Raspberry Pi & Dev Board controls.dat Linux Miscellaneous Arcade Wiki Discussion Old Archives
Lightguns Arcade1Up Try the site in https mode Site News

Unread posts | New Replies | Recent posts | Rules | Chatroom | Wiki | File Repository | RSS | Submit news

  

Author Topic: CabMame  (Read 61377 times)

0 Members and 1 Guest are viewing this topic.

southpaw13

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 831
  • Last login:October 31, 2020, 05:11:18 pm
  • Whatever!
CabMame
« on: November 12, 2010, 07:04:49 pm »
Does anyone know if CabMame 140 is available yet?
Thanks...

WhereEaglesDare

  • Trade Count: (+4)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1536
  • Last login:March 24, 2014, 08:47:08 pm
  • Shut Off All The Compactors on the Detention Level
    • My HomePage
Re: CabMame
« Reply #1 on: November 12, 2010, 10:30:42 pm »
...  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?
« Last Edit: November 12, 2010, 10:38:40 pm by WhereEaglesDare »

jtslade

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 747
  • Last login:February 13, 2025, 10:06:51 pm
  • Keep it looking originallish!
Re: CabMame
« Reply #2 on: November 13, 2010, 07:12:39 am »
It would be great to See if it can solve the vaync sound studder problem...
Ms. Pacman Original Cocktail with Non destructive mod to Groovy Arcade Linux with All 4way Vertical Cocktail capable 2 button or less games.


Neo Geo MVS Mame Cab Running Hyperspin, 25" Nanao Arcade Monitor, Mini-pac, ATI Radeon HD 4850 (ATOM-15), IL 8 Way Euro-Sticks from Paradise Arcade, Win XP 64bit, and tons of other junk.


Gray_Area

  • -Banned-
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 3363
  • Last login:June 23, 2013, 06:52:30 pm
  • -Banned-
Re: CabMame
« Reply #3 on: November 13, 2010, 10:16:02 pm »
Download it. Try it out.
-Banned-

WhereEaglesDare

  • Trade Count: (+4)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1536
  • Last login:March 24, 2014, 08:47:08 pm
  • Shut Off All The Compactors on the Detention Level
    • My HomePage
Re: CabMame
« Reply #4 on: November 13, 2010, 10:40:18 pm »
Does it work if i load that Diff and I use MKChamp's Hi Score Diff?

Gray_Area

  • -Banned-
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 3363
  • Last login:June 23, 2013, 06:52:30 pm
  • -Banned-
Re: CabMame
« Reply #5 on: November 16, 2010, 06:20:02 pm »
Load it up. Try it out.
-Banned-

WhereEaglesDare

  • Trade Count: (+4)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1536
  • Last login:March 24, 2014, 08:47:08 pm
  • Shut Off All The Compactors on the Detention Level
    • My HomePage
Re: CabMame
« Reply #6 on: November 17, 2010, 12:59:45 pm »
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 47
  • Last login:December 03, 2014, 11:34:33 am
Re: CabMame
« Reply #7 on: November 22, 2010, 05:15:54 am »
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

  • Trade Count: (+4)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1536
  • Last login:March 24, 2014, 08:47:08 pm
  • Shut Off All The Compactors on the Detention Level
    • My HomePage
Re: CabMame
« Reply #8 on: November 22, 2010, 01:05:23 pm »
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 831
  • Last login:October 31, 2020, 05:11:18 pm
  • Whatever!
Re: CabMame
« Reply #9 on: December 08, 2010, 08:20:10 pm »
Any luck compiling???

ratsflif

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 85
  • Last login:January 29, 2024, 06:08:07 pm
Re: CabMame
« Reply #10 on: December 18, 2010, 05:15:14 pm »
I am interested in getting cabmame diffs on 140 too.  Anyone get this going?

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #11 on: December 18, 2010, 09:40:35 pm »
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

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1694
  • Last login:June 15, 2022, 05:20:38 pm
    • forum.arcadecontrols.com/index.php/topic,103584.msg1096585.html#msg1096585
    • Newman Family Vlogs
Re: CabMame
« Reply #12 on: December 18, 2010, 10:14:23 pm »
I wonder if anything like the mode line generation from advance mame could be integrated into cab mame or another modern build?

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #13 on: December 18, 2010, 10:24:11 pm »
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

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1694
  • Last login:June 15, 2022, 05:20:38 pm
    • forum.arcadecontrols.com/index.php/topic,103584.msg1096585.html#msg1096585
    • Newman Family Vlogs
Re: CabMame
« Reply #14 on: December 19, 2010, 08:19:59 am »
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

  • Trade Count: (+4)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1536
  • Last login:March 24, 2014, 08:47:08 pm
  • Shut Off All The Compactors on the Detention Level
    • My HomePage
Re: CabMame
« Reply #15 on: December 19, 2010, 11:12:54 am »
ll build the 140u2 redraw/frogger/hi and let you guys know what happens.

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #16 on: December 19, 2010, 12:03:18 pm »
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

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #17 on: December 19, 2010, 02:19:54 pm »
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 7461
  • Last login:May 23, 2025, 06:07:25 am
  • Quote me with care
Re: CabMame
« Reply #18 on: December 19, 2010, 02:56:51 pm »
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).
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #19 on: December 20, 2010, 02:13:05 am »
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

  • Trade Count: (+4)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1536
  • Last login:March 24, 2014, 08:47:08 pm
  • Shut Off All The Compactors on the Detention Level
    • My HomePage
Re: CabMame
« Reply #20 on: December 20, 2010, 06:22:26 am »
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 85
  • Last login:January 29, 2024, 06:08:07 pm
Re: CabMame
« Reply #21 on: December 22, 2010, 10:45:06 am »
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

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #22 on: December 22, 2010, 11:39:16 am »
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
« Last Edit: December 22, 2010, 11:47:59 am by bitbytebit »

ratsflif

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 85
  • Last login:January 29, 2024, 06:08:07 pm
Re: CabMame
« Reply #23 on: December 22, 2010, 12:33:04 pm »
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

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #24 on: December 22, 2010, 12:49:22 pm »
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
« Last Edit: December 22, 2010, 12:54:34 pm by bitbytebit »

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #25 on: December 22, 2010, 01:03:55 pm »
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 85
  • Last login:January 29, 2024, 06:08:07 pm
Re: CabMame
« Reply #26 on: December 22, 2010, 01:43:43 pm »
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
« Last Edit: December 22, 2010, 03:50:02 pm by ratsflif »

Gray_Area

  • -Banned-
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 3363
  • Last login:June 23, 2013, 06:52:30 pm
  • -Banned-
Re: CabMame
« Reply #27 on: December 23, 2010, 09:36:50 pm »
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.
« Last Edit: December 24, 2010, 06:40:28 am by Gray_Area »
-Banned-

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #28 on: December 23, 2010, 09:53:07 pm »
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

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #29 on: December 24, 2010, 02:07:25 am »
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.
« Last Edit: January 26, 2011, 05:08:00 pm by bitbytebit »

ratsflif

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 85
  • Last login:January 29, 2024, 06:08:07 pm
Re: CabMame
« Reply #30 on: December 24, 2010, 08:00:54 pm »
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

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #31 on: December 24, 2010, 08:19:07 pm »
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
« Last Edit: December 24, 2010, 09:21:32 pm by bitbytebit »

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #32 on: December 24, 2010, 08:42:02 pm »
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2017
  • Last login:Yesterday at 02:26:42 pm
  • -"Suck it, Donny!" -"No, YOU suck it.... more".
    • Emphatic's Video Game Collection
Re: CabMame
« Reply #33 on: December 25, 2010, 01:28:05 pm »
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.
« Last Edit: December 25, 2010, 01:32:05 pm by emphatic »

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #34 on: December 25, 2010, 02:30:16 pm »
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2017
  • Last login:Yesterday at 02:26:42 pm
  • -"Suck it, Donny!" -"No, YOU suck it.... more".
    • Emphatic's Video Game Collection
Re: CabMame
« Reply #35 on: December 25, 2010, 02:54:58 pm »
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 85
  • Last login:January 29, 2024, 06:08:07 pm
Re: CabMame
« Reply #36 on: December 27, 2010, 04:58:38 pm »
Same thing here, even with the -nochangeres option it is still in a small window.

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #37 on: December 27, 2010, 05:29:13 pm »
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.
« Last Edit: December 27, 2010, 05:33:15 pm by bitbytebit »

emphatic

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2017
  • Last login:Yesterday at 02:26:42 pm
  • -"Suck it, Donny!" -"No, YOU suck it.... more".
    • Emphatic's Video Game Collection
Re: CabMame
« Reply #38 on: December 28, 2010, 06:40:58 am »
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

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #39 on: December 28, 2010, 01:19:52 pm »
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.

Gray_Area

  • -Banned-
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 3363
  • Last login:June 23, 2013, 06:52:30 pm
  • -Banned-
Re: CabMame
« Reply #40 on: January 01, 2011, 02:57:56 am »
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.

I was under the impression that the chain of things was MAME>video hardware>monitor, with your efforts largely based in forcing/seducing the video hardware into doing MAME's bidding.


Regarding Tron: so you're saying a 15khz/60hz monitor can display Tron with the re-draw feature?
-Banned-

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #41 on: January 01, 2011, 03:29:55 am »
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.

I was under the impression that the chain of things was MAME>video hardware>monitor, with your efforts largely based in forcing/seducing the video hardware into doing MAME's bidding.


Regarding Tron: so you're saying a 15khz/60hz monitor can display Tron with the re-draw feature?
Yeah it can do that without throttle by doubling the frame output I guess so it becomes 60hz instead of 30, of course only works in cases where you are able to double the mame refresh rate to match the monitor refresh rate. 

It's basically setting up an available modeline for mame to target and use which best matches the game and works with the capabilities of the monitor, and tweaking mame command line settings to make that combo of mame/resolution/monitor to run as original as possible.

Here's an example of what switchres does to run Tron on a CGA vs. d9800 with nothrottle and perfect vsync/refresh rate and no tearing w/original resolution(on d9800 only) for horizontal monitor playing it instead of vertical.  So in the CGA case of course there's a bit of virtualization to get the redraw and 60Hz capable modeline and run it at the original refresh, on the d9800 it can match the original resolution and run on the monitor refresh rate with redraw.

CGA:
Code: [Select]
Mame version 0.141 with [cleanstretch][froggerfix][redraw][changeres][] hacks enabled
[] "tron" vertical 512x480@30.000 (1.067) --> 856x512@30.000 (1.666)

MonitorLimits 15250.00-15700.00,49.50-65.00,2.000,4.700,8.000,0.064,0.192,1.024,0,0,288.0,448
Setup monitor limits min=184x108 max=0x608
Increased vertical frequency to 60.000
Using interlace
Starting with Horizontal freq of 16.638 and Vertical refresh of 60.00
Horizontal frequency too high 16.638 vfreq 60.000
Virtualized to 856x480@60.00 15.6000Khz
Original Vref 30.000000 != 60.000000
# 15.250Khz -> 15.700Khz: ( | Interlace | Virtualize | )
# tron [9] 856x480@60.00 15.6300Khz
     "856x480x60.00" 17.255520 856 888 968 1104 480 482 488 521 -HSync -VSync interlace

Opening  modes file for mode 856x480x32@60.00
Running Emulator: mame tron -resolution 856x480x32@60.00 -resolution0 856x480x32@60.00 -video opengl -nocleanstretch -unevenstretch -nochangeres -keepaspect -redraw auto -nothrottle -nomt -waitvsync


D9800:
Code: [Select]
Mame version 0.141 with [cleanstretch][froggerfix][redraw][changeres][] hacks enabled
[d9800] "tron" vertical 512x480@30.000 (1.067) --> 856x512@30.000 (1.666)

MonitorLimits 15250.00-18000.00,40.00-80.00,2.187,4.688,6.719,0.190,0.191,1.018,0,0,288.0,448
Setup monitor limits min=184x84 max=0x864
Increased vertical frequency to 60.000
Using interlace
Starting with Horizontal freq of 16.767 and Vertical refresh of 60.00
Original Vref 30.000000 != 60.000000
# 15.250Khz -> 18.000Khz: ( | Interlace | )
# tron [3] 856x512@60.00 16.7700Khz
     "856x512x60.00" 18.648240 856 896 984 1112 512 518 524 559 -HSync -VSync interlace

MonitorLimits 18001.00-18900.00,40.00-80.00,2.187,4.688,6.719,0.140,0.191,0.950,0,0,288.0,448
Setup monitor limits min=184x104 max=0x912
Increased vertical frequency to 60.000
Using interlace
Starting with Horizontal freq of 16.639 and Vertical refresh of 60.00
Increased horizontal frequency from 16.639 to 18.001
Original Vref 30.000000 != 60.000000
Using 42 lines padding
# 18.001Khz -> 18.900Khz: ( | Hfreq Change | Interlace | Vpad +42 lines | )
# tron [10] 856x512@60.00 18.0300Khz
     "856x512x60.00" 20.482080 856 904 1000 1136 512 538 545 601 -HSync -VSync interlace

MonitorLimits 20001.00-29000.00,40.00-80.00,2.910,3.000,4.440,0.451,0.164,1.048,0,0,480.0,768
Setup monitor limits min=184x104 max=0x1360
Increased vertical frequency to 60.000
Virtualized to 1152x864@60.00 28.8000Khz
Starting with Horizontal freq of 28.793 and Vertical refresh of 60.00
Original Vref 30.000000 != 60.000000
# 20.001Khz -> 29.000Khz: ( | Interlace | Virtualize | )
# tron [9] 1152x864@60.00 28.8300Khz
     "1152x864x60.00" 46.589280 1152 1280 1416 1616 864 890 899 961 -HSync -VSync interlace
MonitorLimits 29001.00-32000.00,40.00-80.00,0.636,3.813,1.906,0.318,0.064,1.048,0,0,576.0,768
Setup monitor limits min=184x160 max=0x1520
Increased vertical frequency to 60.000
Starting with Horizontal freq of 33.603 and Vertical refresh of 60.00
Horizontal frequency too high 33.603 vfreq 60.000
Lowered horizontal frequency to  32000.000 from 33.603
Vertical frequency changed to 57.348 from 60.000
Original Vref 30.000000 != 57.347670
# 29.001Khz -> 32.000Khz: ( | Hfreq Change | Vref Change | )
# tron [11] 856x512@57.35 32.0000Khz
     "856x512x57.35" 34.048000 856 872 1000 1064 512 522 524 558 -HSync -VSync

MonitorLimits 32001.00-34000.00,40.00-80.00,0.636,3.813,1.906,0.020,0.106,0.607,0,0,576.0,768
Setup monitor limits min=184x188 max=0x1664
Increased vertical frequency to 60.000
Starting with Horizontal freq of 32.133 and Vertical refresh of 60.00
Original Vref 30.000000 != 60.000000
# 32.001Khz -> 34.000Khz: ( Perfect Resolution )
# tron [0] 856x512@60.00 32.1600Khz
     "856x512x60.00" 34.218240 856 872 1000 1064 512 513 516 536 -HSync -VSync

MonitorLimits 34001.00-38000.00,40.00-80.00,1.000,3.200,2.200,0.020,0.106,0.607,0,0,600.0,768
Setup monitor limits min=184x200 max=0x1856
Increased vertical frequency to 60.000
Starting with Horizontal freq of 32.133 and Vertical refresh of 60.00
Increased horizontal frequency from 32.133 to 34.001
Original Vref 30.000000 != 60.000000
Using 30 lines padding
# 34.001Khz -> 38.000Khz: ( | Hfreq Change | Vpad +30 lines | )
# tron [5] 856x512@60.00 34.0200Khz
     "856x512x60.00" 36.741600 856 888 1000 1080 512 528 532 567 -HSync -VSync

Opening  modes file for mode 856x512x32@60.00
Running Emulator: mame tron -resolution 856x512x32@60.00 -resolution0 856x512x32@60.00 -video opengl -cleanstretch -redraw auto -nothrottle -nomt -waitvsync

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #42 on: January 01, 2011, 11:54:31 am »
I built a 32bit 141 version of mame with the cabmame patches and hiscore/nonag ones, also I am turning off the changeres option by default now since that seems to contradict anything that needs stretching.  http://mario.groovy.org/GroovyArcade/MameWindows/

If anyone wants the patches, changed slightly but not too much, they are here...
http://groovyarcade.git.sourceforge.net/git/gitweb.cgi?p=groovyarcade/groovyarcade;a=blob_plain;f=overlays/games-emulation/mame/files/groovyarcade-0141.patch;hb=HEAD

(fix for using hi/ directory to store hiscore.dat) http://groovyarcade.git.sourceforge.net/git/gitweb.cgi?p=groovyarcade/groovyarcade;a=blob_plain;f=overlays/games-emulation/mame/files/hilocfix-0141.patch;hb=HEAD

(fix for SDL/Linux compile) http://groovyarcade.git.sourceforge.net/git/gitweb.cgi?p=groovyarcade/groovyarcade;a=blob_plain;f=overlays/games-emulation/mame/files/sdlfix-0141.patch;hb=HEAD
« Last Edit: January 26, 2011, 05:09:42 pm by bitbytebit »

Calamity

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 7461
  • Last login:May 23, 2025, 06:07:25 am
  • Quote me with care
Re: CabMame
« Reply #43 on: January 12, 2011, 01:24:25 pm »
I'm testing your new Mame v0.141 binary with CabMame hacks, it seems you've also added the soundsync functionallity (it's set by default, no command line option), it's working great for me, it also creates the proper default options when doing mame -createconfig, very convenient. I'm going to use this one as my default Mame binary for now on.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

southpaw13

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 831
  • Last login:October 31, 2020, 05:11:18 pm
  • Whatever!
Re: CabMame
« Reply #44 on: January 12, 2011, 04:00:31 pm »
Did you put the soundsync hack in it?

thanks.....

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #45 on: January 12, 2011, 04:03:48 pm »
Did you put the soundsync hack in it?

thanks.....
Yep, every cabmame patch is in there now, for both Mess and Mame 0141. 

southpaw13

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 831
  • Last login:October 31, 2020, 05:11:18 pm
  • Whatever!
Re: CabMame
« Reply #46 on: January 12, 2011, 04:46:32 pm »
Awesome....

thanks again....


EvilDindon

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 47
  • Last login:December 03, 2014, 11:34:33 am
Re: CabMame
« Reply #47 on: January 21, 2011, 12:23:56 pm »
Thanks a lot man, that's what i needed ! The two most important features of cabmame or the soundsync and the frogger/galaxian driver hack.

Question : I have tested an earlier cabmame veriosn (139), on my vertical monitor cab, but i couldn't run the double monitor nintendo games such as punch out! or arm wrestling.

Since I use the hardware stretch and 512X480 resolution for those games (to display the two monitors with an interlaced res), maybe I should turn off the changeres option ?

Cheers,

Mike from France
« Last Edit: January 21, 2011, 12:32:28 pm by EvilDindon »

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #48 on: January 21, 2011, 12:34:13 pm »
Thanks a lot man, that's what i needed ! The two most important features of cabmame or the soundsync and the frogger/galaxian driver hack.

Question : I have tested an earlier cabmame veriosn (139), on my vertical monitor cab, but i couldn't run the double monitor nintendo games such as punch out! or arm wrestling.

Since I use the hardware stretch and 512X480 resolution for those games (to display the two monitors with an interlaced res), maybe I should turn off the changeres option ?

Cheers,

Mike from France

Yep, I'm guessing that most likely is the issue, changeres seems to force a 1 to 1 scaling ratio from what I can tell.

EvilDindon

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 47
  • Last login:December 03, 2014, 11:34:33 am
Re: CabMame
« Reply #49 on: January 21, 2011, 02:07:36 pm »
Hey !

Just tested your build on my cab ; everything is OK even the double monitor nintendo games), BUT there's an issue (nothing is perfect at the first try :5  ) ;

Actually, the frogger hack works great on all the games (galaxian, scramble, moon cresta and clones) EXCEPT FROGGER !!!!  :banghead:


Frogger has still a resolution issue, it seems that the frogger hack that is supposed to set a 256X224 res for this game and all the galxian driver based games instead of the 768 x 224 false and official mame res, doesn't work.   :hissy:

Do you experience the same ?

I tried to workaround by setting in the frogger.ini 640X480 and hwstretch 1, but it' doesn't work neither, the screen isn't full.
« Last Edit: January 21, 2011, 02:09:28 pm by EvilDindon »

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #50 on: January 21, 2011, 02:13:03 pm »
Hey !

Just tested your build on my cab ; everything is OK even the double monitor nintendo games), BUT there's an issue (nothing is perfect at the first try :5  ) ;

Actually, the frogger hack works great on all the games (galaxian, scramble, moon cresta and clones) EXCEPT FROGGER !!!!  :banghead:


Frogger has still a resolution issue, it seems that the frogger hack that is supposed to set a 256X224 res for this game and all the galxian driver based games instead of the 768 x 224 false and official mame res, doesn't work.   :hissy:

Do you experience the same ?

I tried to workaround by setting in the frogger.ini 640X480 and hwstretch 1, but it' doesn't work neither, the screen isn't full.

It works here, but I'm not sure what is going on since frogger really should look just like galaxian so very strange.  So only frogger has the issue, what exactly does it look like?  What does the output of mame with -verbose show?

EvilDindon

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 47
  • Last login:December 03, 2014, 11:34:33 am
Re: CabMame
« Reply #51 on: January 21, 2011, 02:20:08 pm »
Yeah, in theory, frogger should be OK like galaxian, but it's not !

Well the image is stretched vertically and covers only a small part of the screen orizontally, just like if mame runs it on a 768X576 interlaced resolution. I'm pretty sure that this game is considered by mame to have this weird official resolution (768x224)

How can i use the verbose option ?
« Last Edit: January 21, 2011, 02:23:47 pm by EvilDindon »

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #52 on: January 21, 2011, 02:39:24 pm »
Yeah, in theory, frogger should be OK like galaxian, but it's not !

Well the image is stretched vertically and covers only a small part of the screen orizontally, just like if mame runs it on a 768X576 interlaced resolution. I'm pretty sure that this game is considered by mame to have this weird official resolution (768x224)

How can i use the verbose option ?
Just add -verbose to the command line of mame.  I did confirm that an oddity in 0141 is similar to that with gorf, but frogger works here.  I compared gorf in 0140u2 to 0141 and it did that, so sounds similar.  Do you have a version of 139 cabmame to compare it to?  Try it and see if it's the same results, also output of the -verbose option of frogger and galaxian may be helpful.

EvilDindon

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 47
  • Last login:December 03, 2014, 11:34:33 am
Re: CabMame
« Reply #53 on: January 21, 2011, 04:43:21 pm »
Ok thanks a lot dude for your help.

I remember that frogger worked well with cabmame 139.


So I launch frogger via the command prompt, with -verbose ? And after ? it will generate a log file, that's it ?


bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #54 on: January 21, 2011, 04:46:56 pm »
Ok thanks a lot dude for your help.

I remember that frogger worked well with cabmame 139.


So I launch frogger via the command prompt, with -verbose ? And after ? it will generate a log file, that's it ?



It will output text to the console, but you can add > logfile.txt to the end of the mame command after the -verbose argument, and it'll put it into a file for you that you should be able to zip up and post here.

EvilDindon

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 47
  • Last login:December 03, 2014, 11:34:33 am
Re: CabMame
« Reply #55 on: January 21, 2011, 04:49:48 pm »
Ok will see that, thanks, i'll see that.

EvilDindon

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 47
  • Last login:December 03, 2014, 11:34:33 am
Re: CabMame
« Reply #56 on: January 21, 2011, 05:15:42 pm »
OK here we are. It seems that mame picks a weird resolution lol :


Parsing mame.ini
Parsing mame.ini
Video: Monitor 00010001 = "\\.\DISPLAY1" (primary)
DirectDraw: Using DirectDraw 7
DirectDraw: Configuring device RADEON 7000 / RADEON VE
Target refresh = 60.606061
DirectDraw: Selecting video mode...
   240x 240@ 60Hz -> 622.642556
   256x 240@ 60Hz -> 622.642574
   256x 256@ 60Hz -> 622.642593
   256x 264@ 60Hz -> 622.642603
   288x 240@ 60Hz -> 622.642612
   296x 240@ 60Hz -> 622.642622
   304x 240@ 60Hz -> 622.642632
   321x 240@ 60Hz -> 622.642655
   321x 256@ 60Hz -> 622.642676
   336x 240@ 60Hz -> 622.642675
   352x 256@ 60Hz -> 622.642720
   352x 264@ 60Hz -> 622.642732
   352x 288@ 60Hz -> 622.642770
   368x 240@ 60Hz -> 622.642720
   384x 288@ 60Hz -> 622.642823
   392x 240@ 60Hz -> 622.642757
   401x 256@ 60Hz -> 622.642797
   448x 240@ 60Hz -> 622.642852
   512x 240@ 60Hz -> 622.642979
   512x 288@ 60Hz -> 622.643091
   512x 448@ 60Hz -> 622.643631
   512x 512@ 60Hz -> 622.643561
   632x 264@ 60Hz -> 622.643376
   640x 240@ 60Hz -> 622.643322
   640x 288@ 60Hz -> 622.643496
   640x 480@ 60Hz -> 622.644571
   640x 480@ 72Hz -> 80.687662
   640x 480@ 75Hz -> 64.963696
   640x 480@ 85Hz -> 39.382541
   640x 480@ 90Hz -> 32.904362
   640x 480@100Hz -> 24.759257
   640x 480@120Hz -> 16.561020
   640x 480@160Hz -> 9.963828
   640x 480@200Hz -> 7.125882
   648x 288@ 60Hz -> 622.643528
   720x 480@ 60Hz -> 622.645569
   800x 600@ 47Hz -> 68.468230
   800x 600@ 56Hz -> 178.381870
   800x 600@ 60Hz -> 622.645000
   800x 600@ 70Hz -> 96.213410
   800x 600@ 72Hz -> 80.688091
   800x 600@ 75Hz -> 64.964125
   800x 600@ 85Hz -> 39.382970
   800x 600@ 90Hz -> 32.904791
   800x 600@100Hz -> 24.759686
   800x 600@120Hz -> 16.561449
   800x 600@160Hz -> 9.964257
   800x 600@200Hz -> 7.126311
  1024x 768@ 43Hz -> 56.493182
  1024x 768@ 60Hz -> 625.388757
  1024x 768@ 70Hz -> 98.957166
  1024x 768@ 72Hz -> 83.431848
  1024x 768@ 75Hz -> 67.707882
  1024x 768@ 85Hz -> 42.126727
  1024x 768@ 90Hz -> 35.648547
  1024x 768@100Hz -> 27.503442
  1024x 768@120Hz -> 19.305205
  1024x 768@150Hz -> 13.809941
  1024x 768@160Hz -> 12.708013
  1024x 768@200Hz -> 9.870067
DirectDraw: Mode selected = 1024x 768@ 60Hz
DirectDraw: primary surface created: 1024x768x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectDraw: New blit size = 957x472
DirectDraw: blit surface created: 957x472x32 (R=00FF0000 G=0000FF00 B=000000FF)
DirectSound: Primary buffer: 48000 Hz, 16 bits, 2 channels
RawInput: APIs detected
Input: Adding Mouse #1: Souris HID
Input: Adding Gun #1: Souris HID
Input: Adding Mouse #2: Souris HID
Input: Adding Gun #2: Souris HID
Input: Adding Kbd #1: Clavier standard 101/102 touches ou clavier Microsoft Natural Keyboard PS/2
DirectInput: Using DirectInput 7
Input: Changing default joystick map = s8.4s8.44s8.4445
  s8888888s
  4s88888s6
  44s888s66
  444555666
  444555666
  444555666
  44s222s66
  4s22222s6
  s2222222s
Input: Changing default joystick map = s8.4s8.44s8.4445
  s8888888s
  4s88888s6
  44s888s66
  444555666
  444555666
  444555666
  44s222s66
  4s22222s6
  s2222222s
Input: Changing default joystick map = s8.4s8.44s8.4445
  s8888888s
  4s88888s6
  44s888s66
  444555666
  444555666
  444555666
  44s222s66
  4s22222s6
  s2222222s
Resolution change from 2752944x2752752 to 957x472
Starting Driver Device 'root'
  (missing dependencies; rescheduling)
Starting Z80 'maincpu'
Starting Video Screen 'screen'
Starting Timer 'stars'
Starting Speaker 'mono'
  (missing dependencies; rescheduling)
Starting Intel PPI8255 'ppi8255_0'
Starting Intel PPI8255 'ppi8255_1'
Starting Z80 'audiocpu'
Starting AY-3-8910A '8910.0'
Starting Discrete 'konami'
Starting Driver Device 'root'
  (missing dependencies; rescheduling)
Starting Speaker 'mono'
Starting Driver Device 'root'
Sound: buffer overflows=1 underflows=0

EvilDindon

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 47
  • Last login:December 03, 2014, 11:34:33 am
Re: CabMame
« Reply #57 on: January 21, 2011, 05:18:21 pm »
Just tested gorf and it has the same issue than frogger.

Edit : moon cresta too :(
« Last Edit: January 21, 2011, 05:24:37 pm by EvilDindon »

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #58 on: January 21, 2011, 05:40:32 pm »
Just tested gorf and it has the same issue than frogger.

Edit : moon cresta too :(
Double check the non-patched mame 0141, I suspect this might be more to do with 0141 perhaps, not sure why it's choosing such a wrong resolution.

EvilDindon

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 47
  • Last login:December 03, 2014, 11:34:33 am
Re: CabMame
« Reply #59 on: January 21, 2011, 06:31:02 pm »
Hey man I forgot to mention that I'm running mame using an arcadeVGA, not soft15.

That maybe explain the difference in ou results for frogger ?

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #60 on: January 21, 2011, 06:35:29 pm »
Hey man I forgot to mention that I'm running mame using an arcadeVGA, not soft15.

That maybe explain the difference in ou results for frogger ?
Well actually I'm running it in Linux where it can create any modeline on the fly at runtime, and have a d9800.  I think with this, the Soft15KHz and arcadeVGA should be about the same.  Although again it could be something in the drivers or the arcade vga card, but I don't think it is.  If gorf does the exact same thing, it seems like it's possible my thought about mame 0141 having a bug with these certain games may be correct.  It may be in Linux I'm slightly overcoming the frogger issue, but in gorf it's different and for it even without changing resolutions just running it stretched it's all way too skinny now and an exact patched version of mame 0140u2 doesn't do that for me.

EvilDindon

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 47
  • Last login:December 03, 2014, 11:34:33 am
Re: CabMame
« Reply #61 on: January 23, 2011, 04:27:43 am »
So if I understand well, you encounter a similar problem as me with gorf, but not with frogger ?

Damn, frogger was one of the most played game on my cab  :(

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #62 on: January 23, 2011, 04:43:29 am »
So if I understand well, you encounter a similar problem as me with gorf, but not with frogger ?

Damn, frogger was one of the most played game on my cab  :(
Yeah, I'm blaming mame for now, will see if it changes in the next release patch at all.  Seems to be centered around the version, from what I can tell 0140u2 was fine with both games.  Since they are both different drivers, from what I can tell offhand at least, looks like that might be able to explain why with actual resolution usage I'm doing frogger works correctly while gorf breaks still.  I really can't explain though why both break similar, from what I can tell they should be totally separate, but seeming the similar type of break in both and the difference of the frogger patch vs. gorf patch seems to say it's outside anything we are doing in the cabmame hacks at all.

EvilDindon

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 47
  • Last login:December 03, 2014, 11:34:33 am
Re: CabMame
« Reply #63 on: January 24, 2011, 04:14:44 pm »
Hey,

I tried to compile mame on my own with the 141 sources, the hi score diff and the cabmame diffs

When I tried to apply the frogger patch, it returned an error.

Have you noticed it yourself ?

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #64 on: January 24, 2011, 04:25:03 pm »
Hey,

I tried to compile mame on my own with the 141 sources, the hi score diff and the cabmame diffs

When I tried to apply the frogger patch, it returned an error.

Have you noticed it yourself ?


Try these patches, they are against 141u1, this should apply clean.  Also I've got a 32 bit build up of 0141u1 too.

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

Basically the groovyarcade_0141u1.diff file is the complete cabmame patches and a few other tweaks.  Note too that the hiscore.dat file must be in the \hi\ directory, that way it can stay in one place and isn't ambiguous where it should be.


« Last Edit: January 26, 2011, 05:21:27 pm by bitbytebit »

EvilDindon

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 47
  • Last login:December 03, 2014, 11:34:33 am
Re: CabMame
« Reply #65 on: January 24, 2011, 05:23:08 pm »
Wow man, thanks this is awesome, will try it out now.

Hope that frogger gorf and moon cresta will be ok in 141u1

But, tell me, the 141u1 cabmame patches aren't out, have you modified them to work on 141u1 ?
« Last Edit: January 24, 2011, 05:25:10 pm by EvilDindon »

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #66 on: January 24, 2011, 05:30:03 pm »
Wow man, thanks this is awesome, will try it out now.

Hope that frogger gorf and moon cresta will be ok in 141u1

But, tell me, the 141u1 patches aren't out, have you modified them to work on 141u1 ?

On my system Gorf wasn't right until I forced it into CGA mode, using a d9800 and seems it doesn't like the EGA resolution around 23khz and when pushing it back into normal 15khz mode it worked.  I'm still not sure what is going on there, I'm wondering if your seeing the same deal with frogger, but yet there still seems to be something odd going on and I need to test but seems like it'd be in mame itself and not the patches.  Since I could run with my 0140u2 with the same patches, and gorf is fine there.  I'll try a clean build of 0141u1 here and make sure, have you tried a clean build of 0141 and seen any difference in gorf and/or frogger there?

The original 0141 hiscore patch works fine with a little bit of fixing for the config options to apply. 

EvilDindon

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 47
  • Last login:December 03, 2014, 11:34:33 am
Re: CabMame
« Reply #67 on: January 25, 2011, 06:53:12 am »
Hey,

I got an error when applying the hiscore patch.

Anyway i think i'll download your win32 build

Thanks again man.


EvilDindon

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 47
  • Last login:December 03, 2014, 11:34:33 am
Re: CabMame
« Reply #68 on: January 25, 2011, 09:04:05 am »
Just tried your latest build on my cab, and I have the same issues for frogger/gorf/moon cresta.

Can you link me to your 140u2 build to test those games ?

I'd prefer 141 (or above)  for the new shoot'em ups, but I even prefer classics frogger and moon cresta over those shmups, so if 140u2 works fine for them, i'll keep it ;)
« Last Edit: January 25, 2011, 09:15:19 am by EvilDindon »

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #69 on: January 25, 2011, 10:08:57 am »
Just tried your latest build on my cab, and I have the same issues for frogger/gorf/moon cresta.

Can you link me to your 140u2 build to test those games ?

I'd prefer 141 (or above)  for the new shoot'em ups, but I even prefer classics frogger and moon cresta over those shmups, so if 140u2 works fine for them, i'll keep it ;)

Try it with -nocleanstretch, see if that fixes it at all.  I'm suspecting it might be centered around that.  Also if that doesn't work, then instead try adding -changeres and see if that helps.

EvilDindon

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 47
  • Last login:December 03, 2014, 11:34:33 am
Re: CabMame
« Reply #70 on: January 25, 2011, 10:46:05 am »
Thanks for those tips, will try it

EvilDindon

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 47
  • Last login:December 03, 2014, 11:34:33 am
Re: CabMame
« Reply #71 on: January 25, 2011, 12:50:35 pm »
Well I tried :

1/
cleanstretch 0
changeres0

2/
cleanstretch 1
changeres 1

3/
cleanstretch 0
changeres 1

4/
cleanstretch 1
changeres 0

And the result is that I get a very (very) small picture of the game (maybe 4x6 cm on the screen), but with the good proportions.   :banghead:

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #72 on: January 25, 2011, 12:54:07 pm »
Well I tried :

1/
cleanstretch 0
changeres0

2/
cleanstretch 1
changeres 1

3/
cleanstretch 0
changeres 1

4/
cleanstretch 1
changeres 0

And the result is that I get a very (very) small picture of the game (maybe 4x6 cm on the screen), but with the good proportions.   :banghead:

Try to add -hwstretch to those, that should allow it to expand to full screen.

EvilDindon

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 47
  • Last login:December 03, 2014, 11:34:33 am
Re: CabMame
« Reply #73 on: January 25, 2011, 04:13:19 pm »
I enabled hwstretch with no success ; when cleanstretch and changeres are disabled, the game picture fits appr. the quarter of the screen : when one of those parameters are enabled, the game screen is ridiculously small.

Also, the game runs very slow with the hwstretch enabled.

I really think it's a mame problem. Obviously, the cabmame frogger hack doesn't work well on this version.

In theory, with an arcadevga, you never need to enable hwstretch, cause what you want is to run the games at their native res.

Could you post an earlier build you made (140u2 or u3) to see if it's a mame.141 and above problem ?
« Last Edit: January 25, 2011, 04:38:15 pm by EvilDindon »

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #74 on: January 25, 2011, 05:18:23 pm »
I enabled hwstretch with no success ; when cleanstretch and changeres are disabled, the game picture fits appr. the quarter of the screen : when one of those parameters are enabled, the game screen is ridiculously small.

Also, the game runs very slow with the hwstretch enabled.

I really think it's a mame problem. Obviously, the cabmame frogger hack doesn't work well on this version.

In theory, with an arcadevga, you never need to enable hwstretch, cause what you want is to run the games at their native res.

Could you post an earlier build you made (140u2 or u3) to see if it's a mame.141 and above problem ?

I've uploaded 140u3 and 140u2 should be uploaded in a minute, definitely will be interesting to see.  I know that now gorf looks good for me with -nocleanstretch added (and always use -nochangeres and it's the default to be off). 

yeah I figured that, but odd that it's small, have you tried forcing the resolution to the right one with -resolution HxW@R args to mame?  Seems that it's doing it right there but not forcing mame to switch resolutions.  I really can't explain the gorf thing, somehow the cleanstretch patch now does something wrong for it although ok for me on all other games.  I see this on an arcade monitor and a normal LCD monitor too, same behavior with gorf.  Actually frogger works fine for me on the arcade monitor but when I use it on my LCD monitor it is really skinny vertical and wide horizontal and picks the 720x240 resolution or something ridiculous like that.  It's almost as if they have the logic for resolution choosing slightly altered now and it's making bad decisions, but that still doesn't explain what gorf is doing for me but does possibly explain the frogger issue.

EvilDindon

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 47
  • Last login:December 03, 2014, 11:34:33 am
Re: CabMame
« Reply #75 on: January 26, 2011, 07:25:05 am »
Hey I tried downloading several times 140u2 and u3 with no success : the download starts and stops 1 second after.

Anyways, I already tried forcing the resolution in the ini of the game, but it doesn't solve the problem.

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #76 on: January 26, 2011, 09:33:40 am »
Hey I tried downloading several times 140u2 and u3 with no success : the download starts and stops 1 second after.

Anyways, I already tried forcing the resolution in the ini of the game, but it doesn't solve the problem.
Ah I'll reupload those, somehow the file transfer bricked the files, weird.  I should have new ones up shortly, just removed the old ones so when you seen them up again there should be working versions hopefully to test.  

Update:  The sourceforge site is broken for my uploads, I opened a trouble ticket with them so hopefully they fix it soon :/.  I should have figured the free service would have some issues like this, right now all my uploads there within the last day are doing the same thing.
« Last Edit: January 26, 2011, 10:35:59 am by bitbytebit »

EvilDindon

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 47
  • Last login:December 03, 2014, 11:34:33 am
Re: CabMame
« Reply #77 on: January 26, 2011, 03:12:56 pm »
Man, just tried out a .139 build of cabmame and it does the same.

Although I swear an earlier cabmame version was working good for frogger and others.

Mayber it was 0.138. Will try it.

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #78 on: January 26, 2011, 06:32:21 pm »
Man, just tried out a .139 build of cabmame and it does the same.

Although I swear an earlier cabmame version was working good for frogger and others.

Mayber it was 0.138. Will try it.

Ah that figures, then there's something else at play but I'm not sure.  At least know it's nothing in my port of the patches, but also now sure why it's treating the games really oddly different for you, and somewhat for me too, yet I don't have the full ability to compare my Linux setup to my Windows one which now in Linux I've not seen the gorf issue since avoiding cleanstretch.

I also now have changed the location of these builds to a new site, http://mario.groovy.org/GroovyArcade/MameWindows/ so the old one no longer is there.  This one should be much more reliable in the future.

EvilDindon

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 47
  • Last login:December 03, 2014, 11:34:33 am
Re: CabMame
« Reply #79 on: January 27, 2011, 05:48:52 am »
Some good news. I found a solution to make all these games working well even with your 141u1 build. Even with gorf and frogger, but there's still something annoying with frogger.

Actually I had to play with three kind of parameters :

1/ In mame.ini, I set those parameters :

throttle 1
refreshspeed 0
redraw 0
cleanstretch 0
changeres 0
froggerhack 1
syncrefresh 0
waitvsync 0
video ddraw
hwstretch 0
triplebuffer 1
switchres 1

2/ In each game.ini :

In frogger.ini, bombjack.in, mooncrst.ini, gorf.ini, I specified the appropriate resolution :

resolution 256X240
except for gorf : resolution 336X240 (it feet perfectly the full screen)

3/ In the tab menu (OSD in game) :

For bombjack, frogger, gorf, karate champ, gun smoke and moon cresta, I had to go in the video options, and set "Standard (4:3)"or even "Debug". Then the games displayed correctly.

But still, for frogger, I have to do this each time I launch the game : if i don't fo this, the game displays like if the froggerhack is not working (only the half of the screen is visible and is stretched in the full screen). I verified in the frogger.cfg file, and the parameter is saved, but it still doesn't apply automatically, i have to do it manually every two launches of the game.

Dunno if there's a way to workaround this annoying frogger bug. I'll maybe use an interlaced 640X480 res, with hwstretch on and froggerhack off, even if i would have prefered to play in the native res.


But all in all, I'm quite happy with all these improvements  ;)

Edit : actually, a lot of games needs this to work : moon cresta, karate champ, gun smoke, frogger, gorf, etc.    :banghead:

I think I'll go back to mame 0.110 which worked like a charm on my cab.
« Last Edit: January 28, 2011, 02:50:44 am by EvilDindon »

Gray_Area

  • -Banned-
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 3363
  • Last login:June 23, 2013, 06:52:30 pm
  • -Banned-
Re: CabMame
« Reply #80 on: January 31, 2011, 04:00:00 pm »
These parameters can be entered and saved in each game's ini file, and the entries should remain.
-Banned-

EvilDindon

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 47
  • Last login:December 03, 2014, 11:34:33 am
Re: CabMame
« Reply #81 on: January 31, 2011, 04:53:52 pm »
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

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #82 on: February 04, 2011, 10:36:38 am »
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

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1694
  • Last login:June 15, 2022, 05:20:38 pm
    • forum.arcadecontrols.com/index.php/topic,103584.msg1096585.html#msg1096585
    • Newman Family Vlogs
Re: CabMame
« Reply #83 on: February 04, 2011, 10:42:56 am »
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

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #84 on: February 04, 2011, 10:55:08 am »
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

  • -Banned-
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 3363
  • Last login:June 23, 2013, 06:52:30 pm
  • -Banned-
Re: CabMame
« Reply #85 on: February 04, 2011, 08:28:50 pm »
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.....
-Banned-

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #86 on: February 06, 2011, 03:19:19 am »
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

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 4544
  • Last login:August 30, 2023, 05:10:22 pm
    • Arcade Ambience Project
Re: CabMame
« Reply #87 on: February 07, 2011, 03:31:15 pm »
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 109
  • Last login:January 04, 2022, 08:51:42 am
    • Metal Slug!
Re: CabMame
« Reply #88 on: February 10, 2011, 08:32:57 am »
Thanks, will give the 64bit version a go.  Hopefully it will sort out my tearing issues...

RVZ

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 109
  • Last login:January 04, 2022, 08:51:42 am
    • Metal Slug!
Re: CabMame
« Reply #89 on: February 19, 2011, 04:31:49 am »
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

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #90 on: February 19, 2011, 10:19:28 am »
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 252
  • Last login:April 05, 2025, 09:07:48 am
Re: CabMame
« Reply #91 on: February 24, 2011, 06:22:26 am »
Are you not releasing the diffs anymore? Would be useful since I need to also add the hack for guncons/wiimotes to work.
« Last Edit: February 24, 2011, 06:30:50 am by retrorepair »
My arcade racing setup:
My Youtube Channel: http://www.youtube.com/user/RetroRepair
My Twitter: http://twitter.com/retrorepair

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #92 on: February 24, 2011, 07:10:57 am »
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 252
  • Last login:April 05, 2025, 09:07:48 am
Re: CabMame
« Reply #93 on: February 24, 2011, 10:24:13 am »
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.
My arcade racing setup:
My Youtube Channel: http://www.youtube.com/user/RetroRepair
My Twitter: http://twitter.com/retrorepair

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #94 on: February 24, 2011, 10:45:47 am »
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 252
  • Last login:April 05, 2025, 09:07:48 am
Re: CabMame
« Reply #95 on: February 24, 2011, 01:16:11 pm »
That's great, thanks!

It pains me to hear gradius ii like that  :lol
My arcade racing setup:
My Youtube Channel: http://www.youtube.com/user/RetroRepair
My Twitter: http://twitter.com/retrorepair

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #96 on: March 04, 2011, 12:05:46 am »
That's great, thanks!

It pains me to hear gradius ii like that  :lol
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 252
  • Last login:April 05, 2025, 09:07:48 am
Re: CabMame
« Reply #97 on: March 08, 2011, 06:51:27 am »
Fantastic, thanks for this  :applaud:

I'll get testing for you.

Quote
- 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?
My arcade racing setup:
My Youtube Channel: http://www.youtube.com/user/RetroRepair
My Twitter: http://twitter.com/retrorepair

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #98 on: March 08, 2011, 09:25:42 am »
Fantastic, thanks for this  :applaud:

I'll get testing for you.

Quote
- 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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 252
  • Last login:April 05, 2025, 09:07:48 am
Re: CabMame
« Reply #99 on: March 08, 2011, 05:23:50 pm »
I mean with switchres since some games crash the system when using it with more than one core/hyperthreading (Tekken Tag for example)
My arcade racing setup:
My Youtube Channel: http://www.youtube.com/user/RetroRepair
My Twitter: http://twitter.com/retrorepair

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #100 on: March 08, 2011, 05:32:49 pm »
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 252
  • Last login:April 05, 2025, 09:07:48 am
Re: CabMame
« Reply #101 on: March 08, 2011, 06:00:33 pm »
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.
My arcade racing setup:
My Youtube Channel: http://www.youtube.com/user/RetroRepair
My Twitter: http://twitter.com/retrorepair

retrorepair

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 252
  • Last login:April 05, 2025, 09:07:48 am
Re: CabMame
« Reply #102 on: March 08, 2011, 10:45:47 pm »
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?
My arcade racing setup:
My Youtube Channel: http://www.youtube.com/user/RetroRepair
My Twitter: http://twitter.com/retrorepair

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #103 on: March 08, 2011, 10:59:24 pm »
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 252
  • Last login:April 05, 2025, 09:07:48 am
Re: CabMame
« Reply #104 on: March 09, 2011, 12:04:44 am »
Actually, it seems it's not patching a lot of the files when applying the groovymame diff. This is the first of many errors:

Quote
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.
My arcade racing setup:
My Youtube Channel: http://www.youtube.com/user/RetroRepair
My Twitter: http://twitter.com/retrorepair

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #105 on: March 09, 2011, 12:31:26 am »
Actually, it seems it's not patching a lot of the files when applying the groovymame diff. This is the first of many errors:

Quote
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 252
  • Last login:April 05, 2025, 09:07:48 am
Re: CabMame
« Reply #106 on: March 09, 2011, 12:43:21 am »
Ah I see. I tried -p1 though and got:

Quote
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.
My arcade racing setup:
My Youtube Channel: http://www.youtube.com/user/RetroRepair
My Twitter: http://twitter.com/retrorepair

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #107 on: March 09, 2011, 12:51:35 am »
Ah I see. I tried -p1 though and got:

Quote
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 252
  • Last login:April 05, 2025, 09:07:48 am
Re: CabMame
« Reply #108 on: March 09, 2011, 01:07:47 am »
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 :)
My arcade racing setup:
My Youtube Channel: http://www.youtube.com/user/RetroRepair
My Twitter: http://twitter.com/retrorepair

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #109 on: March 09, 2011, 01:15:54 am »
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 252
  • Last login:April 05, 2025, 09:07:48 am
Re: CabMame
« Reply #110 on: March 09, 2011, 01:47:53 am »
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.
« Last Edit: March 09, 2011, 01:49:33 am by retrorepair »
My arcade racing setup:
My Youtube Channel: http://www.youtube.com/user/RetroRepair
My Twitter: http://twitter.com/retrorepair

Calamity

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 7461
  • Last login:May 23, 2025, 06:07:25 am
  • Quote me with care
Re: CabMame
« Reply #111 on: March 09, 2011, 04:52:42 am »
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.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

retrorepair

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 252
  • Last login:April 05, 2025, 09:07:48 am
Re: CabMame
« Reply #112 on: March 09, 2011, 07:46:43 am »
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.
My arcade racing setup:
My Youtube Channel: http://www.youtube.com/user/RetroRepair
My Twitter: http://twitter.com/retrorepair

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #113 on: March 09, 2011, 10:16:46 am »
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.
« Last Edit: March 09, 2011, 11:00:50 am by bitbytebit »

Calamity

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 7461
  • Last login:May 23, 2025, 06:07:25 am
  • Quote me with care
Re: CabMame
« Reply #114 on: March 09, 2011, 12:17:45 pm »
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.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #115 on: March 09, 2011, 12:27:16 pm »
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

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #116 on: March 09, 2011, 05:00:28 pm »
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

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 252
  • Last login:April 05, 2025, 09:07:48 am
Re: CabMame
« Reply #117 on: March 10, 2011, 07:17:35 am »
That's great, I'll get testing this later on  :)

Thanks again bitbytebit!
My arcade racing setup:
My Youtube Channel: http://www.youtube.com/user/RetroRepair
My Twitter: http://twitter.com/retrorepair

Calamity

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 7461
  • Last login:May 23, 2025, 06:07:25 am
  • Quote me with care
Re: CabMame
« Reply #118 on: March 11, 2011, 08:38:10 am »
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.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Calamity

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 7461
  • Last login:May 23, 2025, 06:07:25 am
  • Quote me with care
Re: CabMame
« Reply #119 on: March 12, 2011, 11:36:02 am »
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.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #120 on: March 12, 2011, 11:48:56 am »
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.


Looks good, I just updated the patches and git repository with that change (I have the full source in git now too, http://mame.groovy.org lists it, can follow development and skip having to patch with that).  I'll rebuild the windows builds with it too here in a bit.

I think I can somewhat easily do the recalculation of the new modeline needed, I need to try to get that code to be more mobile so I can do it at that point.  Isn't that the place to alter the new modeline, seems like it would be.  I am going to drop resetting the old ones, since really not necessary to change them back since we always change them each use of them.  That way it should be pretty simple to jump from modeline to modeline this way as it's needed, I just need to make that code a bit easier to call quickly than having the complicated chunk in winmain.c as it is right now.

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #121 on: March 12, 2011, 01:12:54 pm »
Calamity,

Could you pull from the git repository and test it now, I hopefully have made it recalculate the modeline at resolution switching.  It at least should be close I think, but I'm not sure if there might be a few odds n ends to clean up.  Check the last change diff too and see how it's done, possibly any other additional improvements that you see could be made.  Hopefully this makes things really change resolution and get the best modeline and refresh rate for it each time.  If it works good, then I can create new diffs and builds, but figuring the git repository will work well for testing these changes since I don't have a windows/arcade monitor setup to test with.

Calamity

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 7461
  • Last login:May 23, 2025, 06:07:25 am
  • Quote me with care
Re: CabMame
« Reply #122 on: March 13, 2011, 01:02:09 pm »
I've compiled and tested it grabbing the files from your git (it's really cool to have the full source there). It's actually recalculating the modeline each time the resolution changes but seems the switchres_calc_modeline function doesn't get the new values and always recalculates the first resolution used, (so in ga2 you'll see it always getting the 416x224 one). Which param is actually used to extract the video mode from, machine.gamedrv or &machine.switchRes?
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #123 on: March 13, 2011, 02:39:02 pm »
I've compiled and tested it grabbing the files from your git (it's really cool to have the full source there). It's actually recalculating the modeline each time the resolution changes but seems the switchres_calc_modeline function doesn't get the new values and always recalculates the first resolution used, (so in ga2 you'll see it always getting the 416x224 one). Which param is actually used to extract the video mode from, machine.gamedrv or &machine.switchRes?
Do a pull, I just pushed a bunch of fixes and think I figured out possibly at least some of what would cause that.   I basically check and let the machine.resolution. stuff override the machine.gamedrv values if the resolution height and width are filled in, which only happens after a resolution change.  Also there's the .ini file that has to be overridden too with the resolution informaiton, because I set those values to force the resolution the first modeline calculation, unless the already exist, so then after that they must be updated too but also know they'll not be 0 because we set them.  I need to probably work on the .ini file issue some more, right now hopefully it works, but I have to probably store the fact there was an .ini file resolution so we can ignore changes in resolution if someone wants to force the same resolution the whole time.

I also just made a change, I think I might have found the issue, see if it prints this out:
INI File resolution: %dx%d@%d

the changes I made should prevent that unless there really was a .ini file, also I was not running the modline calcuations without overwriting the configuration each time, I fixed that.

It might work better, good news too on the Linux side, I might just have that somewhat working soon possibly.  Some weirdness there, definitely it won't be switching through SDL because it seems deeply in SDL where it won't read modelines again unless you completely kill off and restart SDL (which of course doesn't work very nice at all).  I'm probably going to override SDL after the first modeline and any new ones will use xrandr to switch, I just have to figure out now how to resize/remaximize the window to the new resolution (probably very similar to what the windows code is doing actually).

Calamity

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 7461
  • Last login:May 23, 2025, 06:07:25 am
  • Quote me with care
Re: CabMame
« Reply #124 on: March 13, 2011, 03:44:33 pm »
Now the new modeline is being properly recalculated it seems for what it prompts with -v so that probably is working ok, I have a problem however with this build here, the monitor options are not probably read or something, so it defaults to cga and a random aspect_ratio, don't know if it's a problem with my build not having properly updated your files but the compiler didn't give any errors.

Update: definitely the monitor options are wrong, when it prints "Monitor: %s Orientation: %s\n", it says Monitor: 000100010 or something like that.
« Last Edit: March 13, 2011, 04:50:34 pm by Calamity »
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #125 on: March 13, 2011, 10:04:50 pm »
Now the new modeline is being properly recalculated it seems for what it prompts with -v so that probably is working ok, I have a problem however with this build here, the monitor options are not probably read or something, so it defaults to cga and a random aspect_ratio, don't know if it's a problem with my build not having properly updated your files but the compiler didn't give any errors.

Update: definitely the monitor options are wrong, when it prints "Monitor: %s Orientation: %s\n", it says Monitor: 000100010 or something like that.

Make sure to do a complete make clean, remove entire obj directory, it might be something like that and everything needs to be recompiled.  I'll double check things, but it sounds  like it might be related to the fixes I did and not all the code getting recompiled with that change.

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #126 on: March 14, 2011, 12:15:52 am »
Now the new modeline is being properly recalculated it seems for what it prompts with -v so that probably is working ok, I have a problem however with this build here, the monitor options are not probably read or something, so it defaults to cga and a random aspect_ratio, don't know if it's a problem with my build not having properly updated your files but the compiler didn't give any errors.

Update: definitely the monitor options are wrong, when it prints "Monitor: %s Orientation: %s\n", it says Monitor: 000100010 or something like that.

Make sure to do a complete make clean, remove entire obj directory, it might be something like that and everything needs to be recompiled.  I'll double check things, but it sounds  like it might be related to the fixes I did and not all the code getting recompiled with that change.

Also I've made a few changes to make the .ini file honored and setup the resolution variable a bit better, so do a new pull in git and complete make clean and build again.  In Linux it's odd because it in theory would work but it seems Linux/SDL will lock the resolution change ability somehow so it doesn't allow even xrandr to work.  It does look like the correct monitor is used to calculate, so probably the other issue your seeing I'm guessing is from not doing a complete make clean, otherwise seems like some other trickiness happening.

Calamity

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 7461
  • Last login:May 23, 2025, 06:07:25 am
  • Quote me with care
Re: CabMame
« Reply #127 on: March 14, 2011, 06:18:25 am »
I'll get the new files and try a new clean build of the whole thing today, I just hoped I could avoid doing that as it takes so long but I figured it could be something related to old object files getting mixed up as I've seen problems like that before, I somewhat thought the make tool could do a better job guessing dependencies and stuff but it has to be complicated thing to do. Hopefully the Linux part will be figured up sooner or later.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #128 on: March 14, 2011, 12:52:39 pm »
I'll get the new files and try a new clean build of the whole thing today, I just hoped I could avoid doing that as it takes so long but I figured it could be something related to old object files getting mixed up as I've seen problems like that before, I somewhat thought the make tool could do a better job guessing dependencies and stuff but it has to be complicated thing to do. Hopefully the Linux part will be figured up sooner or later.
yeah there's some issues I always see with the building and changes made, sometimes just depends on what was changed and other things like adding stuff to the structures requires a complete rebuild.  Most changes don't require a complete make clean, but the last one for the .ini file fixes does for sure.  From what I can tell it technically should not be having issues with the monitor type though, at least now, since in Linux it's retaining the same monitor type and all that code is pretty much the same for both linux and windows. 

It's like in SDL there's a lock on video mode changes, I can add video modes, but can't see them or switch to the new ones from an SDL enabled app, only the ones that were there when SDL first loaded.   I am totally confused why xrandr is also affected by this, thought it would bypass it but it says it can't see the video modes when run but can add them fine.  I'm starting to wonder if it'd be easier to fix SDL or change it to allow new video modes, or really figure out how to completely tear down and bring back up the mame OSD in mid game.  Either one is probably really tricky to do, and most likely required to get around the problem.

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #129 on: March 15, 2011, 08:19:07 am »
I synced the builds and patches to git, so are now labeled as version .006 and can be tested more to see if the resolution changing is working right or if it needs more work.  Also this should possibly fix some issues with how soundsync worked and really turn it off, the configuration settings issue I saw with fixing the changeres stuff also affected that too.

Calamity

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 7461
  • Last login:May 23, 2025, 06:07:25 am
  • Quote me with care
Re: CabMame
« Reply #130 on: March 15, 2011, 08:23:25 am »
Probably today I'll be able to compile and test it. I've been trying to do it do it twice but for one or the other reason I had to stop it and messed it up, I haven't been able to stay more than two hours in the same place for some days...
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

retrorepair

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 252
  • Last login:April 05, 2025, 09:07:48 am
Re: CabMame
« Reply #131 on: March 15, 2011, 11:46:02 am »
So I just tested the latest build on my cab and here's my findings (apologies if I'm repeating known info here):

Soundsync can now be fully disabled, at least in the games I tested (Tekken Tag, Gradius 4, Gradius 2) :)

switchres (now called changeres?) works with some oddities. When changing resolution in game, it seems to take a lot longer than it should and the MAME command windows flashes up about 3 times in between. I have MALA hiding the MAME window by default and if I change that to minimise things freak out and it doesn't focus on the MAME render window once it's done changing resolutions.

Tekken Tag seems to work great, switches from interlace to progressive as it should, though the initial boot screen (coloured bars) is compressed at the sides as MAME usually renders it. However it seems other PSX based games now won't go into a progressive mode as they always have before with cabmame. I tried Shikigami no Shiro, G-Darius and Psyvariar which are all the same.

Multithreading with switchres doesn't hang up the system any more though :)
My arcade racing setup:
My Youtube Channel: http://www.youtube.com/user/RetroRepair
My Twitter: http://twitter.com/retrorepair

Calamity

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 7461
  • Last login:May 23, 2025, 06:07:25 am
  • Quote me with care
Re: CabMame
« Reply #132 on: March 15, 2011, 12:28:53 pm »
switchres (now called changeres?) works with some oddities. When changing resolution in game, it seems to take a lot longer than it should and the MAME command windows flashes up about 3 times in between. I have MALA hiding the MAME window by default and if I change that to minimise things freak out and it doesn't focus on the MAME render window once it's done changing resolutions.

It's always been "changeres" in CabMame, "switchres" param is from Mame itself, to enable resolution switching (if it's off it will default to your desktop resolution).

Yes, this "new" method of switching resolutions on the fly is not the smoothest possible, I just wanted to find one that was safe and stable enough and start optimizing it from there. It seems the problem with the other one was that it tried to destroy the window from the main thread, so this method uses Mame's native ortodox functions to toggle fullscreen on/off.

I'll try the new build tonight and report.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

retrorepair

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 252
  • Last login:April 05, 2025, 09:07:48 am
Re: CabMame
« Reply #133 on: March 15, 2011, 01:45:33 pm »
Ah. I often get those confused.

I expected to be repeating known info there, just thought I'd offer some feedback. I had a feeling it was preliminary work, it certainly did the trick though.
My arcade racing setup:
My Youtube Channel: http://www.youtube.com/user/RetroRepair
My Twitter: http://twitter.com/retrorepair

Calamity

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 7461
  • Last login:May 23, 2025, 06:07:25 am
  • Quote me with care
Re: CabMame
« Reply #134 on: March 15, 2011, 06:27:05 pm »
I've finally been testing this version. I've attached some logs.

ga2 is switching resolutions properly but if you see the log it looks like it's not updating the right modeline after first switch yet, it still tries to recalculate 416x224 one (although the right 320x224 resolution is selected by ddraw after that)

twincobr uses a single resolution but in this case it's virtualized for my monitor as expected. However the proper stretch does not occur and instead of that the picture appears as a wide panoramic band of only 320 pixels tall. If you see the log, notice this line:

DirectDraw: blit surface created: 720x320x32 (R=00FF0000 G=0000FF00 B=000000FF)

(this game was working perfectly right before so there must be something broken since last change)
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #135 on: March 15, 2011, 07:26:33 pm »
I've finally been testing this version. I've attached some logs.

ga2 is switching resolutions properly but if you see the log it looks like it's not updating the right modeline after first switch yet, it still tries to recalculate 416x224 one (although the right 320x224 resolution is selected by ddraw after that)

twincobr uses a single resolution but in this case it's virtualized for my monitor as expected. However the proper stretch does not occur and instead of that the picture appears as a wide panoramic band of only 320 pixels tall. If you see the log, notice this line:

DirectDraw: blit surface created: 720x320x32 (R=00FF0000 G=0000FF00 B=000000FF)

(this game was working perfectly right before so there must be something broken since last change)

Cool, thanks for the log files.  I think I fixed it, the patch is updated and also the git repository.  I need to redo the builds but might be later tonight.

Update: builds are being uploaded, will be .007, make sure they look like they are the right size since I'm uploading them into place :)

Update2: Realized after I left the house and going over the code an issue, so not ready just yet.  When the resolution change setting is kept, I should not change it, and the height/width used in the actual window.c code to resize the window should be the result of the modeline calculation and not the resolution mame had wanted that we used.

Update3: Ok I uploaded new patches/builds with the fix for that, only would have been an issue for a vertical game or virtualized resolutions for changes in resolution I am guessing.  Now should be mostly correct, of course I suspect a few lingering problems, hopefully can figure out the SDL issue in Linux because I'd really like to see it working and would help testing it for me.
« Last Edit: March 15, 2011, 11:20:45 pm by bitbytebit »

Calamity

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 7461
  • Last login:May 23, 2025, 06:07:25 am
  • Quote me with care
Re: CabMame
« Reply #136 on: March 16, 2011, 10:45:47 am »
New logs attached:

ga2 seems it's fixed now, the right registry modeline is used now for resolution switching, so things seem to be working here.
twincobr still has the same problem, uses a wide rectangle of 720x320, stretching is not working for some reason.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #137 on: March 16, 2011, 12:31:12 pm »
New logs attached:

ga2 seems it's fixed now, the right registry modeline is used now for resolution switching, so things seem to be working here.
twincobr still has the same problem, uses a wide rectangle of 720x320, stretching is not working for some reason.
Is it possibly the cleanstretch option affecting it, that should now actually get enabled or disabled, before it was always disabled actually I'm guessing in virtualized modes.  Try the newest git, be warned I've done some big changes, but want to test that it now can actually reset all the registry modelines back to how they were as it switches properly.  Besides that, also now you can force cleanstretch off all the time even if thought to be needed, basically doesn't set it if not set in the .ini or command line.  Try disabling it completely and see if virtualization works better, or maybe forcing it always enabled.  At the bottom of switchres.c where it makes those decisions based on the result of the modeline, that's where you can do that.  It may need to be different on Windows with hardware stretch opposed to in SDL with unevenstretch.

Calamity

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 7461
  • Last login:May 23, 2025, 06:07:25 am
  • Quote me with care
Re: CabMame
« Reply #138 on: March 16, 2011, 01:35:57 pm »
Yes, it could be the cleanstretch option getting in the middle, i'll try that later and let you know...
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #139 on: March 16, 2011, 01:42:51 pm »
Yes, it could be the cleanstretch option getting in the middle, i'll try that later and let you know...
That's such an interesting option to me now, I never realized before doing this inside of mame itself how that cleanstretch option can be a key in not needing keepaspect in Linux.  Also it seems to get the aspect perfectly for me now too, on a 16:9 monitor I can setup modelines that make vertical games correct in width without keepaspect now.  The normal scaling and stretch, actually even non-stretching, in mame won't do that for me.  I think it's main thing is it calculates the x and y scale for the height and width separately, seems like that's the key, otherwise I get squares on certain games sort of.  I also of course see how in the Windows code there's a completely different interaction, and all the variables change on what looks correct and what doesn't.  I'm not sure why the old changeres option cut out all scaling, so that's another interesting difference to look at too.

Calamity

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 7461
  • Last login:May 23, 2025, 06:07:25 am
  • Quote me with care
Re: CabMame
« Reply #140 on: March 16, 2011, 02:12:34 pm »
Well, afaik the cleanstretch hack was thought for d3d only, not for ddraw. This was because d3d always introduces some sort of fractional stretching (although d3d is what most systems use nowadays for rendering 2D stuff, it's actually a highly barroque way of doing things if you ask me. DirectDraw has a much more reasonable approach of what a frame buffer should be).

We do not stretch normally with ddraw (we're trying to get pixel perfect always that we can), and in the situations where we're using stretching we always have interlace enabled (when we virtualize due to our monitor limitations), so we DO want to have fractional stretching (filtered), as it highly reduces the flicker associated to interlaced resolutions. So I think it's safe to disable cleanstretch when using ddraw. However, I might be missing something about the cleanstretch option.

In ddraw we explicitly ask Mame to stretch the picture by using hwstretch option. I think the difference with unevenstretch is that hwstretch already has the keepaspect option built in it seems, while with unevenstretch you have to explicitly add keepaspect, otherwise it will stretch the game to full screen regardless the original aspect, maybe that's why cleanstretch is helping there recalculating things with the correct aspect ratio.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #141 on: March 16, 2011, 02:24:42 pm »
Well, afaik the cleanstretch hack was thought for d3d only, not for ddraw. This was because d3d always introduces some sort of fractional stretching (although d3d is what most systems use nowadays for rendering 2D stuff, it's actually a highly barroque way of doing things if you ask me. DirectDraw has a much more reasonable approach of what a frame buffer should be).

We do not stretch normally with ddraw (we're trying to get pixel perfect always that we can), and in the situations where we're using stretching we always have interlace enabled (when we virtualize due to our monitor limitations), so we DO want to have fractional stretching (filtered), as it highly reduces the flicker associated to interlaced resolutions. So I think it's safe to disable cleanstretch when using ddraw. However, I might be missing something about the cleanstretch option.

In ddraw we explicitly ask Mame to stretch the picture by using hwstretch option. I think the difference with unevenstretch is that hwstretch already has the keepaspect option built in it seems, while with unevenstretch you have to explicitly add keepaspect, otherwise it will stretch the game to full screen regardless the original aspect, maybe that's why cleanstretch is helping there recalculating things with the correct aspect ratio.
Interesting, in windows then it might be best to turn it off then.  Try the git version with -nocleanstretch and see how that works, it should always force it off now.

In Linux it seems that the cleanstretch option solves a big issue with stretching, that otherwise occurs no matter what.  So very odd, seems like the way it works make Linux do what happens normally in Windows without it and using ddraw and hwstretch turned off.

I got modeswitching working in Linux, if I change the SDL library to add the modeline reading function in the resize portion of SDL calls.  It statically reads it at startup, at video init actually, and so after that it won't read it again.  I'm still looking at that, there's still oddities like not resetting anymore to the original resolution on exit, but at least I've got the issue someone pinned down.

Update:  

Make that perfect resolution switching now in Linux/SDL.  Got the library patched at the ListModes point in X11 to re-read the modelines on the system, and have to do a funky trick when exiting if we switched modes.  Seems to catch 2 bugs that I can tell in SDL, first is the not re-reading the modelines at east listmodes call, second is it was always choosing the last used mode instead of the original one we had on the desktop.

Also note the last change in the git logs, one where I fixed the SDL for Linux, there is a change that forces cleanstretch off now for Windows when we are stretching there (oddly opposite of Linux, where stretching occurs if we don't use cleanstretch but doesn't if we do?)
« Last Edit: March 16, 2011, 04:09:02 pm by bitbytebit »

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #142 on: March 16, 2011, 04:30:08 pm »
I just uploaded new builds and the patch, so can test that, I have cleanstretch turn off in the windows switchres part if needing stretching.  So can see if that fixes virtualized games.  New patches also make a 'patches' directory with the SDL patch in it, for those wanting to use changeres in Linux correctly, which is working very nicely now.

Calamity

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 7461
  • Last login:May 23, 2025, 06:07:25 am
  • Quote me with care
Re: CabMame
« Reply #143 on: March 16, 2011, 06:29:10 pm »
 ???

The cleanstretch on/off didn't help, it might not be related to that.

twincobr is still the same, using 720x320 (that 320 value is actually the rotated xres that for some reason is getting used there, maybe the right 560 value is overwritten by one of the last code changes).

ga2 now crashes when it attempts to switch resolutions. Notice the log is not complete, it's missing the end of it but I'm able to see it prompted in the screen and it reaches the line "SwitchRes [ga2] (1) horizontal..." where the second resolution is about to be used.

BTW: Great news that you got that in Linux!
I'll try to check the new patches for the Windows part in case I see something...

Update: I've tested ga2 without the modeline option and it works, so it looks like the new code added to the winwindow_video_window_update function in window.c is what's making it crash, that function runs in the main thread so we probably should not be adding too much stuff there and better keep the changeres code in the windows thread, so at that point in winwindow_video_window_update we'd better send an special message to the window thread and wait for it to finish.
« Last Edit: March 16, 2011, 07:09:47 pm by Calamity »
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #144 on: March 16, 2011, 07:38:41 pm »
???

The cleanstretch on/off didn't help, it might not be related to that.

twincobr is still the same, using 720x320 (that 320 value is actually the rotated xres that for some reason is getting used there, maybe the right 560 value is overwritten by one of the last code changes).

ga2 now crashes when it attempts to switch resolutions. Notice the log is not complete, it's missing the end of it but I'm able to see it prompted in the screen and it reaches the line "SwitchRes [ga2] (1) horizontal..." where the second resolution is about to be used.

BTW: Great news that you got that in Linux!
I'll try to check the new patches for the Windows part in case I see something...

Update: I've tested ga2 without the modeline option and it works, so it looks like the new code added to the winwindow_video_window_update function in window.c is what's making it crash, that function runs in the main thread so we probably should not be adding too much stuff there and better keep the changeres code in the windows thread, so at that point in winwindow_video_window_update we'd better send an special message to the window thread and wait for it to finish.


Ah weird, it must be in the Windows side of the code for twincobr, can't repeat that in Linux so it must be somewhere in window.c.

The crash is odd, it might be explained though through me adding a count variable to the resolution structure so I can tell how many mode switches happened and reverse the resolution to the original in SDL.  I am completely rebuilding my windows binaries to see, and will upload those a little later.  I definitely do need to setup my windows system to test this, I think all the code to reset the old modelines are very possibly the issue.

Yeah the Linux stuff is looking nice now, so amazing it was just a simple little line in SDL to re-read those modelines. Now just to figure out what is going on in Windows.

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #145 on: March 16, 2011, 09:52:44 pm »
Yeah there's some issues I'm seeing in the code and am reworking the Windows stuff, also some of the SDL stuff too.  Some usage of the video_config variables combined with the need to make the modeline stuff a bit less dependent on the registry changing.  Also the cleanstretch option was actually being forced in some cases of stretching I think still.  Will hopefully get it sorted out in a bit, and have some builds with the changes to test.

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #146 on: March 16, 2011, 11:35:37 pm »
???

The cleanstretch on/off didn't help, it might not be related to that.

twincobr is still the same, using 720x320 (that 320 value is actually the rotated xres that for some reason is getting used there, maybe the right 560 value is overwritten by one of the last code changes).

ga2 now crashes when it attempts to switch resolutions. Notice the log is not complete, it's missing the end of it but I'm able to see it prompted in the screen and it reaches the line "SwitchRes [ga2] (1) horizontal..." where the second resolution is about to be used.

BTW: Great news that you got that in Linux!
I'll try to check the new patches for the Windows part in case I see something...

Update: I've tested ga2 without the modeline option and it works, so it looks like the new code added to the winwindow_video_window_update function in window.c is what's making it crash, that function runs in the main thread so we probably should not be adding too much stuff there and better keep the changeres code in the windows thread, so at that point in winwindow_video_window_update we'd better send an special message to the window thread and wait for it to finish.


Ah, I see, yeah I didn't see that update till now but makes sense I guess.  I didn't think about that when the normal check for changes occurs it's actually in the main thread.  Where do you think it should be setup and how to call that?  I haven't really gotten my mind around the whole separate thread part of mame and figured out too much of how to pass the code back and forth like that.  I do a lot of changes to test in git, but I *think* it'll crash when trying to switch resolutions with changeres (I'm recompiling from scratch to make sure).  I hopefully have gotten the virtualization issue worked out more though, not sure, but there's also the values assigned to the window->maxheight which I'm not sure the correct one, one is the resolution it had originally requested and the other is the one we've calculated and will use...
Code: [Select]
                       window->maxwidth =
                                window->machine->switchRes.resolution.width;
                                //window->machine->switchRes.modeLine->hactive;
                        window->maxheight =
                                window->machine->switchRes.resolution.height;
                                //window->machine->switchRes.modeLine->vactive;

I've made it so in theory changeres doesn't need modeline changes to work again, if there's available modelines that fit it, so can be used without just ATI cards again.  The odd crash is weird and I am suspecting recompiling, or what your saying about the windows thread and main one clashing, which also makes sense now too.

I changed the way it sets up the virtualization values, might help there I hope, shouldn't run into issues unless a changeres is turned on I am hoping, with crashing at least.  I also turned off keepaspect which I had been turning on for virtualization, that option does some weird stuff and in Linux it makes it so I can't figure out the original desktop size so I fully disable it there.  Not sure where to get the original desktop size if it's on, was using  window->monitor->center_width, window->monitor->center_height for that and works normally till keepaspect comes in and uses those values for the game size to aspect ratio it to that then I don't see where else I can find those values.  Might have to store them there or something, but that's a Linux problem, definitely more interested in the thread issue and how to do that right.

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #147 on: March 17, 2011, 03:05:15 am »
Calamity,

Oddly I see a crash still, but even with -nomt (newest git has it so it actually turns off again from the command line).  Also it's really strange, in the debugger and also when putting in print out statements, it's right when the readSoft15KhzResolutions() function is entered, but I don't see anything printed out in that function when I put it there or the debugger, and all input variables look good.  It's the second run of it, I'm wondering if I've really ever run it twice before, but guessing that one version working for you did run it twice.  Which exact date/version/filename was it called that worked, and can you see in the git logs around which commits probably introduced it?  Pretty odd, I don't know what it's doing, seems like some weird bug that isn't giving me any information at all about it. 

Calamity

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 7461
  • Last login:May 23, 2025, 06:07:25 am
  • Quote me with care
Re: CabMame
« Reply #148 on: March 17, 2011, 04:54:18 am »
Hi bitbytebit,

I think the previous binary (.007) was recalculating the modeline at mode switching without crashing at all.
I also think the virtualizing problems started after these changes:

http://forum.arcadecontrols.com/index.php?topic=107255.msg1169118#msg1169118

However I'm not completely sure as I was not able to get it to compile at some points in the middle. It could help me to have an updated diff of groovymame with all the last changes so I can compile it here removing just some lines each time, and test it through Ollydbg to check were the crash comes from. Also it could be interesting from the testing point of view (it could be there already, not sure) to have groovymame setup so that you can enable modeline option and go to the whole process even if the registry modelines are not found, having an internal boolean called UpdateRegistry or something set to 0/1 only used to block the access to the registry in case no ATI-like modelines are found.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #149 on: March 17, 2011, 07:04:51 am »
Hi bitbytebit,

I think the previous binary (.007) was recalculating the modeline at mode switching without crashing at all.
I also think the virtualizing problems started after these changes:

http://forum.arcadecontrols.com/index.php?topic=107255.msg1169118#msg1169118

However I'm not completely sure as I was not able to get it to compile at some points in the middle. It could help me to have an updated diff of groovymame with all the last changes so I can compile it here removing just some lines each time, and test it through Ollydbg to check were the crash comes from. Also it could be interesting from the testing point of view (it could be there already, not sure) to have groovymame setup so that you can enable modeline option and go to the whole process even if the registry modelines are not found, having an internal boolean called UpdateRegistry or something set to 0/1 only used to block the access to the registry in case no ATI-like modelines are found.


I've updated the patch on the site with what I have currently.  Oddly it seems as if there's any access to the dv[] TCHAR variable in the winreg.c code, after the DefaultVideo name is found and wrote to it, then the next run of the soft15khz function will fail.  It's odd, I'm not sure what is going on, definitely a tricky one. It just seams like running that function twice, becomes odd and corrupted but not sure why, it works fine the first time and then second run just entering the function is right where it fails.

Also check this version possibly for the virtualization issues, might be better.  I found some issues in Linux that looked like the same as you saw, when using cga monitor mode, so hopefully figured those out mostly.  Now it might change things to force cleanstretch off, possibly.

Yeah I have been somewhat trying to separate it from the registry writing as much, and now it does everything but enter the parts that write the registry and do the setup of the settings from the results of the registry modeline found. 

It doesn't seem to have any difference in multithreaded or non-multithreaded mode, so I'm guessing that isn't the issue, but definitely sounds nice to move that code into the other thread if possible. 

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #150 on: March 17, 2011, 09:30:52 am »
Calamity,

I just updated git, uploaded a patch, and am about done uploading a 32 bit build for Windows (64 coming) of version 010.  I got it to stop crashing in Windows, at least looks that way to me.  Check and see if you have it work better there, and what we need to do if anything with the virtualization  issues.  I hopefully also did something to fix that, now cleanstretch is off by default and changeres on.

I split up the method of reading the registry modelines, so I only read them on startup and use them after that so I no longer need to access the registry as much during the resolution changes.  I suspect that code was the issue having it run more than once, or it might be the thread part where the window update is that I am running the resolution change has issues if certain registry calls are made and gets sensitive.  Something strange there but now it seems to be working for me in testing, where before it was consistently crashing.  

Do you know where we should tuck the resolution change code that would be in the window thread, that is able to access the window structure and check for the changeres and act on it.  Figure we could hold off on the window update thread at touching resolutions resizes when changeres is set, and instead do it in the other location, unless you think it's ok where it's at now.  Since it only executes once or twice at startup usually if at all, resolution changes won't happen often, doesn't seem terrible there and that's of course where mame already had the basic idea of resolution resizing kept.

Update: make sure to use .010a, because I commented out some code that actually did something with the registry writing, and that build fixes it.
« Last Edit: March 17, 2011, 11:37:20 am by bitbytebit »

Calamity

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 7461
  • Last login:May 23, 2025, 06:07:25 am
  • Quote me with care
Re: CabMame
« Reply #151 on: March 17, 2011, 10:10:36 am »
Oh great, I'll test that when I get home. Also will think where's the right place to put the changeres code, however if you've fixed the crashing then it may be ok to keep it there by now (you're right actually, it shouldn't be a threads issue when it has worked before for me here in the previous version).
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

Calamity

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 7461
  • Last login:May 23, 2025, 06:07:25 am
  • Quote me with care
Re: CabMame
« Reply #152 on: March 17, 2011, 04:53:46 pm »
Well, things are improving here. Now it's working properly with no crash at all.

ga2: the changeres is working although instead of updating modeline 320x224 its choosing 328x224, after that Mame actually uses 320x224 so the updated modeline is not used. Could you have changed anything in the resolution selection algorithm? (it used to get the right one)

twincobr: now what happens is that the game covers the full screen. It's interesting because if I set the keepaspect option on, then it looks right but in any case the aspect n:d option is not having any effect there, neither the monitor_aspect one, so it seems the usual aspect managing in Mame is overriden for some reason since the last changes.

Hopefully during the weekend I'll have some time to look throgh the code, although it's likely you'll have it fixed already by then :)
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #153 on: March 17, 2011, 06:07:55 pm »
Well, things are improving here. Now it's working properly with no crash at all.

ga2: the changeres is working although instead of updating modeline 320x224 its choosing 328x224, after that Mame actually uses 320x224 so the updated modeline is not used. Could you have changed anything in the resolution selection algorithm? (it used to get the right one)

twincobr: now what happens is that the game covers the full screen. It's interesting because if I set the keepaspect option on, then it looks right but in any case the aspect n:d option is not having any effect there, neither the monitor_aspect one, so it seems the usual aspect managing in Mame is overriden for some reason since the last changes.

Hopefully during the weekend I'll have some time to look throgh the code, although it's likely you'll have it fixed already by then :)


I think I fixed those two problems.  Check the git diff of the last checkin and should be pretty obvious, I hope it is correct.  Basically in the virtualized game case the resolution we picked size in the registry needed to be give to the window->maxheight parameters instead of the original mame requested size.  Also the registry modeline picking was not setting the resolution setting input variable to the exact one the registry had, so it was looking for the original.

Will have some binaries as 010b up in a bit to test.

Calamity

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 7461
  • Last login:May 23, 2025, 06:07:25 am
  • Quote me with care
Re: CabMame
« Reply #154 on: March 17, 2011, 06:39:07 pm »
Testing 010b:

- twincobr is still the same, full screen.
- ga2 now ddraw and 'switchres' mode are synced, unfortunately switchres algorithm is picking 328 instead of 320x224.

Update: Shouldn't we be checking for "machine.switchRes.modeLine->result & RESULT_VIRTUALIZE" instead of this: (window.c)

Quote
                       // Aspect ratio specified
340                           if ((machine.switchRes.gameInfo.orientation && !strcmp(machine.switchRes.cs.morientation, "horizontal")) ||
341                               (!machine.switchRes.gameInfo.orientation && !strcmp(machine.switchRes.cs.morientation, "vertical")))
342                           {
343                                   options_set_string(&machine.options(), WINOPTION_ASPECT, machine.switchRes.cs.aspect, OPTION_PRIORITY_MAXIMUM);
344                           }

Oh, forget that, I see now that it's is checked right before...
« Last Edit: March 17, 2011, 07:09:52 pm by Calamity »
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #155 on: March 17, 2011, 10:52:57 pm »
Testing 010b:

- twincobr is still the same, full screen.
- ga2 now ddraw and 'switchres' mode are synced, unfortunately switchres algorithm is picking 328 instead of 320x224.

I made a change and uploaded the new diff/new builds as 010c.  Basically am now double checking for the exact height width first before trying the fuzzy matching, so we can get an exact match if it exists.  Really odd that changed, the code is pretty much exactly the same from what I can tell, only possible thing would be it reversed the direction it's searching the list or it was out of order, but I don't think either is occurring from what I can tell.  Seems like this is a good change though, better not go through the complicated checking unless we really need to.  I am also thinking this might have always been a weakness, just not sure why not triggered before.

I don't know what is going on with twincobr, but it is an odd game because on Linux it's always done the same thing without keepaspect.  What command line options can you run normally in mame with switchres and see it work perfectly?  I'm definitely getting interested in the Windows stretching, seems like I'm doing the exact same stuff as in switchres now and only thing I can think of is if cleanstretch is getting on somehow externally which I double, or some other trick is occurring.  The aspect ratio calculation shouldn't be altered, so I'm not sure why it's acting that way.  I'll also play around with it more here, seems like it's an issue duplicating the command line perfectly that works.


Also try running those tests for twincobr (and ga2 if it still has issues with the newest update) with the arg added -md 4 or more, that might give more details too.
« Last Edit: March 17, 2011, 11:04:21 pm by bitbytebit »

Calamity

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 7461
  • Last login:May 23, 2025, 06:07:25 am
  • Quote me with care
Re: CabMame
« Reply #156 on: March 18, 2011, 05:30:51 pm »
Well, this is definitely a mystery. I've rescued groovymame patch 004, and with it twincobr sets aspect ratio perfectly, and monitor_aspect works again, same mame.ini, same command line. I've attached the logs of both 004 and 010b patches, notice they both are actually using the same resolution, modelines, and all, so could be good to know which exact mame config options are actually being used to see if there's something wrong with that, maybe a side effect of some change that you've done recently.

On the other hand ga2 insists on selecting 328 instead of 320...

And also tried switchres by first time since and installed xp64, it's not working here (seems it can't find the path for mame binary, it's in the same folder), could it be a problem of this switchres being a 32bit build?
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #157 on: March 18, 2011, 06:32:00 pm »
Well, this is definitely a mystery. I've rescued groovymame patch 004, and with it twincobr sets aspect ratio perfectly, and monitor_aspect works again, same mame.ini, same command line. I've attached the logs of both 004 and 010b patches, notice they both are actually using the same resolution, modelines, and all, so could be good to know which exact mame config options are actually being used to see if there's something wrong with that, maybe a side effect of some change that you've done recently.

On the other hand ga2 insists on selecting 328 instead of 320...

And also tried switchres by first time since and installed xp64, it's not working here (seems it can't find the path for mame binary, it's in the same folder), could it be a problem of this switchres being a 32bit build?

Odd, really strange how the change I made didn't get that resolution correct, seems something else is going on.

I uploaded new 010d versions that now print out every option changed, that might help see what is going on hopefully.

I'll have to look deeper into what is going on with the registry modeline choice.

Calamity

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 7461
  • Last login:May 23, 2025, 06:07:25 am
  • Quote me with care
Re: CabMame
« Reply #158 on: March 18, 2011, 07:23:47 pm »
Well, finally got it. I have actually been wrong all this time on how I thought the keepaspect option was working. It is necessary indeed to have keepaspect on to enable the aspect correction mechanism to work, so if it's off it won't use the screen_aspect option at all. So just enabled it in the ini and it started to work as usual. I can't understand how I haven't noticed that while doing all the tests during these days, silly me, sorry.

Then it sounds this mechanism is exactly the same in Linux, and maybe explains why you've been seeing that also there.

Also have managed to get Switchres working again, so I can double test with it.

This weekend I'll have a look at that modeline selection function in case I see something that explains the 328 thing.
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #159 on: March 18, 2011, 07:29:20 pm »
Well, finally got it. I have actually been wrong all this time on how I thought the keepaspect option was working. It is necessary indeed to have keepaspect on to enable the aspect correction mechanism to work, so if it's off it won't use the screen_aspect option at all. So just enabled it in the ini and it started to work as usual. I can't understand how I haven't noticed that while doing all the tests during these days, silly me, sorry.

Then it sounds this mechanism is exactly the same in Linux, and maybe explains why you've been seeing that also there.

Also have managed to get Switchres working again, so I can double test with it.

This weekend I'll have a look at that modeline selection function in case I see something that explains the 328 thing.

Ah cool, well makes more sense to me now :) yeah I was really seeing in Linux it was required so didn't understand why in Windows it'd be different, hopefully having things print out like that will be nice for any other issues we run into now.

Also I just uploaded a 010e with more debugging output in the registry modeline selection, but of course will be another 010f now adding the keepaspect change, but they'll have that extra output from now on and possibly some more later tonight.

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #160 on: March 18, 2011, 09:44:43 pm »
Calamity,

Think it's fixed in 011, both issues most likely.  I just found the glaring error of my previous attempt to fix it, and at least confirmed it will really pick the exact match if it exists, where before it would not have.  Also the debug output at least will be even better at showing possible problems, if it still doesn't pick the right resolution.  Oddly I don't get why the fuzzy match ever picked an exact match, because from what I can tell the width was always going to be at least 8 pixels more.  Yet there may be something fishy still happening so I'm looking into it closer, but curious of course to see if this really fixes it there for your setup.

Calamity

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 7461
  • Last login:May 23, 2025, 06:07:25 am
  • Quote me with care
Re: CabMame
« Reply #161 on: March 20, 2011, 08:16:25 am »
New version 011 works great here, no problem with any game I've tested so far (quite a lot), so for me this version is already perfect, I mean it does all what Switchres does but with the changeres functionallity added (and all the other CabMame patches too).

Just curious of some new debug messages in the log like this one:
SwitchRes: Failed scanning registry modeline label DALDTMCRTBCD184X208X0X60, using values 184x208instead

It's strange as everything seems to work fine so could be a false error message or something?
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #162 on: March 20, 2011, 08:32:22 am »
New version 011 works great here, no problem with any game I've tested so far (quite a lot), so for me this version is already perfect, I mean it does all what Switchres does but with the changeres functionallity added (and all the other CabMame patches too).

Just curious of some new debug messages in the log like this one:
SwitchRes: Failed scanning registry modeline label DALDTMCRTBCD184X208X0X60, using values 184x208instead

It's strange as everything seems to work fine so could be a false error message or something?

Cool, I was hoping that last change fixed the two issues.

That error message is interesting, it means that there was a failure scanning the registry label for the values so it uses the actual vactive/hactive values instead.  Not something that is going to hurt anything, but the question is why does it fail to scan that string into the height/width/refresh integer values.    I guess it's good I added that warning, seems like something needs to be perfected there.  Does it do it every single registry entry or just a few?  

Update: Ah I see the logfile :) I fixed it, it's that your registry lines use capitol X instead of lowercase x like Soft15khz ones do which is how I test it.  I just added the fix to git, not probably a bug but more of an annoying warning message.  I'll update with the fix here in a second as 011a to test there and make sure it works right.
« Last Edit: March 20, 2011, 08:42:04 am by bitbytebit »

Calamity

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 7461
  • Last login:May 23, 2025, 06:07:25 am
  • Quote me with care
Re: CabMame
« Reply #163 on: March 20, 2011, 01:21:45 pm »
Well, things work perfect here now, no more debug error messages, I've attached the log. I agree it's good to have all that debugging info there, it will help in the future.

There's room for improvement in the Windows changeres method, I'll do some tests in case I can make it smoother, at the moment you can see Mame's window for an instant during resolution switching. However, I'm pretty sure this method is much more stable than the original one, so I'll see if I can get rid of some stuff inside the toogle_fullscreen function if it's possible.

I'm interested in how you achieved SDL reading the new modelines, did it need any kernel change or was it all done inside Mame code?
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #164 on: March 20, 2011, 01:30:08 pm »
Well, things work perfect here now, no more debug error messages, I've attached the log. I agree it's good to have all that debugging info there, it will help in the future.

There's room for improvement in the Windows changeres method, I'll do some tests in case I can make it smoother, at the moment you can see Mame's window for an instant during resolution switching. However, I'm pretty sure this method is much more stable than the original one, so I'll see if I can get rid of some stuff inside the toogle_fullscreen function if it's possible.

I'm interested in how you achieved SDL reading the new modelines, did it need any kernel change or was it all done inside Mame code?


Sounds good.  It was a simple one line change in the SDL library, just adding the function to read the system modelines when the ListModes X11 call is made (usually that only happens when SDL is initialized).  That was really all it needed, I had been fighting it for quite awhile thinking it might be something else, but they really allocate a static list of modelines in SDL at init and they usually never update again.  From there it's just at the same point in window.c when it detects the resolution change from the emu/render.c flagging of changeres, I sort of do my own version of checking the SDL resolutions and finding the correct one, feed that into the resize function.  It was quite interesting making it work, actually both the Linux and Windows versions to quite different yet similar things.  Have to admit it was more fun than I thought it would be and feel a lot better now about the general resolution switching since it's recursive now and generally seems to have worked out many of the bugs by requiring it to be capable of getting called multiple times.

Calamity

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 7461
  • Last login:May 23, 2025, 06:07:25 am
  • Quote me with care
Re: CabMame
« Reply #165 on: March 22, 2011, 01:43:07 pm »
I'm testing this patch (over the new groovymame one) to see if changeres can be smoother now, I'm rescuing the original patch by Sailorsat but placing it inside the window thread message processing function, creating a new custom message WM_USER_CHANGERES.

Code: [Select]
diff -Nru b/src/osd/windows/window.c c/src/osd/windows/window.c
--- b/src/osd/windows/window.c 2011-03-22 18:23:17.000000000 +0100
+++ c/src/osd/windows/window.c 2011-03-22 18:24:55.000000000 +0100
@@ -103,6 +103,7 @@
 #define WM_USER_SET_MINSIZE (WM_USER + 5)
 #define WM_USER_UI_TEMP_PAUSE (WM_USER + 6)
 #define WM_USER_EXEC_FUNC (WM_USER + 7)
+#define WM_USER_CHANGERES (WM_USER + 8)
 
 
 
@@ -920,10 +921,6 @@
  window->maxheight =
  window->machine->switchRes.bestMode.a_height;
 
- // Change resolution
- winwindow_toggle_full_screen();
- winwindow_toggle_full_screen();
-
  // Reset old video modeline
  if (window->machine->switchRes.resolution.count > 1) {
                 ModeLine DesktopMode;
@@ -945,9 +942,10 @@
  window->machine->switchRes.resolution.width;
  window->maxheight =
  window->machine->switchRes.resolution.height;
- winwindow_toggle_full_screen();
- winwindow_toggle_full_screen();
  }
+
+ // Change resolution
+ SendMessage(window->hwnd, WM_USER_CHANGERES, 0, 0);
  }
 
  // see if the target has changed significantly in window mode
@@ -1684,6 +1682,11 @@
  case WM_USER_SET_FULLSCREEN:
  set_fullscreen(window, wparam);
  break;
+
+ case WM_USER_CHANGERES:
+ (*draw.window_destroy)(window);
+ (*draw.window_init)(window);
+ break;
 
  // minimum size set
  case WM_USER_SET_MINSIZE:

I'll try this later on my cab and let you know if it works.

Update: I've done basic testing with this patch and looks stable with multithreading on, and it's actually smoother during resolution switching (you won't see the window minimized for an instant any more).

« Last Edit: March 22, 2011, 05:22:20 pm by Calamity »
Important note: posts reporting GM issues without a log will be IGNORED.
Steps to create a log:
 - From command line, run: groovymame.exe -v romname >romname.txt
 - Attach resulting romname.txt file to your post, instead of pasting it.

CRT Emudriver, VMMaker & Arcade OSD downloads, documentation and discussion:  Eiusdemmodi

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #166 on: March 23, 2011, 12:16:46 am »
Update: I've done basic testing with this patch and looks stable with multithreading on, and it's actually smoother during resolution switching (you won't see the window minimized for an instant any more).

Looks great, I applied the patch to git, and am uploading builds with these changes.

retrorepair

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 252
  • Last login:April 05, 2025, 09:07:48 am
Re: CabMame
« Reply #167 on: March 23, 2011, 05:31:32 pm »
Great work both of you, it works great now.  :applaud:

Only thing I noticed is G-Darius now starts off in a progressive mode then when the intro kicks in switches to an interlaced mode. I'm pretty sure it shouldn't, at least the old cabmame didn't.

Everything else I tried is great though :)
My arcade racing setup:
My Youtube Channel: http://www.youtube.com/user/RetroRepair
My Twitter: http://twitter.com/retrorepair

krick

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2006
  • Last login:May 23, 2025, 03:48:36 am
  • Gotta have blue hair.
Re: CabMame
« Reply #168 on: April 07, 2011, 11:03:10 pm »
Would there be any value in adding in the SmoothMAME 60Hz patch?

(check out the thread, then read the last post for an update)

http://www.mameworld.info/ubbthreads/showflat.php?Number=207738
Hantarex Polo 15KHz
Sapphire Radeon HD 7750 2GB (GCN)
GroovyMAME 0.197.017h_d3d9ex
CRT Emudriver & CRT Tools 2.0 beta 13 (Crimson 16.2.1 for GCN cards)
Windows 7 Home Premium 64-bit
Intel Core i7-4790K @ 4.8GHz
ASUS Z87M-PLUS Motherboard

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #169 on: April 07, 2011, 11:24:11 pm »
Would there be any value in adding in the SmoothMAME 60Hz patch?

(check out the thread, then read the last post for an update)

http://www.mameworld.info/ubbthreads/showflat.php?Number=207738

Interesting, I'll look at how that works and see if that can be non-obtrusively setup as an option.  Looks good for people that either don't have a supported video card for custom modelines, or a LCD monitors fixed at 60hz.  It would be interesting to change this around slightly to basically look at the available refresh rates and alter the game to those, instead of being hard wired at 60hz.  Definitely like the thread states, a non-arcade accurate hack, yet looks like something useful when there's no other choice with the hardware available.

krick

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2006
  • Last login:May 23, 2025, 03:48:36 am
  • Gotta have blue hair.
Re: CabMame
« Reply #170 on: April 08, 2011, 12:48:50 am »
From what I understand, even with a 15KHz arcade monitor and an ArcadeVGA, there will be games that have issues because they have a higher refresh rate than your arcade monitor.  I think this is supposed to cap everything at 60Hz to eliminate that possibility.
Hantarex Polo 15KHz
Sapphire Radeon HD 7750 2GB (GCN)
GroovyMAME 0.197.017h_d3d9ex
CRT Emudriver & CRT Tools 2.0 beta 13 (Crimson 16.2.1 for GCN cards)
Windows 7 Home Premium 64-bit
Intel Core i7-4790K @ 4.8GHz
ASUS Z87M-PLUS Motherboard

torino

  • -Banned-
  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 201
  • Last login:July 24, 2011, 05:18:12 pm
  • -Banned-
Re: CabMame
« Reply #171 on: April 08, 2011, 12:18:17 pm »
Would there be any value in adding in the SmoothMAME 60Hz patch?

(check out the thread, then read the last post for an update)

http://www.mameworld.info/ubbthreads/showflat.php?Number=207738

Interesting, I'll look at how that works and see if that can be non-obtrusively setup as an option.  Looks good for people that either don't have a supported video card for custom modelines, or a LCD monitors fixed at 60hz.  It would be interesting to change this around slightly to basically look at the available refresh rates and alter the game to those, instead of being hard wired at 60hz.  Definitely like the thread states, a non-arcade accurate hack, yet looks like something useful when there's no other choice with the hardware available.

The other day I was using some old VESA diagnostic utilities and it showed different refresh rates for different resolutions on my laptop's LCD, all the way from 53.xxHz to 60.xxHz, although I think that was an error, possibly due to WinXP.

Obviously I too am convinced PC LCDs do have truly fixed refresh rate, at 60Hz. However, my conclusion is rather based on the lack of information than anything else. Most LCDs are being sold without any specification given for their refresh rate as if there is some unspoken rule or is somehow self-implied, that they all run at fixed 60Hz. But then, I do not see any practical reason why they could not vary their refresh rate, so I am going to get another LCD and test it all again but this time from both Windows and DOS, and Linux if I can find any such diagnostic tools.


Anyway, in that case LCDs could only do authentic vertical refresh rate if the game's refresh rate is also 60Hz exactly, or they could force games to have 60Hz updates by slowing them down or speeding them up to 60Hz, which is the only good looking and proper way to do away with it. Anyhow else trying to fix this situation is just as artificial and ugly hack as digitally interpolating/extrapolating frames, i.e. making non-existing frames out of thin air or deleting existing ones and trying to arrange what's left evenly over time.

http://en.wikipedia.org/wiki/Telecine

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #172 on: April 08, 2011, 12:24:50 pm »
This might  be partly a Windows issue too.  In Linux on my LCD I can run a lot of odd resolutions just fine, I am pretty sure the refresh rates are not all 60Hz, but then again it might be a slight bit less accurate still than a CRT, I'm not sure though.  It might be the EDID, and Windows, especially Windows 7, totally giving in to the EDID which these monitors most likely have preset resolutions set at fixed amounts like 60Hz.  So if the OS like Windows has a very strict obeying nature to the EDID, it'll most likely stick to what the monitor tells it to do.  In Linux with an ATI card I can pretty much tell the monitor/video card whatever I want to, and it either displays it if really able to just goes blank.  Not for sure, but it might be some of the issue and why people say that LCD's can only do 60Hz, there might be other factors involved.

torino

  • -Banned-
  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 201
  • Last login:July 24, 2011, 05:18:12 pm
  • -Banned-
Re: CabMame
« Reply #173 on: April 08, 2011, 12:26:00 pm »
Bitbytebit, and to whomever it may concern,


Rather than trying to "fix" MAME, would you be interested to fork off another project, something like AdvanceMAME + SmoothMAME + FastMAME, only better, faster and simpler?

I already started the project and reached interesting point. I took MAME 0.88, for various reasons, and completely stripped it from EVERYTHING but core engine. I think around 70% went out yet it still can play games, and about 15% faster. Then I went and simplified drawgfx.c with intention to convert all the graphics data structures (sprites and tiles) into OpenGL textures and actually re-write the core drawing engine to support hardware acceleration and 3D in the very heart of graphics emulation.
 
However, at this point I realized that my empty Windows application, either OpenGL or DirectX, can not reach over 2000fps with nothing going on there but printing the fps on the screen, while VAntAGE emulator for DOS can run Galaga at 6000fps!!!!

I can not explain it, I barely believe myself, why and how can Windows application, or any of those APIs, come with such monstrous overhead, but that's how it is. So, I am now wondering should I go 15 years back in time and instead of using modern video hardware capabilities just do MAME re-write for VESA standard and actually make it several orders of magnitude FASTER. Unbelievable!


Anyway, would you be interested in such project, either OpenGL (SDL) or VESA based? My real goal is to make it really compact and simple so to be portable to mobile platforms, but beside speed and size my main concerned is smooth animation and authentic gameplay, so this should be something you would want to put in both, your arcade cabinet (with cheap old computer) and your shiny new mobile phone. How about it?



bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #174 on: April 08, 2011, 12:43:22 pm »
Bitbytebit, and to whomever it may concern,


Rather than trying to "fix" MAME, would you be interested to fork off another project, something like AdvanceMAME + SmoothMAME + FastMAME, only better, faster and simpler?

I already started the project and reached interesting point. I took MAME 0.88, for various reasons, and completely stripped it from EVERYTHING but core engine. I think around 70% went out yet it still can play games, and about 15% faster. Then I went and simplified drawgfx.c with intention to convert all the graphics data structures (sprites and tiles) into OpenGL textures and actually re-write the core drawing engine to support hardware acceleration and 3D in the very heart of graphics emulation.
 
However, at this point I realized that my empty Windows application, either OpenGL or DirectX, can not reach over 2000fps with nothing going on there but printing the fps on the screen, while VAntAGE emulator for DOS can run Galaga at 6000fps!!!!

I can not explain it, I barely believe myself, why and how can Windows application, or any of those APIs, come with such monstrous overhead, but that's how it is. So, I am now wondering should I go 15 years back in time and instead of using modern video hardware capabilities just do MAME re-write for VESA standard and actually make it several orders of magnitude FASTER. Unbelievable!


Anyway, would you be interested in such project, either OpenGL (SDL) or VESA based? My real goal is to make it really compact and simple so to be portable to mobile platforms, but beside speed and size my main concerned is smooth animation and authentic gameplay, so this should be something you would want to put in both, your arcade cabinet (with cheap old computer) and your shiny new mobile phone. How about it?




I'd definitely be interested in porting the changes to resolution switching/calculation into such a project, including it in the Groovy Arcade Linux as an alternative to the current groovymame.  Not tons of time to branch off into more than what I'm currently undertaking, but sounds like if you have your project in a git repository available I'd be poking around at it and trying to create patches to submit to you adding in any extra arcade monitor functionality or other modeline/resolution improvements.  I'd say open it up and see where it goes, I'd definitely feel like things like the smoothmame patch would be nicer to work into something like that.  After looking at the smoothmame patch, it does look like less of something I want to put into my patches to current mame since it makes some core changes to defines that would be hard to keep current to a moving target, so more suited to something like this that was forked permanently.  I like groovymame for keeping current, and so something like this sounds interesting to have for everything else to go that can't be kept current without constantly re-factoring patches each release.  I have all the code mostly in separate files in groovymame, so it's concise and simple in how it's modified mame, but with major changes in resolution configuration/setup too.  That way I hopefully won't have to spend a ton of time in future releases adapting it, and also that separate code could easily be put into a project like yours or other emulators in the future.  I actually would like to sometime make it into more of a library for modeline switching and generation to link into other applications with an API to use it.

torino

  • -Banned-
  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 201
  • Last login:July 24, 2011, 05:18:12 pm
  • -Banned-
Re: CabMame
« Reply #175 on: April 08, 2011, 12:48:16 pm »
This might  be partly a Windows issue too.  In Linux on my LCD I can run a lot of odd resolutions just fine, I am pretty sure the refresh rates are not all 60Hz, but then again it might be a slight bit less accurate still than a CRT, I'm not sure though.  It might be the EDID, and Windows, especially Windows 7, totally giving in to the EDID which these monitors most likely have preset resolutions set at fixed amounts like 60Hz.  So if the OS like Windows has a very strict obeying nature to the EDID, it'll most likely stick to what the monitor tells it to do.  In Linux with an ATI card I can pretty much tell the monitor/video card whatever I want to, and it either displays it if really able to just goes blank.  Not for sure, but it might be some of the issue and why people say that LCD's can only do 60Hz, there might be other factors involved.

How do you know what refresh rate your LCD is running? Does that monitor have on screen display showing that information or you trust some software? 

I believe no one was even talking about it around here, and from what I can find via Google LCDs do have truly fixed rates, so even if they can accept some range they would end up updating their screen at their internal refresh rate, or so it would seem.

Ironically then my own tests show otherwise too, and of course if I was so sure about any of it I would not test it any more, but then, not all tests are to be believed and surely such LCD, with varying refresh rate, would come with some manual and specification sheet that says so, right? But where is it?

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #176 on: April 08, 2011, 12:51:38 pm »
This might  be partly a Windows issue too.  In Linux on my LCD I can run a lot of odd resolutions just fine, I am pretty sure the refresh rates are not all 60Hz, but then again it might be a slight bit less accurate still than a CRT, I'm not sure though.  It might be the EDID, and Windows, especially Windows 7, totally giving in to the EDID which these monitors most likely have preset resolutions set at fixed amounts like 60Hz.  So if the OS like Windows has a very strict obeying nature to the EDID, it'll most likely stick to what the monitor tells it to do.  In Linux with an ATI card I can pretty much tell the monitor/video card whatever I want to, and it either displays it if really able to just goes blank.  Not for sure, but it might be some of the issue and why people say that LCD's can only do 60Hz, there might be other factors involved.

How do you know what refresh rate your LCD is running? Does that monitor have on screen display showing that information or you trust some software? 

I believe no one was even talking about it around here, and from what I can find via Google LCDs do have truly fixed rates, so even if they can accept some range they would end up updating their screen at their internal refresh rate, or so it would seem.

Ironically then my own tests show otherwise too, and of course if I was so sure about any of it I would not test it any more, but then, not all tests are to be believed and surely such LCD, with varying refresh rate, would come with some manual and specification sheet that says so, right? But where is it?

Basically in Linux running with an ATI card using vsync and no throttle, xrandr modelines and looking at the mame speed percent.  I am pretty sure I can get 100% speed running on the card/monitor vsync to the LCD, and not all 60Hz games.

torino

  • -Banned-
  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 201
  • Last login:July 24, 2011, 05:18:12 pm
  • -Banned-
Re: CabMame
« Reply #177 on: April 08, 2011, 01:01:58 pm »
I'd definitely be interested in porting the changes to resolution switching/calculation into such a project, including it in the Groovy Arcade Linux as an alternative to the current groovymame.  Not tons of time to branch off into more than what I'm currently undertaking, but sounds like if you have your project in a git repository available I'd be poking around at it and trying to create patches to submit to you adding in any extra arcade monitor functionality or other modeline/resolution improvements.  I'd say open it up and see where it goes, I'd definitely feel like things like the smoothmame patch would be nicer to work into something like that.  After looking at the smoothmame patch, it does look like less of something I want to put into my patches to current mame since it makes some core changes to defines that would be hard to keep current to a moving target, so more suited to something like this that was forked permanently.  I like groovymame for keeping current, and so something like this sounds interesting to have for everything else to go that can't be kept current without constantly re-factoring patches each release.  I have all the code mostly in separate files in groovymame, so it's concise and simple in how it's modified mame, but with major changes in resolution configuration/setup too.  That way I hopefully won't have to spend a ton of time in future releases adapting it, and also that separate code could easily be put into a project like yours or other emulators in the future.  I actually would like to sometime make it into more of a library for modeline switching and generation to link into other applications with an API to use it.

Great, in worst case we can share some code and in best case scenario we might end up with some cool project, so all the chicks would scream our names in their wild arcade dreams. Anyway, I have to log off now, let me get back to that later.

torino

  • -Banned-
  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 201
  • Last login:July 24, 2011, 05:18:12 pm
  • -Banned-
Re: CabMame
« Reply #178 on: April 08, 2011, 01:11:07 pm »
This might  be partly a Windows issue too.  In Linux on my LCD I can run a lot of odd resolutions just fine, I am pretty sure the refresh rates are not all 60Hz, but then again it might be a slight bit less accurate still than a CRT, I'm not sure though.  It might be the EDID, and Windows, especially Windows 7, totally giving in to the EDID which these monitors most likely have preset resolutions set at fixed amounts like 60Hz.  So if the OS like Windows has a very strict obeying nature to the EDID, it'll most likely stick to what the monitor tells it to do.  In Linux with an ATI card I can pretty much tell the monitor/video card whatever I want to, and it either displays it if really able to just goes blank.  Not for sure, but it might be some of the issue and why people say that LCD's can only do 60Hz, there might be other factors involved.

How do you know what refresh rate your LCD is running? Does that monitor have on screen display showing that information or you trust some software?  

I believe no one was even talking about it around here, and from what I can find via Google LCDs do have truly fixed rates, so even if they can accept some range they would end up updating their screen at their internal refresh rate, or so it would seem.

Ironically then my own tests show otherwise too, and of course if I was so sure about any of it I would not test it any more, but then, not all tests are to be believed and surely such LCD, with varying refresh rate, would come with some manual and specification sheet that says so, right? But where is it?

Basically in Linux running with an ATI card using vsync and no throttle, xrandr modelines and looking at the mame speed percent.  I am pretty sure I can get 100% speed running on the card/monitor vsync to the LCD, and not all 60Hz games.

MAME?! If they knew anything about it there would not be things like SmoothMAME or AdvanceMAME, or CabMAME, or people like you and me trying to fix all that rubbish. MAME does crazy things with timers and is probably the worst software to tell you anything about your monitor.


Find some LCD with OSD that shows refresh rates like PC CRTs used to have, if there is any such LCD?
Find the manual or whatever specification of whatever LCD on the Internet that confirms it black on white?

Until then, I am not trusting even any software that was made to tell those things, let alone MAME's gibberish.

« Last Edit: April 08, 2011, 01:12:58 pm by torino »

krick

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2006
  • Last login:May 23, 2025, 03:48:36 am
  • Gotta have blue hair.
Re: CabMame
« Reply #179 on: April 08, 2011, 11:08:25 pm »
Do you know if your build fixes this issue?  I'm still setting up my Windows 7 + ArcadeVGA system, so I can't test it yet.

This sucks because it limits my front-end to 640x288   :(


http://www.ultimarc.com/avgainst.html
Quote
Important note about Windows 7

There is currently a known issue with Windows 7 switching between resolutions.

If the desktop is running at an interlaced resolution (eg 640 x 480 on a standard-res monitor), When any game which uses a non-interlaced res is started (which is pretty much any Mame game), an error resuts "Unable to initialize directdraw".

Note this only happens if the desktop is running at an interlaced res, which is the case when using a standard res monitor (not a multi-frequency monitor).

There is a workaround for this: Run the desktop at a non-interlaced res such as 640 x 288. This might mean using a front end which has a 640 x 288 mode such as Mamewah.

The resolution can be switched using the Quickres icon.

Note to Mame devs: This issue does not arise if D3D is selected. But owing to not being able to disable stretching in D3D in Mame this results in a poor quality picture.
Hantarex Polo 15KHz
Sapphire Radeon HD 7750 2GB (GCN)
GroovyMAME 0.197.017h_d3d9ex
CRT Emudriver & CRT Tools 2.0 beta 13 (Crimson 16.2.1 for GCN cards)
Windows 7 Home Premium 64-bit
Intel Core i7-4790K @ 4.8GHz
ASUS Z87M-PLUS Motherboard

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #180 on: April 08, 2011, 11:27:46 pm »
Do you know if your build fixes this issue?  I'm still setting up my Windows 7 + ArcadeVGA system, so I can't test it yet.

This sucks because it limits my front-end to 640x288   :(


http://www.ultimarc.com/avgainst.html
Quote
Important note about Windows 7

There is currently a known issue with Windows 7 switching between resolutions.

If the desktop is running at an interlaced resolution (eg 640 x 480 on a standard-res monitor), When any game which uses a non-interlaced res is started (which is pretty much any Mame game), an error resuts "Unable to initialize directdraw".

Note this only happens if the desktop is running at an interlaced res, which is the case when using a standard res monitor (not a multi-frequency monitor).

There is a workaround for this: Run the desktop at a non-interlaced res such as 640 x 288. This might mean using a front end which has a 640 x 288 mode such as Mamewah.

The resolution can be switched using the Quickres icon.

Note to Mame devs: This issue does not arise if D3D is selected. But owing to not being able to disable stretching in D3D in Mame this results in a poor quality picture.

Interesting, I had no clue that this happened with the arcadeVGA card and Windows 7.  The method of using custom modelines for the non-ArcadeVGA ATI drivers we use doesn't work in Windows 7 though.  It may have more todo with Windows 7 and directdraw being depreciated, possibly they are causing interlaced modelines to be not able to switch back and forth.  I remember seeing something, where the whole interlaced flag I think is changing there.  Actually in the powerstrip forums they were talking about how you can't jump from interlaced to progressive modes, I think that's what I'm thinking of.  So it may be an ATI + Windows 7 interaction I guess, not sure if it's fixable without just dropping back to XP64 or XP32.  Not the best answer, but newer versions of Windows aren't exactly trying to be flexible with arcade monitors, quite the opposite actually.  I guess that the ArcadeVGA in Windows 7 does have a few drawbacks, just less than other solutions in Windows 7, yet sounds like quite an irritation to not be able to utilize an interlaced desktop for the frontend.

torino

  • -Banned-
  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 201
  • Last login:July 24, 2011, 05:18:12 pm
  • -Banned-
Re: CabMame
« Reply #181 on: April 09, 2011, 01:33:56 pm »
I'd definitely be interested in porting the changes to resolution switching/calculation into such a project...

Ok, so I organized my files and I can upload everything together with Mingw environment, all set up for easy compile. It compiles in about 15 seconds, it's a tiny build supporting just three games - Galaga, Scramble and Moon Patrol.

I'm not sure if there is anything interesting for you to see at this point, but I think it's common interest to find some basic performance numbers, so if you would be keen to test VAntAGE DOS emulator (it works under Windows just as good, without sound that is) and compare fps with what you get in empty OpenGL or DirectX application on your system, that would great, and I can upload all those files as well and make it easy for you to test. Are you interested?


And also, are we going to settle on LCD refresh rates, truly fixed or not?
« Last Edit: April 09, 2011, 01:35:34 pm by torino »

krick

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2006
  • Last login:May 23, 2025, 03:48:36 am
  • Gotta have blue hair.
Re: CabMame
« Reply #182 on: April 09, 2011, 02:49:30 pm »

And also, are we going to settle on LCD refresh rates, truly fixed or not?


I have an older NEC MultiSync LCD monitor that supposedly supports multiple refresh rates (see attached image).
Hantarex Polo 15KHz
Sapphire Radeon HD 7750 2GB (GCN)
GroovyMAME 0.197.017h_d3d9ex
CRT Emudriver & CRT Tools 2.0 beta 13 (Crimson 16.2.1 for GCN cards)
Windows 7 Home Premium 64-bit
Intel Core i7-4790K @ 4.8GHz
ASUS Z87M-PLUS Motherboard

Gray_Area

  • -Banned-
  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 3363
  • Last login:June 23, 2013, 06:52:30 pm
  • -Banned-
Re: CabMame
« Reply #183 on: April 09, 2011, 06:00:51 pm »

And also, are we going to settle on LCD refresh rates, truly fixed or not?


I have an older NEC MultiSync LCD monitor that supposedly supports multiple refresh rates (see attached image).

I can't imagine using a monitor with less than nineteen inches of viewable area.
-Banned-

krick

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2006
  • Last login:May 23, 2025, 03:48:36 am
  • Gotta have blue hair.
Re: CabMame
« Reply #184 on: April 09, 2011, 07:12:05 pm »

And also, are we going to settle on LCD refresh rates, truly fixed or not?


I have an older NEC MultiSync LCD monitor that supposedly supports multiple refresh rates (see attached image).

I can't imagine using a monitor with less than nineteen inches of viewable area.

I don't plan on using this in a cabinet.  I was just citing it as an example of an LCD that supposedly supports multiple refresh rates.
Hantarex Polo 15KHz
Sapphire Radeon HD 7750 2GB (GCN)
GroovyMAME 0.197.017h_d3d9ex
CRT Emudriver & CRT Tools 2.0 beta 13 (Crimson 16.2.1 for GCN cards)
Windows 7 Home Premium 64-bit
Intel Core i7-4790K @ 4.8GHz
ASUS Z87M-PLUS Motherboard

torino

  • -Banned-
  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 201
  • Last login:July 24, 2011, 05:18:12 pm
  • -Banned-
Re: CabMame
« Reply #185 on: April 09, 2011, 08:48:09 pm »

And also, are we going to settle on LCD refresh rates, truly fixed or not?


I have an older NEC MultiSync LCD monitor that supposedly supports multiple refresh rates (see attached image).

Thank you. That helped a lot, I think I figured it all out now.


"MultiSync LCD", that makes sense as much as "square wheel", but I'm sure it helped increase the sales, it sure sounds good, whatever it is, even if it's nothing, nothing but scam. So, there was a time when decision was made for LCDs are to replace CRTs. And as always in computer industry, when old standards get replaced with new, there was a question of backward compatibility. LCDs simply had to be able to accept the same signal as CRTs they're trying to overthrow, and they managed to achieve this. However, what they did not want you to know is that even though input could stay the same, the output would be something very different. Very, very different, but they called it "better", and we believed. 


Anyhow, what you really want to know is what is the 'response time' of that LCD and that will tell you its ACTUAL refresh rate - the number that defines how many different whole screens it can display over one second interval. For that specific monitor it's ~17ms, which means maximum of 60fps. And that's sufficient, it's adequate and good compared to how it was just several years ago, but still, it's all very misleading, as you can see.


- "NEC ’s Rapid Response technology provides for
uninterrupted display of full-motion video with
response times of 30ms or less.

Rapid Response delivers streaming video without
noticeable ghosting or blur-ring, while achieving
as many as 40 frames per second (fps).

This remarkably quick motion makes these models
better than ever for gaming and video... "


http://www.monitorgalaxy.com/pdf/2351.pdf


Can you believe it? 40fps!? Why did no one ever read those manuals? It was only yesterday when we still had CRTs and we knew the higher the fps the better animation and precision of movement control, yet when LCDs invaded we were happily degraded to believe 40fps is "remarkably quick motion" and BETTER THAN EVER for GAMING!?!

How did that happen? Well, in retrospect, it seems much of it has to do with simply calling things differently, so there was no more 60Hz refresh rate, now we have 17ms response time. I mean, would you really buy any of those LCDs if you knew they can do maximum of 40fps? Of course not, but 30ms response time, well that sounded much better, add there the word "MultiSync" and voila! Who would not want one? Therefore, conclusion is that LCD do have truly fixed refresh rates, and all this confusion, misinformation and lack of information is actually intentional propaganda and false advertisement, as those numbers are (were) such that some might not really wanna know about it at all. 

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #186 on: April 09, 2011, 08:52:09 pm »
I'd definitely be interested in porting the changes to resolution switching/calculation into such a project...

Ok, so I organized my files and I can upload everything together with Mingw environment, all set up for easy compile. It compiles in about 15 seconds, it's a tiny build supporting just three games - Galaga, Scramble and Moon Patrol.

I'm not sure if there is anything interesting for you to see at this point, but I think it's common interest to find some basic performance numbers, so if you would be keen to test VAntAGE DOS emulator (it works under Windows just as good, without sound that is) and compare fps with what you get in empty OpenGL or DirectX application on your system, that would great, and I can upload all those files as well and make it easy for you to test. Are you interested?


And also, are we going to settle on LCD refresh rates, truly fixed or not?


Sounds interesting, I'd definitely when have some extra time take a peek at  it and see how it runs.  

I know that my acer LCD's in the manual state a horizontal range and vertical refresh range they can run in.  I don't know for sure though, I'm guessing any LCD isn't as great at displaying the tear free refresh rate even if it tries to match the rate.   I wonder too about the Wells Gardner and other arcade monitor LCD replacements that are really pricey and are meant to put into place of an original arcade monitor and take direct output from a PCB.  I have no way to test an LCD for true refresh rate, guess just by sight and it's subjective, my d9800 wells gardner arcade monitor has an OSD and I can easily see on it, only if every monitor had such things.

Interesting, yeah I found the wording quite interesting too and now looking at LCD information they all seem sort of sly in how the describe things.  So it's kinda like some technical magic trick to make the display output work with the input refresh rate, but it's not like an old CRT arcade monitor where it's really what the screen is doing in the end.  I figured it was something like this actually, I still wonder though about the high end wells gardner LCD's, but suspect they are doing similar "make it work to a persons eyes" technology but not really running output in the same Hz as you are sending it, but digitally I guess you can do a lot of tricks like that and a majority of people don't even notice.  Just like they have the 16:9 TV's with 4:3 pictures on stretch, and they don't notice that everybody is really fatter than they should be.
« Last Edit: April 09, 2011, 08:59:13 pm by bitbytebit »

torino

  • -Banned-
  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 201
  • Last login:July 24, 2011, 05:18:12 pm
  • -Banned-
Re: CabMame
« Reply #187 on: April 10, 2011, 05:40:43 pm »
Sounds interesting, I'd definitely when have some extra time take a peek at  it and see how it runs.  

* MobileMAME v0.01 + MinGW + TEST(VAntAGE & Empty App) [19mb]

http://www.4shared.com/account/file/W7B1C4X-/MobileMAME_001.html



!RunMe.bat - will produce "tiny.exe", then it will compile "empty.exe" and then it will execute all:



1.) tiny mpatrol

You should see fps counter and garbled OpenGL texture but you will still be able recognize it's Moon Patrol running in it. There is nothing much to see here other than to go through source code and see what is _missing, as what is left is still pretty much MAME 0.88, bit cleared up and simplified at some parts, but overall is quite a mess.
 


And more importantly...

2.) empty.exe

You should see black screen and fps counter, on my laptop, which is 1.7GHz with lousy integrated ATI Xpress GPU, I get 2500fps



3.) vantage galaga -ror

You need to press F11 to see fps counter. I get 6200fps and when I "insert coin" it goes to 7500fps. All tested on WinXP.



Curious, isn't it? What kind of super-duper graphic card we need, how many gigahertz and gigabytes does it take to beat 15 years old VESA and dead old DOS?



Quote
I know that my acer LCD's in the manual state a horizontal range and vertical refresh range they can run in.  I don't know for sure though, I'm guessing any LCD isn't as great at displaying the tear free refresh rate even if it tries to match the rate.   I wonder too about the Wells Gardner and other arcade monitor LCD replacements that are really pricey and are meant to put into place of an original arcade monitor and take direct output from a PCB.  I have no way to test an LCD for true refresh rate, guess just by sight and it's subjective, my d9800 wells gardner arcade monitor has an OSD and I can easily see on it, only if every monitor had such things.

Yeah, and so rather unexpectedly I actually found the software meant for this purpose exactly.

The program is called "JudderTest" and it needs Powerstrip:

http://www.kuratorn.se/011/software/JudderTest11.zip

http://www.entechtaiwan.com/files/pstrip.exe


It can tell you "missed frames". That is, the programs presumes to know, somehow, what is the ACTUAL (internal) rate of the display, but it also has good visual test. I also found some "Judder test" for Linux, but this first one seem good enough so I didn't bother to try or look for more of these tests.


Quote
Interesting, yeah I found the wording quite interesting too and now looking at LCD information they all seem sort of sly in how the describe things.  So it's kinda like some technical magic trick to make the display output work with the input refresh rate, but it's not like an old CRT arcade monitor where it's really what the screen is doing in the end.  I figured it was something like this actually, I still wonder though about the high end wells gardner LCD's, but suspect they are doing similar "make it work to a persons eyes" technology but not really running output in the same Hz as you are sending it, but digitally I guess you can do a lot of tricks like that and a majority of people don't even notice.  Just like they have the 16:9 TV's with 4:3 pictures on stretch, and they don't notice that everybody is really fatter than they should be.

From what I know now, I'd say there is no such thing as Arcade LCD meant to work with multiple arcade PCBs. I'd say LCDs at most support two internal refresh rates, like 50 and 60fps, but it does not seem it is easy or possible for them to vary refresh rate from predefined and built-in one(s).

They use telecine or pulldown, or interpolation/extrapolation aka sampling, or some combination, which is why you see ghosting and/or blurring when you feed frames in different temporal resolution than LCD internal refresh rate.


Those 40fps LCDs from 2003, I'm pretty sure many continued to play their first person shooters at 75Hz or 85Hz like they did with CRTs, giving the GPU quite a workload just so the LCD would degrade it down to 40fps and even make it worse on the way with blurring and ghosting, and so our unfortunate gamers would have been much better off if they were running their game at 40fps to start with, or even better if they never switched to LCD at all.
« Last Edit: April 10, 2011, 05:52:34 pm by torino »

torino

  • -Banned-
  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 201
  • Last login:July 24, 2011, 05:18:12 pm
  • -Banned-
Re: CabMame
« Reply #188 on: April 11, 2011, 11:55:01 am »
Wells-Gardner Electronics Corporation

http://www.wellsgardner.com/products/details.asp?iCat=1&iSubCat=5

- "The 9000 series LCD comes standard with an A/D scaler controller. This controller features an integrated DVI receiver operating up to 135 MHZ, high quality scaling for all VESA modes that fit the screen and direct connect to all DVI compliant transmitters."


There it is, that Analog-Digital controller they are talking about is not only resolution scaler, but it also does frequency re-sampling, which they do not mention, nor imply anyhow. And just like we get bogus image in regards to pixels due to stretching, so do we also get non-authentic visual tempo which comes together with its own visual artifact due to frame rate conversion. Ergo, both spatial and temporal resolution gets skewed and distorted which can hardly help you break any world record, and I don't think Twin Galaxies would/should even accept such record due to terrible non-authenticity that comes with LCD displays, even if it actually makes the games harder.


However, that's only top of an iceberg. Having a temporal scaler means once frames get to A/D controller they need to go into buffer first, then they go through digital manipulation process and only then get sent to display, all of which takes time, so we get the beautiful lag, aka latency. And here comes the best part. You can't use the same mechanism to convert whatever arbitrary mismatch in frame rates, and the difference directly determines the amount of time, or better to say number of frames that need to go into buffer and be worked on as a sequence.

Why? Well, if you need to convert between 50/60fps (PAL/NTSC) you have 10 frames to play with each second, so the latency can be under two seconds, or under one second depending on desired quality, but consider what happens when you need to convert 60.606 -> 60 fps. In such case there is only one extra frame every two seconds, approximately, so what do you do? Do you simply drop that extra frame and get a jerk every now and then, or do you feed two seconds into buffer first and try to smooth 121 frames for each such sequence, and then somehow re-arrange it all over upcoming time?

The closer the input/output frame rates the harder it becomes to actually smooth them, and it takes more time as the relevant sequence gets wider, more sparse, until there is a perfect match, then it becomes perfect, as it should be, and that's what CRTs do.



Anyhow, they say it's always best to ask, so that's what I did.

Quote
frossini@wellsgardner.com

Hello,

I'm looking at this monitor: WGF1979-SDSS39J
7900 Series 19" LCD W/SAMSUNG PANEL (TN)


Can you please tell me what is its internal refresh rate, how many
frames per second?

Can it vary refresh rate like CRTs can, or is it fixed at say 60fps,
or maybe fixed 120fps?

What happens when PCB is feeding different frequency like 60.606fps or
57fps? CRTs can adjust refresh rate to match that of the game, but as
far as I know LCDs must do some kind of conversion and re-sampling to
to match their internal refresh rate, so can you please explain what
kind of conversion/scaling happens when there is such mismatch?


Thank you.


Hopefully we will soon have all the answers, and with some luck maybe it turns out I was completely wrong all along, but as my mum always says - that's not very likely. And, should we move this discussion to some other thread, or new one, I did not mean to interrupt or plan to get so much off the topic, although all this is related at some level, so maybe it does fit here as it is.



bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #189 on: April 11, 2011, 12:09:42 pm »
Wells-Gardner Electronics Corporation

http://www.wellsgardner.com/products/details.asp?iCat=1&iSubCat=5

- "The 9000 series LCD comes standard with an A/D scaler controller. This controller features an integrated DVI receiver operating up to 135 MHZ, high quality scaling for all VESA modes that fit the screen and direct connect to all DVI compliant transmitters."


There it is, that Analog-Digital controller they are talking about is not only resolution scaler, but it also does frequency re-sampling, which they do not mention, nor imply anyhow. And just like we get bogus image in regards to pixels due to stretching, so do we also get non-authentic visual tempo which comes together with its own visual artifact due to frame rate conversion. Ergo, both spatial and temporal resolution gets skewed and distorted which can hardly help you break any world record, and I don't think Twin Galaxies would/should even accept such record due to terrible non-authenticity that comes with LCD displays, even if it actually makes the games harder.


However, that's only top of an iceberg. Having a temporal scaler means once frames get to A/D controller they need to go into buffer first, then they go through digital manipulation process and only then get sent to display, all of which takes time, so we get the beautiful lag, aka latency. And here comes the best part. You can't use the same mechanism to convert whatever arbitrary mismatch in frame rates, and the difference directly determines the amount of time, or better to say number of frames that need to go into buffer and be worked on as a sequence.

Why? Well, if you need to convert between 50/60fps (PAL/NTSC) you have 10 frames to play with each second, so the latency can be under two seconds, or under one second depending on desired quality, but consider what happens when you need to convert 60.606 -> 60 fps. In such case there is only one extra frame every two seconds, approximately, so what do you do? Do you simply drop that extra frame and get a jerk every now and then, or do you feed two seconds into buffer first and try to smooth 121 frames for each such sequence, and then somehow re-arrange it all over upcoming time?

The closer the input/output frame rates the harder it becomes to actually smooth them, and it takes more time as the relevant sequence gets wider, more sparse, until there is a perfect match, then it becomes perfect, as it should be, and that's what CRTs do.



Anyhow, they say it's always best to ask, so that's what I did.

Quote
frossini@wellsgardner.com

Hello,

I'm looking at this monitor: WGF1979-SDSS39J
7900 Series 19" LCD W/SAMSUNG PANEL (TN)


Can you please tell me what is its internal refresh rate, how many
frames per second?

Can it vary refresh rate like CRTs can, or is it fixed at say 60fps,
or maybe fixed 120fps?

What happens when PCB is feeding different frequency like 60.606fps or
57fps? CRTs can adjust refresh rate to match that of the game, but as
far as I know LCDs must do some kind of conversion and re-sampling to
to match their internal refresh rate, so can you please explain what
kind of conversion/scaling happens when there is such mismatch?


Thank you.


Hopefully we will soon have all the answers, and with some luck maybe it turns out I was completely wrong all along, but as my mum always says - that's not very likely. And, should we move this discussion to some other thread, or new one, I did not mean to interrupt or plan to get so much off the topic, although all this is related at some level, so maybe it does fit here as it is.




It's making sense to me, now it all kind of makes sense about what LCD's have done to the idea of different framerates or vertical frequency of analog video input.  I've never liked what LCD's and digital displays have done to video, unless of course it's new HD or digitally created video that was meant to be tightly set to the 50 or 60 fps/Hz.  Now it's really sounding quite sad about what the truth is, how the blurring happens because of it pretty much being a bunch of smoke and mirrors to make it seem like the original refresh rates would even be kept.

Here's the things I read that were interesting, about how they keep on increasing the Hz to somehow mask the issues...
http://www.lcdtvbuyingguide.com/lcdtv/lcdtv-responsetime.shtml
http://www.lcdtvbuyingguide.com/lcdtv/120hz-240hz-60hz.html

Well it seems to fit this cabmame thread somewhat, probably more of the monitor forum topic, but either way it's definitely more in depth details about LCD's than I've seen before in how they actually are working.  I am interested to hear what Wells Gardner reports back about your question to them.

torino

  • -Banned-
  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 201
  • Last login:July 24, 2011, 05:18:12 pm
  • -Banned-
Re: CabMame
« Reply #190 on: April 11, 2011, 05:43:48 pm »
<FRossini@wellsgardner.com> Hi John,
Please see email below and respond back to this customer.

Thank you, Fran

<jpruski@wellsgardner.com> Hello.
I am attaching the spec. sheet with all of the modes that this LCD can handle so all that is means is that if your game falls into any of these frequencies it will either auto search it or you can manually depress the AUTO SEARCH.

John W.G. TECH. SUPPORT
wgf1979 modes.PDF (see below)




So, I'm asking about this LCD they say is meant for classics like Pac-Man, Galaga and Space Invaders and they send me some specification sheet that describes some VGA and VESA modes. It looks like description for analog CRT signal and in no way seem to be related to what I was asking, nor do I see 60.606Hz that MAME claims Galaga is running at. Anyway, this was my reply...

Quote
Hi,

I understand it can "handle" different input, but I want to know what
is the output.

What is the internal refresh rate of that LCD, how many frames per second?

Thank you.

It's getting interesting, I wonder if I'll get any more replies. Perhaps someone who actually bought this thing would have the right to DEMAND this information and/or get them to court for false advertising. Well, I have no further comment, I'm kind of speechless at the moment, I expected far better response, though I can't quite say I'm surprised either. But really, what now, what if they simply refuse to say? Fascinating!

krick

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2006
  • Last login:May 23, 2025, 03:48:36 am
  • Gotta have blue hair.
Re: CabMame
« Reply #191 on: April 11, 2011, 06:10:12 pm »
I agree, this is pretty much off topic at this point.
Maybe one of the board moderators can figure out how to split this thread into two threads.

BUT since I'm here, I'll throw some more wood on the fire.

My guess is that the hardware on the input side of an LCD acts somewhat like a Time Base Corrector...

Quote
Time base correction counteracts errors by buffering the video signal and releasing it at a steady rate. "TBC"s also allow a variable delay in the video stream. By adjusting the rate and delay using a waveform monitor and a vectorscope, the corrected signal can now match the timing of the other devices in the system. If all of the devices in a system are adjusted so their signals meet the video switcher at the same time and at the same rate, the signals can be mixed together. A single master clock or "sync generator" provides the reference for all of the devices' clocks.

I'm willing to bet that input to one of these "arcade replacement" LCD monitors suffers from a small amount of input lag, possibly a frame or two because of the buffering that goes on.

If the people in the thread below are correct, the same sort of input lag can happen when you use triple buffering in PC games...
http://hardforum.com/showthread.php?t=1436949
Hantarex Polo 15KHz
Sapphire Radeon HD 7750 2GB (GCN)
GroovyMAME 0.197.017h_d3d9ex
CRT Emudriver & CRT Tools 2.0 beta 13 (Crimson 16.2.1 for GCN cards)
Windows 7 Home Premium 64-bit
Intel Core i7-4790K @ 4.8GHz
ASUS Z87M-PLUS Motherboard

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #192 on: April 11, 2011, 06:27:06 pm »
I agree, this is pretty much off topic at this point.
Maybe one of the board moderators can figure out how to split this thread into two threads.

BUT since I'm here, I'll throw some more wood on the fire.

My guess is that the hardware on the input side of an LCD acts somewhat like a Time Base Corrector...

Quote
Time base correction counteracts errors by buffering the video signal and releasing it at a steady rate. "TBC"s also allow a variable delay in the video stream. By adjusting the rate and delay using a waveform monitor and a vectorscope, the corrected signal can now match the timing of the other devices in the system. If all of the devices in a system are adjusted so their signals meet the video switcher at the same time and at the same rate, the signals can be mixed together. A single master clock or "sync generator" provides the reference for all of the devices' clocks.

I'm willing to bet that input to one of these "arcade replacement" LCD monitors suffers from a small amount of input lag, possibly a frame or two because of the buffering that goes on.

If the people in the thread below are correct, the same sort of input lag can happen when you use triple buffering in PC games...
http://hardforum.com/showthread.php?t=1436949

Sounds like basically the same process as you use when encoding video, like input is 29.97 fps and you output 15 fps, dropping frames there, things smooth out and timing is redone for the output.  So these LCD's most likely are re-encoding the input to the output digital display and so the whole concept of 'frame rate' as preserved for the output  is no longer relevant at all.  It makes a lot of sense, but they of course never actually explain it in this way, and of course many people don't even understand that about encoders of digital video and how that truly works with input/output frame rates.   Then you have things like WMV which are time based instead of frame based, so MPEG2 to WMV totally loses any concept of actual framerate, WMV just makes things up essentially in a timeline with smoothing and drops frames here and there, unlike MPEG2 which has to strictly keep the same frame rate you ask it to have for the output.  So these LCD's are just encoders, with different input capabilities and the Arcade ones have a larger range of input possible framerates.  Then they all just encode it and plop it out at the 50 or 60fps, or whatever the flat output capability is, but it's nothing like a CRT and the input framerate means nothing really to what your seeing as output.  I'm very familiar with encoding video, feeding raw video frames to an encoder, changing framerates of the output and timestamps on frames.  So it just really sounds like the same thing to me, and I'm surprised I didn't think of what the LCD was doing actually since it now hits very close to what I've done a ton of with video encoding.

torino

  • -Banned-
  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 201
  • Last login:July 24, 2011, 05:18:12 pm
  • -Banned-
Re: CabMame
« Reply #193 on: April 12, 2011, 05:48:15 am »
I agree, this is pretty much off topic at this point.
Maybe one of the board moderators can figure out how to split this thread into two threads.

BUT since I'm here, I'll throw some more wood on the fire.

My guess is that the hardware on the input side of an LCD acts somewhat like a Time Base Corrector...

What we are talking about here is generally known as "telecine". There is no win-win situation with frame rate conversion, except when the difference gives exact double, and it's only thanks to our lazy eyes we are not more aware, or better to say - upset, about any of it.


http://en.wikipedia.org/wiki/Telecine


a.) if too many: drop extra frames, but produce hiccups

b.) if not enough: repeat some frames, but produce judder

c.) or adjust the speed, but produce funny audio pitch

When the difference in frame rate is small the best thing to do is simply speed up or slow down the whole thing. Only that's not something monitors can do, for that you need direct control over timing of the output signal, so that's done in production (together with sound pitch correction), or you can build it in video players, or software such as SmoothMAME.



...independent extra:
d.) interpolate motion, but produce blurring and ghosting



http://en.wikipedia.org/wiki/Motion_interpolation

- "Motion interpolation... aimed at alleviating the video artifacts introduced by framerate conversions in fixed-framerate displays such as LCD TVs... "


Quote
I'm willing to bet that input to one of these "arcade replacement" LCD monitors suffers from a small amount of input lag, possibly a frame or two because of the buffering that goes on.

It does spatial scaling to fill the screen in any case, that means minimum lag in duration of 'one frame', and so your bet wins. But that still leaves us with whatever that LCD does with frame rate scaling, and that we can only know once we know what is actually going on in-there, but we don't know the first thing - its actual output refresh rate, so we really know nothing, yet.


Classic arcade games, that's where every pixel and every frame counts. If you wanna be the King of Kong, then you better stay away from LCDs, that's what I think about it.

torino

  • -Banned-
  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 201
  • Last login:July 24, 2011, 05:18:12 pm
  • -Banned-
Re: CabMame
« Reply #194 on: April 12, 2011, 06:13:04 am »
Sounds like basically the same process as you use when encoding video, like input is 29.97 fps and you output 15 fps, dropping frames there, things smooth out and timing is redone for the output.  So these LCD's most likely are re-encoding the input to the output digital display and so the whole concept of 'frame rate' as preserved for the output  is no longer relevant at all. 

Yes, exactly, but nothing smooths out when you drop frames, unless you drop exactly half of them. What do you mean "no longer relevant"?

Frame rate is all that matters, that's what animation is. We are talking about "moving pictures", and they are moving in time, so beside the time we also must have those pictures, and that means WHOLE pictures, aka frames. If there are fractions, then we have tearing. In any case, the distribution of those frames over time will define our frame rate and this effectively produces what we call "animation".

Frame by frame, there is no other way to depict motion. Except for vector monitors I suppose, or even LCDs could save some energy by only updating those pixels that changed since last frame, and by doing that completely skew the meaning of "frames per second", but when the camera pans and when the screen scrolls then often all the pixels change every frame, so it really all must come down to same old thing - "frame by frame".


Unless you're talking about compression, but that's "internal" to 'format',  and the video stream still has to come out on the display as a sequence of frames, where again the "time spacing" between them defines the quality of the illusion of motion. Interestingly enough, thanks to our lazy eyes, for motion to be perceived as "smooth" the sheer number of frames is less important than its distribution, so constant and evenly spaced 25fps is more fluid to eye than uneven 100fps, which is ugly judder and should be prohibited by international law.


.    .    .    .    .    .    .    .    .    .    .    .

..... ................... .................... .........



Quote
It makes a lot of sense, but they of course never actually explain it in this way, and of course many people don't even understand that about encoders of digital video and how that truly works with input/output frame rates.   Then you have things like WMV which are time based instead of frame based, so MPEG2 to WMV totally loses any concept of actual framerate, WMV just makes things up essentially in a timeline with smoothing and drops frames here and there, unlike MPEG2 which has to strictly keep the same frame rate you ask it to have for the output. 

Perhaps, but I think you are talking about compression. The end result, the actual output, still must manifest via frames changing through the time, frame by frame, and that's foremostly the property of the display itself, so it should be up to software to do the best it can with a given display. It's only that LCDs make such cooperation impossible as they are impostors pretending to be CRTs. And they are also your second video card, the one you don't wanna have as it will override and downgrade what your actual video card was working on so hard.


All this is actually about the 'whole numbers', there simply can't be any fractions, we must have those frames complete. If there are fractions, then we have tearing, like top half of one frame and bottom half of the next frame, but that's not the way to do animation, that's visual artifact, it's ugly and it should be prohibited by international law.


Quote
So these LCD's are just encoders, with different input capabilities and the Arcade ones have a larger range of input possible framerates.  Then they all just encode it and plop it out at the 50 or 60fps, or whatever the flat output capability is, but it's nothing like a CRT and the input framerate means nothing really to what your seeing as output.  I'm very familiar with encoding video, feeding raw video frames to an encoder, changing framerates of the output and timestamps on frames.  So it just really sounds like the same thing to me, and I'm surprised I didn't think of what the LCD was doing actually since it now hits very close to what I've done a ton of with video encoding.

I know exactly what you mean. So, what happed there? We are naive, that's what happened. LCDs did seem adequate replacement for CRTs, they could "handle" all the usual input, we just never got to the point to question its output. Windows would say 60Hz and that was pretty usual, so from that point on we all assumed everything else was "usual" too, or at least adequate replacement, and that was it. For the rest we can blame our lazy eyes and cunning advertisement.
 

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #195 on: April 12, 2011, 06:37:07 am »
Sounds like basically the same process as you use when encoding video, like input is 29.97 fps and you output 15 fps, dropping frames there, things smooth out and timing is redone for the output.  So these LCD's most likely are re-encoding the input to the output digital display and so the whole concept of 'frame rate' as preserved for the output  is no longer relevant at all. 

Yes, exactly, but nothing smooths out when you drop frames, unless you drop exactly half of them. What do you mean "no longer relevant"?

 
Just that it's changing the frame rate with multiple tricks to achieve the output, and so the output frame rate isn't even correlating to what the input frame rate was.  In fact the output with the blurring and other LCD issues is a lot like compressed video and what the non-frame rate temporal types of compression tend to do.   So it can fudge and change around the output framerate to make it work, put an extra frame here and there to make it fit and smooth it out between frames to avoid tearing, instead it's sort of blurry.

I'm certainly glad I got the d9800 now, after all you've talked about here, only downside is moving the thing around of course. 

So how does the smooth mame patch then have the ability to change the original framerate?  I've always thought about it like sampling analog, or the actual video camera, and at the mame emulation end feeding the frames, the source basically, can alter this in multiple ways just like feeding an encoder or monitor/LCD.  I'm not sure how correct I am in assuming that, I do know in cases like the redraw patch of cabmame it is exactly like that in doubling the framerate through repeating each frame twice.  I've just never fully known if it really is at the ROM/machine level that we could have the ability to alter this much at all or that any changes like in smooth mame are going to be doing some loss/add to what the ROM/machine is giving out.  I guess in smoothmame it's changing the machine, at least I am guessing, to run at a different pace, and is it really true that the ROM can just alter if the machine is altered like that, in what the output framerate is?  I guess since smoothmame works well on an LCD, it must be doing something right, just wondering what the technical reasons are for that, how it really is allowed to alter the fps or Hz, and yet the LCD can't do it right at that later stage in the pipeline.

krick

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 2006
  • Last login:May 23, 2025, 03:48:36 am
  • Gotta have blue hair.
Re: CabMame
« Reply #196 on: April 12, 2011, 12:49:53 pm »
My understanding is that SmoothMAME slows down (or speeds up) emulation to make the output exactly 60Hz.

This is not without consequences.  It will change the pitch of sound output as well.  But usually the amount adjusted is small enough that it's not noticeable.

Some smoothmame links...
http://www.zophar.net/mame/smoothmame.html
http://forum.arcadecontrols.com/index.php?topic=9195.0
http://forum.arcadecontrols.com/index.php?topic=18260.0
http://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=58007
Hantarex Polo 15KHz
Sapphire Radeon HD 7750 2GB (GCN)
GroovyMAME 0.197.017h_d3d9ex
CRT Emudriver & CRT Tools 2.0 beta 13 (Crimson 16.2.1 for GCN cards)
Windows 7 Home Premium 64-bit
Intel Core i7-4790K @ 4.8GHz
ASUS Z87M-PLUS Motherboard

torino

  • -Banned-
  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 201
  • Last login:July 24, 2011, 05:18:12 pm
  • -Banned-
Re: CabMame
« Reply #197 on: April 12, 2011, 08:08:20 pm »
Just that it's changing the frame rate with multiple tricks to achieve the output, and so the output frame rate isn't even correlating to what the input frame rate was.  In fact the output with the blurring and other LCD issues is a lot like compressed video and what the non-frame rate temporal types of compression tend to do.   So it can fudge and change around the output framerate to make it work, put an extra frame here and there to make it fit and smooth it out between frames to avoid tearing, instead it's sort of blurry.

Not really. There is no "between frames". If your LCD is fixed at 60fps then that's how many unique frames it can show in one second. Those are your allotted time slots, and while you can fiddle with what you're going to put in each one, you can't put anything between or around them. In other words, the time dimension or time granularity is locked, you only have 2 space dimensions left to work with.

So, if you want to apply this extra step, you first need to realize it will only affect the space, not time dimension. "Motion interpolation" effect comes 'on top' of whatever you have done with frame rate conversion first, and to implement it you will need to double display refresh rate (or triple, or quadruple), i.e. increase the number of alloted time slots so you can put those extra frames in.


There are two problems with it:

1.) This is intended for TVs where standard frame rate conversion produces hiccups and judder which is closely spaced in time, but the choppiness produced with small mismatch in frame rates, like Galaga +0.606 or Moon Patrol -3 frames per second, produce choppiness that is just too sparse, it falls out of the limit where it can be smoothed, not even if you insert 100x more frames in between.

Once you drop a frame you practically change the speed of all the objects in the scene for that instant in time. Interpolation can't quite "fix" that, it can only make the animation of it all more "pleasing" to the eye, but even if it's all "blurry" you will still notice all the objects increased their speed and then suddenly slowed down back to normal for no apparent reason, your brain will know that's not what actually happened, but it's only ugly visual artifact known as "telecine judder".


2.) It takes time to do this interpolation, it produces latency aka lag. By the way that example from above looks too good, I don't see how can image algorithm possibly make it look so perfect. In reality it's more like this:




In any case that explains "ghosting" a bit more clearly. So, we did our frame rate conversion and we now have exactly 60 frames to match with our fixed 60fps LCD, all together with hiccups and judder. Now we press the "smooth" button and this doubles our display refresh rate to 120fps. In ever 'even' numbered time slot we place original frame and in every 'odd' time slot we place our intermediate frame. But, to produce this extra frame we need to have the next frame as well, since we need to combine these two to make our "transition frame". This means the display must be in the past, lagging behind the real time for at least one frame, which is still at least ~17ms even though we now operate at internal 120Hz.


If you really wanted to "smooth" sparse judder where there is a small mismatch in refresh rate, you will need to combine not two frames, but as many frames as there is in between each hiccup. Galaga's 60.606fps would produce hiccup only once every two seconds, so you will really need to buffer and interpolate 121 frames, which means 2 second latency, and that's just out of the question. In more practical view, the problem here is that this does not seem to scale so that we are be able to compensate latency for quality, so I think choosing the tearing over judder and "smoothing" that artifact instead might be easier and more effective than smoothing judder, but I don't think anyone is actually doing this in practice.


Quote
I'm certainly glad I got the d9800 now, after all you've talked about here, only downside is moving the thing around of course. 

Hmm. You don't even know its output refresh rate or latency, those are the numbers that will define its downsides. You should at least have a game of Moon Patrol and Galaga, or Scramble, and give it a very close inspection, can you do that please?

It would be even be better if you had any actual game PCB instead of MAME, but in any case I am willing to trust in your power of observation more than in any of those formal specifications. My crystal ball says you will actually see tearing, not choppiness, that's what I would do if I designed it, as I'd say it's lesser of two evils in this particular case.


Quote
So how does the smooth mame patch then have the ability to change the original framerate?  I've always thought about it like sampling analog, or the actual video camera, and at the mame emulation end feeding the frames, the source basically, can alter this in multiple ways just like feeding an encoder or monitor/LCD.  I'm not sure how correct I am in assuming that, I do know in cases like the redraw patch of cabmame it is exactly like that in doubling the framerate through repeating each frame twice.  I've just never fully known if it really is at the ROM/machine level that we could have the ability to alter this much at all or that any changes like in smooth mame are going to be doing some loss/add to what the ROM/machine is giving out.  I guess in smoothmame it's changing the machine, at least I am guessing, to run at a different pace, and is it really true that the ROM can just alter if the machine is altered like that, in what the output framerate is?  I guess since smoothmame works well on an LCD, it must be doing something right, just wondering what the technical reasons are for that, how it really is allowed to alter the fps or Hz, and yet the LCD can't do it right at that later stage in the pipeline.


As kirck said. Imagine there is no emulation and you already have all the frames ready, say recorded and saved as a collection of images: frame_001.bmp, frame_002.bmp, frame_003.bmp... and so on. Imagine you recorded Moon Patrol at 57fps, and now if you play-back those images at 60fps it will perfectly sync with the 60fps display refresh rate, but everything will be slightly faster. Speeding up or slowing down is regularly done as a part of "telecine" process, not only on its own but also in combination with "pulldown" techniques aka skipping/repeating frames. Changing speed, that is the only one of these telecine methods that leaves the frames as they were, the only good looking one.



newmanfamilyvlogs

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1694
  • Last login:June 15, 2022, 05:20:38 pm
    • forum.arcadecontrols.com/index.php/topic,103584.msg1096585.html#msg1096585
    • Newman Family Vlogs
Re: CabMame
« Reply #198 on: April 12, 2011, 08:58:52 pm »
The whole attempt at trying to get LCDs to run at any arbitrary refresh rate seems like it will never work consistently enough to be any sort of releasable system. I would imagine that there is a vast amount of variability between different LCD driver in as far as what frame rates they actually display. I would also imagine that the rate at which it attempts to display frames, and the rate at which the actual liquid crystals can change is variable, as was suggested previously. Since monitor speeds are generally stated as 'gray to gray' i would also be lead to believe that there is variability in the speed at which different colours change to one another, again independent of what rate they are being instructed to change.

The 'ghosting' effect that's traditionally described in LCDs is more a result of of this rate of change of the individual cells, rather than any sort of intentional interframe-interpolation.

I doubt there is any technical reason why an LCD could not be updated at a fully arbitrary frame rate. In face I imagine there are probably ones on the market right now that would happily be fed a random refresh speed and display it just fine. However, I would assume that most are going to simply ASSUME they will be run at ~60hz and happily drop frames that don't line up since 99.9% of the consumers will not only not care, but not even notice.

In traditional CRTs the actual speed of the electron gun was being driven by the sync signal, which is why arbitrary rates were a non-issue.

bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #199 on: April 12, 2011, 11:23:44 pm »

Quote
I'm certainly glad I got the d9800 now, after all you've talked about here, only downside is moving the thing around of course. 

Hmm. You don't even know its output refresh rate or latency, those are the numbers that will define its downsides. You should at least have a game of Moon Patrol and Galaga, or Scramble, and give it a very close inspection, can you do that please?

It would be even be better if you had any actual game PCB instead of MAME, but in any case I am willing to trust in your power of observation more than in any of those formal specifications. My crystal ball says you will actually see tearing, not choppiness, that's what I would do if I designed it, as I'd say it's lesser of two evils in this particular case.



Actually the d9800 has an OSD and it does show my in 2 decimal places the hfreq and vertical refresh, and they are spot on.  There's never any tearing at all on my d9800, it's a real arcade CRT and ranges from 15.1khz -> 38khz horizontal and 40Hz -> 100Hz vertical.  It's able to play galaxian, galaga, super mario, moon patrol, and every game pretty much at the exact vertical refresh without any tearing at all.  I worked actually for quite a while to get this to work in Linux, with xrandr and vsync using the ATI cards.  I saw tearing, was very familiar with it, and finally after a lot of work totally eradicated every bit of it I saw.  I just do small tests for the groovymame changes on my LCD, which are cheap Acers, and also a samsung HDTV too, and they definitely are terrible and show tearing compared to my d9800.  Even when they are supposed to be running at the correct refresh rate.  They do say they are running at that rate though, they just don't seem to be able to hold it steady, it varies and I don't even trust they are as accurate as they are claiming with the numbers from the ATI PLL clocks and xrandr reporting compared to what the LCD is actually performing.  So the d9800 has no question at all about it, that's as perfect as you can possibly get, even more accurate with overall games refresh rates compared to a standard straight 15khz generic arcade monitor (since it has the large range there of khz and Hz, yet a real CRT, and on screen OSD display verifying it besides the visual proof).

torino

  • -Banned-
  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 201
  • Last login:July 24, 2011, 05:18:12 pm
  • -Banned-
Re: CabMame
« Reply #200 on: April 13, 2011, 01:51:49 am »

Quote
I'm certainly glad I got the d9800 now, after all you've talked about here, only downside is moving the thing around of course. 

Hmm. You don't even know its output refresh rate or latency, those are the numbers that will define its downsides. You should at least have a game of Moon Patrol and Galaga, or Scramble, and give it a very close inspection, can you do that please?

It would be even be better if you had any actual game PCB instead of MAME, but in any case I am willing to trust in your power of observation more than in any of those formal specifications. My crystal ball says you will actually see tearing, not choppiness, that's what I would do if I designed it, as I'd say it's lesser of two evils in this particular case.



Actually the d9800 has an OSD and it does show my in 2 decimal places the hfreq and vertical refresh, and they are spot on.  There's never any tearing at all on my d9800, it's a real arcade CRT and ranges from 15.1khz -> 38khz horizontal and 40Hz -> 100Hz vertical.  It's able to play galaxian, galaga, super mario, moon patrol, and every game pretty much at the exact vertical refresh without any tearing at all.  I worked actually for quite a while to get this to work in Linux, with xrandr and vsync using the ATI cards.  I saw tearing, was very familiar with it, and finally after a lot of work totally eradicated every bit of it I saw.  I just do small tests for the groovymame changes on my LCD, which are cheap Acers, and also a samsung HDTV too, and they definitely are terrible and show tearing compared to my d9800.  Even when they are supposed to be running at the correct refresh rate.  They do say they are running at that rate though, they just don't seem to be able to hold it steady, it varies and I don't even trust they are as accurate as they are claiming with the numbers from the ATI PLL clocks and xrandr reporting compared to what the LCD is actually performing.  So the d9800 has no question at all about it, that's as perfect as you can possibly get, even more accurate with overall games refresh rates compared to a standard straight 15khz generic arcade monitor (since it has the large range there of khz and Hz, yet a real CRT, and on screen OSD display verifying it besides the visual proof).

Sorry, I thought it was one of those LCDs.

Do you have any PCB so we can compare what your OSD says with what MAME/MAWS says?

torino

  • -Banned-
  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 201
  • Last login:July 24, 2011, 05:18:12 pm
  • -Banned-
Re: CabMame
« Reply #201 on: April 13, 2011, 01:58:27 am »
The whole attempt at trying to get LCDs to run at any arbitrary refresh rate seems like it will never work consistently enough to be any sort of releasable system.

Normally, it should be video source that defines consistency, display should only fulfill minimum requirements to follow along with the given rhythm. But in any case, it's only with arcade games where this is a problem, otherwise refresh rates are pretty standard.

All the media is already converted in production to correct refresh rates for your region. As far as TVs are concerned this is all just about motion interpolation to compensate for large screens. Extras, such as 'frame rate scaler', that's just for NTSC/PAL conversion, and that's as far as REAL-TIME framerate conversion goes. 


But wait a second, if the MAXIMUM refresh rate of some LCD is 60fps, why would it not be able to do 57fps or 53fps?


Quote
I would imagine that there is a vast amount of variability between different LCD driver in as far as what frame rates they actually display.

Are you saying LCDs can't be driven by the rhythm of the video source, they have their own internal clock, and even if they made them tick at exactly 60Hz some LCDs still end up at 59.93Hz, some at 60.42Hz and so on?


Quote
I would also imagine that the rate at which it attempts to display frames, and the rate at which the actual liquid crystals can change is variable, as was suggested previously. Since monitor speeds are generally stated as 'gray to gray' i would also be lead to believe that there is variability in the speed at which different colours change to one another, again independent of what rate they are being instructed to change.

Variability in crystal response should not matter as long as they can satisfy some minimum to maintain internal refresh rate in worst case scenario. Maybe there will be impact and colors will go funny if you really go tough on them, but the framerate itself should not suffer because of it, more likely is that crystals would go bad if they can't cope with given refresh rate.


Quote
I doubt there is any technical reason why an LCD could not be updated at a fully arbitrary frame rate. In face I imagine there are probably ones on the market right now that would happily be fed a random refresh speed and display it just fine.

I think there is a reason, even if only economical, but I thought you suggested they have their own internal clock and work in some kind of non-cooperative and asynchronous mode completely independently from the rhythm given by the video source?


Quote
However, I would assume that most are going to simply ASSUME they will be run at ~60hz and happily drop frames that don't line up since 99.9% of the consumers will not only not care, but not even notice.

That sounds like truth.


Quote
In traditional CRTs the actual speed of the electron gun was being driven by the sync signal, which is why arbitrary rates were a non-issue.

Yes, so what drives the refresh rate of an LCD, the rhythm of the video source or the rhythm of an internal clock? But even if it's internal clock, why it would need to be fixed? I don't know, but it surely looks like LCDs come with completely fixed output refresh rates.

newmanfamilyvlogs

  • Trade Count: (+1)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1694
  • Last login:June 15, 2022, 05:20:38 pm
    • forum.arcadecontrols.com/index.php/topic,103584.msg1096585.html#msg1096585
    • Newman Family Vlogs
Re: CabMame
« Reply #202 on: April 13, 2011, 05:51:07 am »
There's a fair bit of information in this article which might be worth reading:
http://www.xbitlabs.com/articles/monitors/print/lcd-parameters.html


bitbytebit

  • Guest
  • Trade Count: (0)
Re: CabMame
« Reply #203 on: April 13, 2011, 08:08:09 am »

Quote
I'm certainly glad I got the d9800 now, after all you've talked about here, only downside is moving the thing around of course. 

Hmm. You don't even know its output refresh rate or latency, those are the numbers that will define its downsides. You should at least have a game of Moon Patrol and Galaga, or Scramble, and give it a very close inspection, can you do that please?

It would be even be better if you had any actual game PCB instead of MAME, but in any case I am willing to trust in your power of observation more than in any of those formal specifications. My crystal ball says you will actually see tearing, not choppiness, that's what I would do if I designed it, as I'd say it's lesser of two evils in this particular case.



Actually the d9800 has an OSD and it does show my in 2 decimal places the hfreq and vertical refresh, and they are spot on.  There's never any tearing at all on my d9800, it's a real arcade CRT and ranges from 15.1khz -> 38khz horizontal and 40Hz -> 100Hz vertical.  It's able to play galaxian, galaga, super mario, moon patrol, and every game pretty much at the exact vertical refresh without any tearing at all.  I worked actually for quite a while to get this to work in Linux, with xrandr and vsync using the ATI cards.  I saw tearing, was very familiar with it, and finally after a lot of work totally eradicated every bit of it I saw.  I just do small tests for the groovymame changes on my LCD, which are cheap Acers, and also a samsung HDTV too, and they definitely are terrible and show tearing compared to my d9800.  Even when they are supposed to be running at the correct refresh rate.  They do say they are running at that rate though, they just don't seem to be able to hold it steady, it varies and I don't even trust they are as accurate as they are claiming with the numbers from the ATI PLL clocks and xrandr reporting compared to what the LCD is actually performing.  So the d9800 has no question at all about it, that's as perfect as you can possibly get, even more accurate with overall games refresh rates compared to a standard straight 15khz generic arcade monitor (since it has the large range there of khz and Hz, yet a real CRT, and on screen OSD display verifying it besides the visual proof).

Sorry, I thought it was one of those LCDs.

Do you have any PCB so we can compare what your OSD says with what MAME/MAWS says?



Eventually I want to do that, get one of those 90 in 1 PCB's to play around with and compare to Mame, I have a WG7200 19" arcade monitor too and would be really interesting to go back and forth between all combinations of Mame/PCB/d9800/WG7200.  Probably not as soon as later, in the middle of getting ready to move right now, so both funding and have to wait till in the new place to even think of getting the WG7200 setup in some kind of table top testing rig.  It's at least in the future plans to do such things.