GroovyMAME selecting modelines that my system doesn't like?

Software Support > GroovyMAME

(1/3) > >>

gabe:
I originally posted about this issue in the GroovyArcade Linux thread but decided to bring the discussion over here, as I believe it is a better fit.

Using GroovyMAME in Linux, I have found several games which crash MAME right around the time a modeline is selected. With logging, I get something similar to this (from baddudes):

--- Code: ---Parsing mame.ini
SwitchRes: Found output connector 'VGA-0'
SwitchRes: Monitor: cga Orientation: horizontal Aspect 4:3
SwitchRes v0.013: [baddudes.zip] (1) horizontal (256x240@57.39)->(256x240@57.39)->(256x240@57.39)
SwitchRes: # baddudes.zip 256x240@57.39 15.2663Khz
SwitchRes: ModeLine "256x240x57.39" 5.251606 256 272 296 344 240 244 247 266 -HSync -VSync
SwitchRes: Setting Option -redraw 0
SwitchRes: Setting Option -rotate
SwitchRes: Setting Option -nothrottle
SwitchRes: Setting Option -refreshspeed
SwitchRes: Setting Option -waitvsync
SwitchRes: Xrandr ADD VGA-0: ModeLine "256x240x57.39" 5.251606 256 272 296 344 240 244 247 266 -HSync -VSync
SwitchRes: Running 'xrandr --newmode "256x240x57.39" 5.251606 256 272 296 344 240 244 247 266 -HSync -VSync'
SwitchRes: Running 'xrandr --addmode VGA-0 256x240x57.39'
SwitchRes: Setting Option -resolution 256x240x32@57.392092
Build version: 0.143 (Jun 29 2011)
Build architecure: SDLMAME_ARCH=
Build defines 1: SDLMAME_UNIX=1 SDLMAME_X11=1 SDLMAME_LINUX=1
Build defines 1: LSB_FIRST=1 PTR64=1 DISTRO=generic SYNC_IMPLEMENTATION=tc
SDL/OpenGL defines: SDL_COMPILEDVERSION=1214 USE_OPENGL=1 USE_DISPATCH_GL=1
Compiler defines A: __GNUC__=4 __GNUC_MINOR__=6 __GNUC_PATCHLEVEL__=0 __VERSION__="4.6.0 20110603 (prerelease)"
Compiler defines B: __amd64__=1 __x86_64__=1 __unix__=1
Compiler defines C: __USE_FORTIFY_LEVEL=0
SDL Device Driver : x11
SDL Monitor Dimensions: 640 x 480
Enter sdlwindow_init
Using SDL single-window OpenGL driver (SDL 1.2)
Leave sdlwindow_init
640x 480 -> 0.001600
304x 224 -> 0.000015
288x 224 -> 0.000020
256x 240 -> 2.000000
Loaded opengl shared library: <default>
--- End code ---

I have found that I can avoid the above crash by creating a game specific ini such as:

--- Code: ---cleanstretch 1
switchres 0
--- End code ---

or by specifying a different resolution such as:

--- Code: ---resolution 512x480@57.41
--- End code ---

I should note that when I manually force a resolution, X windows then stays in that resolution after exiting MAME.

Does anyone have any thoughts/ideas/solutions?

If it helps, I'm using a Wells-Gardner 25K7191 with the following monitor_specs0 in mame.ini:

--- Code: ---monitor_specs0 15100.00-16800.00,47.00-63.00,2.187,4.688,6.719,0.190,0.191,1.018,0,0,288,448
--- End code ---

bitbytebit:

--- Quote from: gabe on July 05, 2011, 10:36:24 am ---I originally posted about this issue in the GroovyArcade Linux thread but decided to bring the discussion over here, as I believe it is a better fit.

Using GroovyMAME in Linux, I have found several games which crash MAME right around the time a modeline is selected. With logging, I get something similar to this (from baddudes):

--- Code: ---Parsing mame.ini
SwitchRes: Found output connector 'VGA-0'
SwitchRes: Monitor: cga Orientation: horizontal Aspect 4:3
SwitchRes v0.013: [baddudes.zip] (1) horizontal (256x240@57.39)->(256x240@57.39)->(256x240@57.39)
SwitchRes: # baddudes.zip 256x240@57.39 15.2663Khz
SwitchRes: ModeLine "256x240x57.39" 5.251606 256 272 296 344 240 244 247 266 -HSync -VSync
SwitchRes: Setting Option -redraw 0
SwitchRes: Setting Option -rotate
SwitchRes: Setting Option -nothrottle
SwitchRes: Setting Option -refreshspeed
SwitchRes: Setting Option -waitvsync
SwitchRes: Xrandr ADD VGA-0: ModeLine "256x240x57.39" 5.251606 256 272 296 344 240 244 247 266 -HSync -VSync
SwitchRes: Running 'xrandr --newmode "256x240x57.39" 5.251606 256 272 296 344 240 244 247 266 -HSync -VSync'
SwitchRes: Running 'xrandr --addmode VGA-0 256x240x57.39'
SwitchRes: Setting Option -resolution 256x240x32@57.392092
Build version: 0.143 (Jun 29 2011)
Build architecure: SDLMAME_ARCH=
Build defines 1: SDLMAME_UNIX=1 SDLMAME_X11=1 SDLMAME_LINUX=1
Build defines 1: LSB_FIRST=1 PTR64=1 DISTRO=generic SYNC_IMPLEMENTATION=tc
SDL/OpenGL defines: SDL_COMPILEDVERSION=1214 USE_OPENGL=1 USE_DISPATCH_GL=1
Compiler defines A: __GNUC__=4 __GNUC_MINOR__=6 __GNUC_PATCHLEVEL__=0 __VERSION__="4.6.0 20110603 (prerelease)"
Compiler defines B: __amd64__=1 __x86_64__=1 __unix__=1
Compiler defines C: __USE_FORTIFY_LEVEL=0
SDL Device Driver : x11
SDL Monitor Dimensions: 640 x 480
Enter sdlwindow_init
Using SDL single-window OpenGL driver (SDL 1.2)
Leave sdlwindow_init
640x 480 -> 0.001600
304x 224 -> 0.000015
288x 224 -> 0.000020
256x 240 -> 2.000000
Loaded opengl shared library: <default>
--- End code ---

I have found that I can avoid the above crash by creating a game specific ini such as:

--- Code: ---cleanstretch 1
switchres 0
--- End code ---

or by specifying a different resolution such as:

--- Code: ---resolution 512x480@57.41
--- End code ---

I should note that when I manually force a resolution, X windows then stays in that resolution after exiting MAME.

Does anyone have any thoughts/ideas/solutions?

If it helps, I'm using a Wells-Gardner 25K7191 with the following monitor_specs0 in mame.ini:

--- Code: ---monitor_specs0 15100.00-16800.00,47.00-63.00,2.187,4.688,6.719,0.190,0.191,1.018,0,0,288,448
--- End code ---

--- End quote ---

Does it do it on the ISO image too? Hadn't seen if you had tested just the liveCD to double check that there isn't some other factor happening besides the actual groovymame having a bug. If not already tested, try the ISO and see if the behavior can be repeated there too. That would help track down where things are going wrong quicker, since it might be the X Windows/compiler builds/versions or something else like that.

gabe:

--- Quote from: bitbytebit on July 05, 2011, 12:51:01 pm ---Does it do it on the ISO image too? Hadn't seen if you had tested just the liveCD to double check that there isn't some other factor happening besides the actual groovymame having a bug. If not already tested, try the ISO and see if the behavior can be repeated there too. That would help track down where things are going wrong quicker, since it might be the X Windows/compiler builds/versions or something else like that.
--- End quote ---

It works properly on the ISO. I set my monitor type to h9110 and baddudes runs perfectly at 256x240@57.41.

Just for kicks, I tried setting my monitor type to h9110 on my Arch install, but no dice.

I'm more than happy to experiment, take shots in the dark, etc... But I don't even really know where to begin with this particular issue. ???

bitbytebit:

--- Quote from: gabe on July 05, 2011, 07:00:08 pm ---
--- Quote from: bitbytebit on July 05, 2011, 12:51:01 pm ---Does it do it on the ISO image too? Hadn't seen if you had tested just the liveCD to double check that there isn't some other factor happening besides the actual groovymame having a bug. If not already tested, try the ISO and see if the behavior can be repeated there too. That would help track down where things are going wrong quicker, since it might be the X Windows/compiler builds/versions or something else like that.
--- End quote ---

It works properly on the ISO. I set my monitor type to h9110 and baddudes runs perfectly at 256x240@57.41.

Just for kicks, I tried setting my monitor type to h9110 on my Arch install, but no dice.

I'm more than happy to experiment, take shots in the dark, etc... But I don't even really know where to begin with this particular issue. ???

--- End quote ---
I'm guessing it's somewhere with how the OpenGL, DRM, X Windows, ATI Driver for X, are compiled that would be causing the crash. I'm not sure what versions and how Arch sets these up, but possibly that is causing the problem. Seems like it's crashing out with OpenGL, so possibly the OpenGL version is too new and there are quite a few issues with the newest OpenGL and Mame, possibly that or there's yet another issue now with certain resolutions.

Calamity:
I'd check if its only a problem with that exact modeline or rather it's a low dotclock issue. If you see the modeline generated for the cga monitor, it has a dotclock of 5.251606 MHz. I'd test games that have use a dotclock that's a little lower or higher, to see if they're affected too, i.e. argus (-monitor_orientation vertical) and toki.

Navigation

[0] Message Index

[#] Next page

Go to full version