GroovyMAME 0.171 - SwitchRes v0.015m

[Calamity]

Cool. Definitely some weird behaviour. Don't really want to pepper you with logs, but another one I just spotted. If I change the ini I posted to "orientation horizontal" then galaga88 and invaders appear rotated vertically on the screen but fractionally stretched (filtered).

Not sure what would be the expected behaviour here. Don't be afraid to post logs

ket is integer stretched. If I subsequently pass "-norotate" to galaga88, it appears in its natural orientation but it's running at 200%.

If you touch any of the rotation options then things are guaranteed to get weird. Everything is calculated assuming GM takes care of those.

[cools]

Gotcha. I'm not sure what's going on with the first two (I swear it didn't work like this earlier) and not hugely bothered as anyone running vertical games rotated on a horizontal monitor is a deviant anyway

[Sledge]

Have you tried the blitter delay thing?
http://www.mameworld.info/ubbthreads/showflat.php?Cat=&Board=mamechat&Number=324467&Forum=All_Forums&Words=Tafoid&Match=Username&Searchpage=0&Limit=25&Old=allposts&Main=324445&Search=true#Post324467

Yep.. made it perform worse.

[jimmer]

Thanks for this program Calamity. As a newcomer it's all a bit confusing reading the back and forth between people who know what all the functions do. Is there a guide anywhere?

Anyway I downloaded the binary a few pages back and on my windows7 system with 17" LCD in portrait, it rendered Galaxian just how I wanted it first time. I've been bothered by how to fix Galaxian for a few days now.

Now I'll have get the source and compile win32 version for my arcade machines. They are Dell optiplex 745 with onboard graphics only. Am I going to need an ATI video card? I'll be running a 1280x1024 LCD vertically, and also either a 1600x1200 horizontal or 1920x1080 horizontal.

[machyavel]

Hi, ATI cards are useful in case you want to output low resolutions with the help of Calamity's CRT_Emudriver.

[jimmer]

Well I got 0153  compiled how I want. And hi-score works, it took a while but I had a vague memory of a post somewhere saying hiscore.dat had to be in the \hi folder.

So, next step, how do I set the games up individually? If anyone wants to help me out with an example: I would like to use integer scaling to display Galaxian on my horizontal 1600x1200 LCD.

[Calamity]

Hi jimmer,

So, next step, how do I set the games up individually? If anyone wants to help me out with an example: I would like to use integer scaling to display Galaxian on my horizontal 1600x1200 LCD.

You only need to enable -monitor lcd, and set the proper aspect in the -aspect option (-aspect 4:3 in your case).

You don't need to do anything special to have integer scaling. Basically it's the default setting. GM will calculate the nearest integer scale factor for your screen resolution. Ony if the resulting borders are too big (around 15%) fractional scaling will be used instead. You can force integer scaling even in this situation by setting -cleanstretch 1 in the specific game ini, but only for horizontal games.

[jimmer]

Ah, what I really meant to write was that I want to choose the scaling, I don't want Galaxian to fill my 4:3 horizontal screen like it does at the moment, I want a vertical strip.

Also I don't know how to do an individual ini, so I'm after an example galaxian ini that scales the game by eg 3,5 or 4,5

After fixing Galaxian, the most important goal is to sort out my Defender set-up. I usually play without v-sync and put up with the tearing. When I use vsync, I get the occasional crash but also I sometimes I think I feel a bit of lag but I'm not sure. I'm looking forward to trying out framedelay with vsync to see if that feels and looks right.

[Calamity]

Hi jimmer,

I'd say you're missing something basic. If vertical games are filling the screen it probably means you didn't create mame.ini using the GM executable.

GM doesn't support user scale factors. You can trick GM to set different aspect ratios for vertical games by playing with the -aspect option (actually by lying about your actual monitor's aspect).

Using -frame_delay with LCD monitor causes static tearing, looks better than random tearing but still not perfect.

[Tithis]

I've been bashing my head a bit here 

How do I override groovymames selected resolutions with my own? I tried the modeline in the games ini file like shown on the first page here and it seemingly is being ignored, no messages in the cmd. If I try passing the modeline directly with -modeline it complains about a missing parameter. Mame.ini has the correct ini folder specified.

I know the formatting of the modeline is correct, I copied it from here and filled it in with modeline info from OSD.

[Calamity]

Hi Tithis,

If the format of the modeline is correct (post your .ini file here so I can check) then it's possible that you're requesting a resolution that is not available in your system. In other words, you can only modify the timings/geometry of an already existing mode. As usual, a log is worth a thousand words.

[Tithis]

Alright I'll try to get you that sometime tonight when I go over to work on the cab.

[NightSprinter]

Calamity, though I'm going to be moving soon, once I've settled into he new place I'm going to test out how emulation works if I set it up exclusively for 31-52KHz horizontal (especially since certain 31KHz modes can in fact go up to 120Hz vertical refresh on my NEC).  I have a lot of the basic settings down for groovymame and switchres, but could need help tweaking it to ensure it's right.  I'll let you know when the gear is set up again.

[cools]

That'll be a nice setup for vertical games

[NightSprinter]

Yeah, just don't expect me to rotate the NEC ever.  Got enough spinal issues as it is. XD

But seriously, though, this could also be useful for setting up non-MAME/emulation stuff in a linux arcade box as well.  *wonders how OpenTyrian would work at 120Hz 320x200?..*

[bent98]

is there gonna to be a .154 compile of groovymame anytime soon?

THanks

[Calamity]

is there gonna to be a .154 compile of groovymame anytime soon?

Sure. 0.154 has been released today, give us a few days

[bent98]

lol, I didn't realize it came out today. I am just getting back into the swing of things. I was running .144 so its been a while.

[Sledge]

is there gonna to be a .154 compile of groovymame anytime soon?

Sure. 0.154 has been released today, give us a few days

Your few days are up!!
lol

Got my .154 romset ready to go
Any major changes with the new version?

[Calamity]

Your few days are up!!
lol

Got my .154 romset ready to go
Any major changes with the new version?

Seeing that MKChamp hadn't included the patches for SDL, I was waiting for Ozfalcon's patch: http://forum.arcadecontrols.com/index.php/topic,64298.msg1453043.html#msg1453043

I'll be porting the current "groovy" patch to the new MAME version, no new features/fixes this time. I'll be addressing the current scaling/stretching issues on a future patch.

[Calamity]

Here goes the diff for v0.154 (+ the new MKChamp's hiscore diff with the SDL patches by Ozfalcon, thanks for including these, it makes for a cleaner GroovyMAME patch).

And here are the new binaries (Windows): https://drive.google.com/#folders/0B5iMjDor3P__eWcwWUxaV1RnSjQ

[Ansa89]

Thanks very much.

[Sledge]

Thanks Calamity!!

[Paradroid]

Cheers!

[Dr.Venom]

Thanks

[machyavel]

Thanks a lot!

[cools]

Thanks. AUR packages updated

[bent98]

My Current specs

Win xp 64 bit
ATI 4800HD
BL27CB0P 29” monitor dot .68mm max res 1024*768  HFreq 15-50khz VFreq 47-90HZ Bandwidth 100mhz
Video driver crt_emudriver_9.3_1.2a_x64_multisync
VM maker 1.3b
Groovy mame .154

I wanted to upgrade my groovy mame and mame rom set to the latest .154.  I started with a fresh mame setup and created a new mame.ini. Im my testing I noticed frogger and dig dug do not display properly. Dig dug is small and centered in the middle of screen and frogger is small and is half of the screen. I remember this specific provblem this and a few other games when I initially set up groovy mame 2+ years ago. I know a lot has changed since then. I was hoping to get some help.

I have enclosed the log files for both games and my mame.ini file.
Aside from needing help with the above peoblems I had a few other questions/observations.

1)   I am using d9800 as my monitor preset as there isn’t one for my bill labs model. I used the 9800 in the past as I was told they are close. I have posted specs of the monitor at the top of the thread. Not sure if we can add my monitors defaults to groovymame and add an entry for Billabs to groovymame.
2)   I noticed I had vmmaker 1.3b. I tried using 1.3c . I replicated my settings from my 1.3b ini file but 1.3c doesn’t seem to work for me. It screws up a lot of my games like dkong for instance. I switched back to 1.3b but would like to know why. 1.3c makes dkong use 512x512 resolution.


Edit: Update

Also noticed issues with moon patrol being small and centered on screen and NBA Jam too big for the screen, All worked with groovy mame .144

[bent98]

Seems the artwork folder was causing the issue even though I had it disabled in the .ini

[Calamity]

Seems the artwork folder was causing the issue even though I had it disabled in the .ini

Hi bent98, sorry for my late answer, indeed your logs show an artwork related common issue. If I remind right the other workaround was enabling the artwork_crop option.

[Calamity]

Thanks. AUR packages updated

Hi cools, thanks for the packages.

Regarding this new GM, after porting the patches I haven't had the change to test it on my actual machines yet. I'm noticing by the logs posted by people that most of the information that used be in the logs is no longer there. I'd say it has to do with what they've recently changed in base line MAME about osd_printf_verbose etc. I'll need to have a look through it because some important information is now missing in the logs that used to be there.

[bent98]

I had a few other questions/observations.

1) Punchout which is a two screen game displays both screens on one. but it looks squished,
2) Is there a way to display artwork for games like asteroids deluxe which had a background overlay while still maintain resolutions?
3)   I am using d9800 as my monitor preset as there isn’t one for my bill labs model. I used the 9800 in the past as I was told they are close. I have posted specs of the monitor at the top of the thread. Not sure if we can add my monitors defaults to groovymame and add an entry for Billabs to groovymame.
4)   I noticed I had vmmaker 1.3b. I tried using 1.3c . I replicated my settings from my 1.3b ini file but 1.3c doesn’t seem to work for me. It screws up most  of my games like dkong for instance. I switched back to 1.3b but would like to know why. 1.3c makes dkong use 512x512 resolution.
5) I noticed in my old ini i used waitsync. Its off by default do I need to use? I noticed most games run at 99.7% speed. Any way to make them run at 100%? Any issues with games not being sync properly?

[Calamity]

I had a few other questions/observations.

1) Punchout which is a two screen game displays both screens on one. but it looks squished,
2) Is there a way to display artwork for games like asteroids deluxe which had a background overlay while still maintain resolutions?
3)   I am using d9800 as my monitor preset as there isn’t one for my bill labs model. I used the 9800 in the past as I was told they are close. I have posted specs of the monitor at the top of the thread. Not sure if we can add my monitors defaults to groovymame and add an entry for Billabs to groovymame.
4)   I noticed I had vmmaker 1.3b. I tried using 1.3c . I replicated my settings from my 1.3b ini file but 1.3c doesn’t seem to work for me. It screws up most  of my games like dkong for instance. I switched back to 1.3b but would like to know why. 1.3c makes dkong use 512x512 resolution.
5) I noticed in my old ini i used waitsync. Its off by default do I need to use? I noticed most games run at 99.7% speed. Any way to make them run at 100%? Any issues with games not being sync properly?

1) This can be managed from the video menus in the ui.
2) You might try enabling artwork just for the game you want.
3) Can you point me to the specs, I can't find them. You could open a thread for your monitor. Basically creating specs depends on tests done on the user end that confirm that we're using the right timings.
4) You really need to use version 1.3c with newer versions of MAME. It won't read the new xml format otherwise. When you say you replicated to config did you just copy the .ini or you actually went through the new options? Pass me your .ini in another thread and I'll help you. It's working for everybody, there shouldn't be any problems.
5) Just leave it off, GM enables it automatically when required. 99.7% is probably the closest it can be because of the dotclock granularity.

[bent98]

I had a few other questions/observations.

1) Punchout which is a two screen game displays both screens on one. but it looks squished,
2) Is there a way to display artwork for games like asteroids deluxe which had a background overlay while still maintain resolutions?
3)   I am using d9800 as my monitor preset as there isn’t one for my bill labs model. I used the 9800 in the past as I was told they are close. I have posted specs of the monitor at the top of the thread. Not sure if we can add my monitors defaults to groovymame and add an entry for Billabs to groovymame.
4)   I noticed I had vmmaker 1.3b. I tried using 1.3c . I replicated my settings from my 1.3b ini file but 1.3c doesn’t seem to work for me. It screws up most  of my games like dkong for instance. I switched back to 1.3b but would like to know why. 1.3c makes dkong use 512x512 resolution.
5) I noticed in my old ini i used waitsync. Its off by default do I need to use? I noticed most games run at 99.7% speed. Any way to make them run at 100%? Any issues with games not being sync properly?

3) Can you point me to the specs, I can't find them. You could open a thread for your monitor. Basically creating specs depends on tests done on the user end that confirm that we're using the right timings.


4) You really need to use version 1.3c with newer versions of MAME. It won't read the new xml format otherwise. When you say you replicated to config did you just copy the .ini or you actually went through the new options? Pass me your .ini in another thread and I'll help you. It's working for everybody, there shouldn't be any problems.

BL27CB0P 29” monitor dot .68mm max res 1024*768  HFreq 15-50khz VFreq 47-90HZ Bandwidth 100mhz

Ill work on getting the ini with using 1.3c

[bent98]

Ok.

I tried using the stock 1.3c file and let it use ListFromXML = 1 and GenerateXML = 1. Hes the problem. Hyperspin doesnt start up. I think I remember we had this issue a few years back when you were helping me and thats why we didnt use the ListFromXML = 1 GenerateXML = 1 settings but I'm not 100% sure. In vmmaker.ini it's set to 120 modelines so it should allow Hyperspin to run?

MY monitor is a quad sync so its capable of 15khz all the way up to 1024x768. Im not sure if there is a way to get rid of the higher resolutions in windows so it doesnt waste those for modelines?

I also attached the new working vmmaker.ini

[bent98]

I got it working.

[ozfalcon]

Hi Calamity, Just looking at your new GM 0.154 diff.
Specifically relating to the change in scope to OPTION_SYNCREFRESH

This is going to get messy, But please bear with me.

As of mame 153, The patch moves these options to /src/emu/emuopts

From:
pc:/home/Compile/mame0153.clean$ fgrep -r OPTION_SYNCREFRESH .
./src/osd/windows/winmain.h:#define WINOPTION_SYNCREFRESH           "syncrefresh"
./src/osd/windows/winmain.h:   bool sync_refresh() const { return bool_value(WINOPTION_SYNCREFRESH); }
./src/osd/windows/winmain.c:   { WINOPTION_SYNCREFRESH ";srf",                   "0",        OPTION_BOOLEAN,    "enable using the start of VBLANK for throttling instead of the game time" },
./src/osd/sdl/osdsdl.h:#define SDLOPTION_SYNCREFRESH           "syncrefresh"
./src/osd/sdl/osdsdl.h:   bool sync_refresh() const { return bool_value(SDLOPTION_SYNCREFRESH); }
./src/osd/sdl/sdlmain.c:   { SDLOPTION_SYNCREFRESH ";srf",           "0",        OPTION_BOOLEAN,    "enable using the start of VBLANK for throttling instead of the game time" },

To:
pc:/home/Compile/mame0153.Hi_AGSND$  fgrep -r OPTION_SYNCREFRESH .
./src/emu/emuopts.h:#define OPTION_SYNCREFRESH          "syncrefresh"
./src/emu/emuopts.h:   bool sync_refresh() const { return bool_value(OPTION_SYNCREFRESH); }
./src/emu/emuopts.c:   { OPTION_SYNCREFRESH ";srf",                         "0",         OPTION_BOOLEAN,    "enable using the start of VBLANK for throttling instead of the game time" },


However, Mame 0.154 has already moved these to /src/osd/osdepend
pc:/home/Compile/mame0154.clean$ fgrep -r OPTION_SYNCREFRESH .
./src/osd/osdepend.c:   { OSDOPTION_SYNCREFRESH ";srf",           "0",        OPTION_BOOLEAN,    "enable using the start of VBLANK for throttling instead of the game time" },
./src/osd/osdepend.h:#define OSDOPTION_SYNCREFRESH           "syncrefresh"
./src/osd/osdepend.h:   bool sync_refresh() const { return bool_value(OSDOPTION_SYNCREFRESH); }


Is there still need to move it to /src/emu/emuopts ?
Hope this makes sense - Though I'm no expert - I may be wrong in my understanding of things.





Also as the scope has changed, I don't think you need these two sections.

One:
diff -Nru ./src_0.154_hi/osd/windows/video.c ./src/osd/windows/video.c
--- ./src_0.154_hi/osd/windows/video.c   2014-07-29 10:29:17.000000000 +0200
+++ ./src/osd/windows/video.c   2014-07-29 10:29:57.000000000 +0200
@@ -410,7 +419,7 @@
       video_config.mode = VIDEO_MODE_GDI;
    }
    video_config.waitvsync     = options.wait_vsync();
-   video_config.syncrefresh   = options.sync_refresh();
+   video_config.syncrefresh   = machine.options().sync_refresh();
    video_config.triplebuf     = options.triple_buffer();
    video_config.switchres     = options.switch_res();

Two:
diff -Nru ./src_0.154_hi/osd/sdl/video.c ./src/osd/sdl/video.c
--- ./src_0.154_hi/osd/sdl/video.c   2014-07-29 10:29:17.000000000 +0200
+++ ./src/osd/sdl/video.c   2014-07-29 12:01:47.000000000 +0200
@@ -692,12 +703,7 @@
    video_config.centerh       = options.centerh();
    video_config.centerv       = options.centerv();
    video_config.waitvsync     = options.wait_vsync();
-   video_config.syncrefresh   = options.sync_refresh();
-   if (!video_config.waitvsync && video_config.syncrefresh)
-   {
-      osd_printf_warning("-syncrefresh specified without -waitsync. Reverting to -nosyncrefresh\n");
-      video_config.syncrefresh = 0;
-   }
+   video_config.syncrefresh   = machine.options().sync_refresh();
 
    #if (USE_OPENGL || SDLMAME_SDL2)
       video_config.filter        = options.filter();

[Calamity]

Hi Calamity, Just looking at your new GM 0.154 diff.
Specifically relating to the change in scope to OPTION_SYNCREFRESH

Hi ozfalcon,

This patch has been there from the beginning and there's a very good reason to it. First just to clarify, the recent change in MAME has moved some options to the OSD_OPTION scope, but my understanding is that this has only been done to make them general for all osd implementations instead of having them defined in each of these implementations, which is a good thing. Anyway this doesn't change the fact that -syncrefresh is still defined in the osd side. And this is exactly the problem. IMHO, from a design point of view, -syncrefresh should have always been defined as a core option, just like -throttle is. This is necessary so that -syncrefresh can be accesed from the throttling function in emu\video.c, and so it can be decided whether the cpu clock should be used for waiting or we should just rely on the wait for vsync implementation instead. This is how things were indeed before v0.114, we're just restoring the previous functionality, just like it is still documented as working in the official docs. Then the actual code for vsync is implemented by the different osd modules and controlled by the -waitvsync option (had you ever wondered why there are two options -syncrefresh and -waitvsync for mostly the same thing?).

[ozfalcon]

Hi Calamity, Just looking at your new GM 0.154 diff.
Specifically relating to the change in scope to OPTION_SYNCREFRESH

Hi ozfalcon,

This patch has been there from the beginning and there's a very good reason to it. First just to clarify, the recent change in MAME has moved some options to the OSD_OPTION scope, but my understanding is that this has only been done to make them general for all osd implementations instead of having them defined in each of these implementations, which is a good thing. Anyway this doesn't change the fact that -syncrefresh is still defined in the osd side. And this is exactly the problem. IMHO, from a design point of view, -syncrefresh should have always been defined as a core option, just like -throttle is. This is necessary so that -syncrefresh can be accesed from the throttling function in emu\video.c, and so it can be decided whether the cpu clock should be used for waiting or we should just rely on the wait for vsync implementation instead. This is how things were indeed before v0.114, we're just restoring the previous functionality, just like it is still documented as working in the official docs. Then the actual code for vsync is implemented by the different osd modules and controlled by the -waitvsync option (had you ever wondered why there are two options -syncrefresh and -waitvsync for mostly the same thing?).

Ok, I think I understand.
Putting -syncrefresh in /emu/emuopts makes it a core option like throttle (So it can be accessed by /emu/video.c)

The 154 patch removes one osdepend entry:
diff -Nru ./src_0.154_hi/osd/osdepend.h ./src/osd/osdepend.h
--- ./src_0.154_hi/osd/osdepend.h   2014-07-29 10:29:17.000000000 +0200
+++ ./src/osd/osdepend.h   2014-07-29 10:29:57.000000000 +0200
@@ -85,7 +85,6 @@
    bool keep_aspect() const { return bool_value(OSDOPTION_KEEPASPECT); }
    bool uneven_stretch() const { return bool_value(OSDOPTION_UNEVENSTRETCH); }
    bool wait_vsync() const { return bool_value(OSDOPTION_WAITVSYNC); }
-   bool sync_refresh() const { return bool_value(OSDOPTION_SYNCREFRESH); }
 
    // per-window options
    const char *screen() const { return value(OSDOPTION_SCREEN); }


I'm still unclear about these entries.
./src/osd/osdepend.c:   { OSDOPTION_SYNCREFRESH ";srf",           "0",        OPTION_BOOLEAN,    "enable using the start of VBLANK for throttling instead of the game time" },
./src/osd/osdepend.h:#define OSDOPTION_SYNCREFRESH           "syncrefresh"


I'll have to take another look and understand how it works.

[ozfalcon]

Calamity, This section has me confused. Can you explain why this line uses OSDOPTION_SYNCREFRESH ?
ie. What is the difference between OPTION_SYNCREFRESH and OSDOPTION_SYNCREFRESH here?

Line:
+   set_option_osd(machine, OSDOPTION_SYNCREFRESH, !options.triple_buffer());

From:
diff -Nru ./src_0.154_hi/osd/windows/switchres.c ./src/osd/windows/switchres.c
--- ./src_0.154_hi/osd/windows/switchres.c   1970-01-01 01:00:00.000000000 +0100
+++ ./src/osd/windows/switchres.c   2014-07-29 10:29:57.000000000 +0200
.
+   // Vertical synchronization management
+   // Unless -syncrefresh is forced, we only enable v-sync if the refresh difference is below the value specified by -sync_refresh_tolerance.
+   // Otherwise -triplebuffer is used, provided we run multithreaded
+   // Forcing -triplebuffer will override the -syncrefresh setting
+   bool triple_buffer_effective = options.triple_buffer() && options.multithreading() && !(options.sync_refresh() && machine.options().priority(WINOPTION_TRIPLEBUFFER) < machine.options().priority(OPTION_SYNCREFRESH));
+   set_option_osd(machine, WINOPTION_TRIPLEBUFFER, triple_buffer_effective || (!options.sync_refresh() && !black_frame_insertion && ((best_mode->result.weight & R_V_FREQ_OFF) || best_mode->result.v_scale > 1)));
+   set_option_osd(machine, OSDOPTION_SYNCREFRESH, !options.triple_buffer());
+   set_option_osd(machine, OSDOPTION_WAITVSYNC, options.sync_refresh());



Extra info:
The SDL switchres seems to use only OPTION_SYNCREFRESH

diff -Nru ./src_0.154_hi/osd/sdl/switchres.c ./src/osd/sdl/switchres.c
--- ./src_0.154_hi/osd/sdl/switchres.c   1970-01-01 01:00:00.000000000 +0100
+++ ./src/osd/sdl/switchres.c   2014-07-29 10:29:57.000000000 +0200
.
+   // Disable -syncrefresh if our vfreq is scaled or too off
+   set_option_osd(machine, OPTION_SYNCREFRESH, !(best_mode->result.weight & R_V_FREQ_OFF || best_mode->result.v_scale > 1) || black_frame_insertion);