GroovyMame for arcade monitors version 0.146u4_013f

[Calamity]

One more thing: after setting the monitor_spec0, some vertical games (galaga, galaga88, galaxian) were displayed out of frequency.
Looking your monitor_spec0, I changed it this way:

Code: [Select]

15625-15800,49.50-60.50,2.000,4.700,8.000,0.064,0.160,1.056,0,0,288,448
That's fine. That was a generic setting for arcade monitors. It's reasonable that a TV has a narrower range for hfreq. Vfreq should be fine a bit higher than 60 (think that many games use the 60.606060 Hz frequency), but that's not too important.

As you can see, the previous vfreq and hfreq were too high, so I searched for pal specification and adjusted the values to something more comfortable.
Now everyone seem happy (me too) .

The problem with the PAL/NTSC presets in GroovyMAME is that they only accept a fixed value for vfreq when that's not how real devices work. So my advice is to always use custom ones based on the line I passed above. Apart from that it seems that I broke those fixed frequency settings when changing some stuff in the modeline generator, I'll need to fix it.

[Ansa89]

Ok, thanks for all your work .

[ozfalcon]

Are you using the waitvsync option?

NOTE the Typo bug: http://mamedev.org/source/src/osd/sdl/video.c.html

When is says "-waitsync" it's referring to "-waitvsync"
 

Code: [Select]

SwitchRes v0.013: [mslug3] (1) horizontal (320x224@59.19)->(320x224@59.19)->(320x224@33.39)
-syncrefresh specified without -waitsync. Reverting to -nosyncrefresh
Average speed: 100.00% (10 seconds)No errors at all and the screen continuing flickering .

Now what?
[/quote]

[Ansa89]

The problem was an incorrect monitor_spec0 line.
I launch the games from advancemenu without passing any arguments (at least that's what I think).

[Ansa89]

With update 7 (mame 0.144u7) groovymame patch needs a little change:

Code: [Select]

--- 0144u2_groovymame_013d.diff 2012-01-31 12:35:52.075364846 +0100
+++ 0144u7_groovymame_013d.diff 2012-01-31 13:57:31.780794671 +0100
@@ -1234,7 +1234,7 @@
 diff -Nru src/emu/switchres/switchres.c src/emu/switchres/switchres.c
 --- src/emu/switchres/switchres.c      1970-01-01 01:00:00.000000000 +0100
 +++ src/emu/switchres/switchres.c      2011-12-05 19:25:14.000000000 +0100
-@@ -0,0 +1,390 @@
+@@ -0,0 +1,391 @@
 +#include "emu.h"
 +#include "emuopts.h"
 +
@@ -1327,7 +1327,8 @@
 +        r = ATTOSECONDS_TO_HZ(devconfig->refresh_attoseconds());
 +
 +      gameInfo->screens = 0;
-+        for (devconfig = config.first_screen(); devconfig != NULL; devconfig = devconfig->next_screen())
++      screen_device_iterator iter(config.root_device());
++      for (devconfig = iter.first(); devconfig != NULL; devconfig = iter.next())
 +                gameInfo->screens++;
 +
 +      if (resolution->width != 0 && resolution->height != 0) {I don't know if it needs some other workarounds due to mame upgrade, but at least it compiles .

[Calamity]

I don't know if it needs some other workarounds due to mame upgrade, but at least it compiles .

Thanks Ansa, hopefully in the next days (weeks) I find some time to update GM and try this.

[Ansa89]

Note that we are near to mame 0.145, so a reworked patch should be fine within the new official release.

[Calamity]

Note that we are near to mame 0.145, so a reworked patch should be fine within the new official release.

Sure, I've rewritten the soundsync patch in a way that may eventually work in Linux too. I intended to launch it together with the 0.145 version. I can't build the Linux part however 

[Ansa89]

When you release it, I will try to build and test under linux.

[Calamity]

Version 0.145 is uploaded:

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

groovymame32_0145.013e.rar
groovymame64_0145.013e.rar
groovymame32_0145.013e_wiimote_linux.tar.bz2

0145_groovymame_013e.diff

Thanks go to:

- VeS for building the Linux binary including Wiimote support.
- Ansa89 for his patch update.

Compiling notes

Apply patches in this order:

1) hi_145.txt (http://mamestuff.lowtrucks.net/MKChamp/)
2) 0145_groovymame_013e.diff (http://mario.groovy.org/GroovyMame/WindowsATIDrivers/)


Important notes about the new groovy-013e patch


Some default options have been changed in the version. Make sure to create a fresh mame.ini file.

The 'soundsync' patch has been completely rewritten in an attempt to port its functionality to the Linux side. Now there's no 'soundsync' option anymore. The emulator core has been subtly modified in a way that allows the sound to be always synchronized with the game's speed. Thus, this patch is not OS-dependent and works in Linux too.

In order to achieve this, MAME's 'syncrefresh' option has been moved from the OS layer right into the emulator core. In our humble opinion, from a design point of view, this is where it should always have been, as the 'syncrefresh' option shouldn't belong to the layer where the final wait-for-vsync implementation is performed, but be part of the emulator's throttling mechanism.

Another important implication is that the 'throttle' option now needs to be enabled in order for 'syncrefresh' to be considered. A modification of the throttling mechanism makes it possible to have 'throttle' and 'syncrefresh' enabled and still enjoy smooth scrolling. When in the game, by pressing F10, the game can be throttled/unthrotted even with 'syncrefresh' enabled.

As usual, the 'triplebuffer' option (ony Windows) can be enabled to achieve truly asynchronous tearing-less rendering, improving performance in some situations, at the cost of scroll stuttering. Notice that 'triplebuffer' has preference over 'syncrefresh', so if both are enabled, only 'triplebuffer' will be considered.

Finally, remind that the 'waitvsync' option is managed internally by GroovyMAME, so whatever value you use will be overridden. Use syncrefresh/triplebuffer instead.

Linux notes


You'll need to manually enable the 'cleanstretch' option in mame.ini in order to get the right aspect for vertical games.

Bugs fixed

- Windows: Many crashes due to the 3-threaded rendering mechanism, when running games that switch resolutions, or using ALT+ENTER, ALT+TAB, maximizing, minimizing, etc. This should be the most stable GroovyMAME version on that regard (update: still found a crash in XP-64 build, I'm afraid)

- Windows: Crash when the -nomodeline option was used.

[Paradroid]

Sounds fantastic! Thanks! Will try tonight! 

[Ansa89]

I will try it ASAP.

[Paradroid]

Again, thank you. It's working great here! No problems at all with the games I tried. Smooth as always!

[Ansa89]

With groovymame 0.145 the sound is scratchy (tried with galaga, tekken 3, nba hangtime) .
Are there some options I can set/unset?

[Calamity]

With groovymame 0.145 the sound is scratchy (tried with galaga, tekken 3, nba hangtime) .
Are there some options I can set/unset?

Did you create a fresh mame.ini?

[Ansa89]

Yep, but (just to be sure) I will recreate it (tomorrow, because now my mom doesn't let me play with the cab... ).
Any other suggestion?

[Calamity]

Just make sure that the throttle and syncrefresh options are enabled. Possibly try disabling waitvsync.

I wanted to test it today too but for some reason the UpdateGroovyMame command failed, I guess Linux doesn't like the name I gave to the .tar file??

[Ansa89]

I wanted to test it today too but for some reason the UpdateGroovyMame command failed, I guess Linux doesn't like the name I gave to the .tar file??

I never used that script: to compile groovymame I download all patches and sources by hand and then use a slackbuild which build a slackware package.
If you post the script, I will give a look at this.

[ves]

Just make sure that the throttle and syncrefresh options are enabled. Possibly try disabling waitvsync.

I wanted to test it today too but for some reason the UpdateGroovyMame command failed, I guess Linux doesn't like the name I gave to the .tar file??

Hello Calamity, forgets of putting the name of the compressed file of this form Groovy ****** the first letter it is with capital letter.

[Calamity]

Hello Calamity, forgets of putting the name of the compressed file of this form Groovy ****** the first letter it is with capital letter.

Thanks, I've edited the file name, figured it had to be something like that, I'll never get used to Linux's case sensitivity. I'll try it later.

[Calamity]

With groovymame 0.145 the sound is scratchy (tried with galaga, tekken 3, nba hangtime) .
Are there some options I can set/unset?

Finally I could try the Linux version. Everything works fine here with the right options, the sound is smooth and get's adjusted to the action when syncrefresh is used and speed doesn't reach 100% (dkong, dspirit, etc.)

[Ansa89]

Just make sure that the throttle and syncrefresh options are enabled. Possibly try disabling waitvsync.

With throttle, sycrefresh and waitvsync all enabled, the sound is a bit delayed (with Tekken 3 if I hit the opponent, I hear the hit-sound a bit after I should hear it; same with galaga).
Now I will try disabling waitvsync.

[Calamity]

With throttle, sycrefresh and waitvsync all enabled, the sound is a bit delayed (with Tekken 3 if I hit the opponent, I hear the hit-sound a bit after I should hear it; same with galaga).
Now I will try disabling waitvsync.

I didn't notice that exactly (tested tekken3 and galaga too among others). Please check the speed these games are running. With -syncrefresh enabled, galaga runs at 89% in my system, tekken3 can't remember but it certainly looks like slow motion. So what I noticed is a delay proportional to the speed decrease, and the difference in pitch one would expect. But the sound is not choppy anymore.

[Ansa89]

On my system tekken3 runs at 99% - 100%, galaga at 100% and everything is ok, but sound (for tekken3) is delayed.

[dmarcum99]

Anyone fancy to compile a 64-bit binary for the new groovymame?  I have a 64-bit hard-drive install and I tried to use the updated 32-bit binary but it was unsuccessful...lots of flickering on my d9200.  I've compiled windows binaries before but I'm about useless under linux.  I use the live-cd because it "just works" out of the box.   

My rom set is from .143u9...will the .145 binary cause the cave games to dissapear??

[Ansa89]

I upgraded groovymame patch, so it can be applied to mame 0.145u1.


Compiling notes

Apply patches in this order:

1) 0145u1.diff (http://mamedev.org/updates.html)
2) hi_145u1.txt (http://mamestuff.lowtrucks.net/MKChamp/)
3) 0145u1_groovymame_013e.diff


PS: I also found a bug (in mame core) about ldresample. If you need that binary, don't upgrade.

[Calamity]

That's great! Thanks

[Ansa89]

Anyone fancy to compile a 64-bit binary for the new groovymame?

Why can't you compile it yourself?
It gives you some errors?

My rom set is from .143u9...will the .145 binary cause the cave games to dissapear??

Probably yes.

[Calamity]

Why can't you compile it yourself?
It gives you some errors?

Well, I understand dmarcum99 here, compiling Mame is not an easy task for everybody.

For instance, I'm compiling the Windows binaries now routinely, but don't have a clue of how to set my system up for Linux compiling. I'd like to, but have read I need Cygwin and stuff...

My rom set is from .143u9...will the .145 binary cause the cave games to dissapear??

That is a fact.

[senorchris]

Hi Calamity,

I was trying to compile the x64 version of GroovyMAME tonight, and I think I found a small bug that would only affect the Windows x64 version, and only at compile time.  In osd\windows\window.c, you're patching in the following snippet:

Code: [Select]

@@ -1431,6 +1543,8 @@
  // syscommands: catch win_start_maximized
  case WM_SYSCOMMAND:
  {
+ mame_printf_verbose("window_proc: WM_SYSCOMMAND %d\n", wparam);
+
  // prevent screensaver or monitor power events
  if (wparam == SC_MONITORPOWER || wparam == SC_SCREENSAVE)
  return 1;
The problem is, in the x64 compiler, the wparam variable (a WPARAM type) is a 64-bit integer, and doesn't like being printf'd as a %d.  Casting it to a 32-bit integer lets it compile fine.  More info here.

This should fix it (it compiles at least, will let you know if I run into any bugs when I get a chance to use it):

Code: [Select]

@@ -1431,6 +1543,8 @@
  // syscommands: catch win_start_maximized
  case WM_SYSCOMMAND:
  {
+ mame_printf_verbose("window_proc: WM_SYSCOMMAND %d\n", (UINT32)wparam);
+
  // prevent screensaver or monitor power events
  if (wparam == SC_MONITORPOWER || wparam == SC_SCREENSAVE)
  return 1;
Cheers - I really appreciate all you're doing for the community!

[Ansa89]

PS: I also found a bug (in mame core) about ldresample. If you need that binary, don't upgrade.

Someone else find it out: bug 4697, bug 4698.
These issues will be fixed in update2.

[Calamity]

I was trying to compile the x64 version of GroovyMAME tonight, and I think I found a small bug that would only affect the Windows x64 version, and only at compile time.  In osd\windows\window.c, you're patching in the following snippet:

Thanks senorchris for pointing this and your explanation, that's true. I had to fix it when building the 64-bit binary but forgot to include it in the diff.

[Ansa89]

I think it's time for official 0.145u1 groovymame patch to be uploded .

[androtaz08]

Any reason why I lose my control settings when updating to this version?

[jimmy2x2x]

does the binary 'groovymame64_0145.013e.rar' have working high score support?

[Ansa89]

Every groovymame binary should have high score support (it's a prerequisite in order to apply groovymame patch).

[jimmy2x2x]

Is it working for you?

[Calamity]

does the binary 'groovymame64_0145.013e.rar' have working high score support?

Yes it has, but make sure to place the hiscore.dat inside the \hi folder, contrary to other builds where you just place it in MAME's main folder. This was done like this for compatibility with Linux.

[Ansa89]

I don't use the prebuilt binary, I compile groovymame by myself.
Moreover I use it under linux, so I can't test it.

My previous post was only a thought (since I know how the groovymame patch works), for a correct answer we must wait Calamity.


EDIT: @Calamity: posted at the same time...

[jimmy2x2x]

does the binary 'groovymame64_0145.013e.rar' have working high score support?

Yes it has, but make sure to place the hiscore.dat inside the \hi folder, contrary to other builds where you just place it in MAME's main folder. This was done like this for compatibility with Linux.

that did it, cheers!