GroovyMame for arcade monitors version 0.146u4_013f

[krick]

I will extend my thanks to bitbytebit and Calamity for burning their free time to create this fine piece software.

Make sure you donate too.  I encourage anyone who is using GroovyMAME and/or the custom ATI drivers to donate.

[gabe]

Has anyone successfully compiled GroovyMAME in any other Linux distros? I'm trying to do so in Arch, but am getting snagged up here:

Code: [Select]

obj/sdl/groovymame64/libocore.a: could not read symbols: Malformed archive
collect2: ld returned 1 exit status
make: *** [obj/sdl/groovymame64/build/makedep] Error 1
Any ideas?

[gabe]

To clarify (and update) I get the above error when trying to make after doing:

Code: [Select]

git clone git://git.groovy.org/groovy/groovymame0142.git
If I try to prepare the source myself, I run into problems similar to those described here. 0142_hi.diff applies just fine, but 0142_hilinux.diff fails, which of course causes 0142_groovymame.diff to fail.

I unzip the virgin MAME 0.142 source with:

Code: [Select]

unzip -aa mame.zip
I do not apply any update patches. I then apply 0142_hi.diff, 0142_hilinux.diff, and
0142_groovymame.diff (in order) with:

Code: [Select]

patch -p0 -E <0142_hi.diff
Following this method, patch -p0 -E <0142_hilinux.diff spits out the following:

Code: [Select]

patching file src/emu/emuopts.c
Hunk #1 FAILED at 194.
1 out of 1 hunk FAILED -- saving rejects to file src/emu/emuopts.c.rej
patching file src/emu/hiscore.c
Hunk #1 FAILED at 349.
1 out of 1 hunk FAILED -- saving rejects to file src/emu/hiscore.c.rej
patching file src/osd/sdl/osdsdl.h
Hunk #1 FAILED at 242.
1 out of 1 hunk FAILED -- saving rejects to file src/osd/sdl/osdsdl.h.rej
patching file src/osd/sdl/video.c
Hunk #1 FAILED at 351.
1 out of 1 hunk FAILED -- saving rejects to file src/osd/sdl/video.c.rej
patching file src/osd/sdl/window.c
Hunk #1 FAILED at 1006.
1 out of 1 hunk FAILED -- saving rejects to file src/osd/sdl/window.c.rej
patching file src/osd/sdl/window.h
Hunk #1 FAILED at 129.
1 out of 1 hunk FAILED -- saving rejects to file src/osd/sdl/window.h.rej

[Calamity]

Just something to try: check if applying the patches using Mame Compiler for Windows works, then make your build under Linux.

[abispac]

Groovy mame needs it's own forum section.

you got your 5 minutes of fame and allready want a forum section, ive seen posts larger then this threat, i remember uncle t having its own section,not to mention powermame and skjukebox and dos sections are dead...

But I bet they are still full of relevant information for whomever might want to run them, or have run them in the past.

Between the Groovy build and the drivers, there are a lot of possibilities for different configurations on different display devices that would be more easily serviced in individual threads. Even if it were abandoned in a year there would still be a good bit of searchable information there.

Currently I'm running on an SVGA monitor, but essentially using native resolutions/refresh rates without visible scaling, and filling the screen on every resolution. I don't think that's something that had been easily done previously. Likewise I recently tested it on an LCD with a variable refresh rate range and was able to run MK1 at ~99% speed with perfect sync-- even on the infamous character scroll screen there was no visible tearing or judder. If the monitor had supported a slightly wider range of refresh rates it would have been synced at 100%.

I think there is too much active development going on for a single thread to be a viable place to discuss it. Even a dozen threads on an existent board would be scattered and hard to correlate.

I was just teasing, actualy i think this project its great, im still lurking on it.....

[jimmy2x2x]

Calamity, have you had any time to produce a new .diff with the most recent changes (+ hiscores working)?

Or will you guys be waiting for 0.143 for the next release (I suspect its coming towards the end of the .142 cycle)?

Any news on the BYOAC GroovyMame forum, will it have sub forums for 'nix and drivers, how are you going to structure it?

Many thanks

[Calamity]

Calamity, have you had any time to produce a new .diff with the most recent changes (+ hiscores working)?

I had a look at the hiscore issue but found no reason why it shouldn't work... you say it does work for the mainline Groovymame?
I'm working on fixing some of the issues I mentioned above, will have it ready soon hopefully.

Or will you guys be waiting for 0.143 for the next release (I suspect its coming towards the end of the .142 cycle)?

Yes, 0.143 is about to come, if bitbytebit isn't back by then I'll try to adapt the patches for the new version, it shouldn't be too difficult unless they've changed too much stuff in the involved files since 0.142 version, however later patches where quite clean to apply.

Any news on the BYOAC GroovyMame forum, will it have sub forums for 'nix and drivers, how are you going to structure it?

Many thanks

I think an unique subforum should be more than enough to keep the different subjects in separate threads. Honestly I'm happy enough with these spaghetti threads but I understand that it is a mess to get any information from for the newcomers.

[jimmy2x2x]

Yes, for me Highscores stopped working in the test versions but do work fine in my compile of groovymame (from the supplied diff)

Ps. Glad you saw the light with the LCD refresh rate thread - that guy is poison.

[gabe]

Just something to try: check if applying the patches using Mame Compiler for Windows works, then make your build under Linux.

That did the trick, thank you - I probably should have been able to figure that out based on jimmy2x2x's posts above, but for whatever reason I tuned them out as being a "Windows solution."

Games look awesome, however I have found a couple oddities. Most notably, if multithreading is enabled, many games run at break-neck speed; unplayably fast. I'm not sure what the common thread is here, but it spans several different drivers. I'm not too concerned about it, however I find it interesting as multithreading worked fine using a vanilla install of sdlmame.

In case this helps... This occurs in ArchLinux using a kernel built with bitbytebit's GroovyLinux patches on an AVGA3000 with the stock open source ATI driver feeding a 25" Wells-Gardner k7191.

[krick]

Games look awesome, however I have found a couple oddities. Most notably, if multithreading is enabled, many games run at break-neck speed; unplayably fast. I'm not sure what the common thread is here, but it spans several different drivers. I'm not too concerned about it, however I find it interesting as multithreading worked fine using a vanilla install of sdlmame.

In case this helps... This occurs in ArchLinux using a kernel built with bitbytebit's GroovyLinux patches on an AVGA3000 with the stock open source ATI driver feeding a 25" Wells-Gardner k7191.

I've seen that happen when running GroovyMAME on my PC monitor with a normal video card, but when running on my arcade cabinet (Windows XP x64 + ArcadeVGA 3000 + Hantarex Polo 25), I've never seen it happen unless GroovyMAME loses focus.

What specific games do this in your build?  I'd like to try them on my setup with the stock Windows GroovyMAME build (groovymame64_0142.012o) to see if I can reproduce it.

[Calamity]

Games look awesome, however I have found a couple oddities. Most notably, if multithreading is enabled, many games run at break-neck speed; unplayably fast. I'm not sure what the common thread is here, but it spans several different drivers. I'm not too concerned about it, however I find it interesting as multithreading worked fine using a vanilla install of sdlmame.

The multithreading full-speed issue was fixed before and was even added to the mainline Mame, so I'm not sure what this new problem could be. Probably is due to how -waitvsync is managed, but it's sure it has worked before. Please post a complete log by running a game with the -v -md 4 params so we can have a look.

Yes, for me Highscores stopped working in the test versions but do work fine in my compile of groovymame (from the supplied diff)

For some reason I can't get my hiscores recorded even with the "official" groovymame. Testing 1942a, must be doing something wrong (hiscore.dat is in the same folder as Mame.exe, hiscore_directory hi, deleted .nv files, hiscore patch enabled...)

[gabe]

I've seen that happen when running GroovyMAME on my PC monitor with a normal video card, but when running on my arcade cabinet (Windows XP x64 + ArcadeVGA 3000 + Hantarex Polo 25), I've never seen it happen unless GroovyMAME loses focus.

What specific games do this in your build?  I'd like to try them on my setup with the stock Windows GroovyMAME build (groovymame64_0142.012o) to see if I can reproduce it.

You may be onto something with the "losing focus" deal. I'm not using a window manager - just plain old X. I autologin using SLiM, and then launch wahcade -f from .xinitrc. It works great, however I'm not really sure how window focus is handled when no window manager is used. I'll try installing a window manager to see if it makes a difference.

Several (all?) games that use neodrvr.c suffer from this "bug." In particular I observed it with Twinkle Star Sprites (twinspri). I also observed it with DonPachi (donpachi) which uses cave.c.

Please post a complete log by running a game with the -v -md 4 params so we can have a look.

I will do that once I get home.

[Calamity]

You may be onto something with the "losing focus" deal. I'm not using a window manager - just plain old X. I autologin using SLiM, and then launch wahcade -f from .xinitrc. It works great, however I'm not really sure how window focus is handled when no window manager is used. I'll try installing a window manager to see if it makes a difference.

It could be due to Mame not getting access to the vysnc features. When GroovyMame considers the calculated refresh is close enough to the target one it disables the throttle option and just uses waitvsync as a timer, but if for some reason vsync is not working it will make it run fullspeed. But it's strange that it just happens with multithreading enabled. Try glxgears to see if vsync works.

[Calamity]

Yes, for me Highscores stopped working in the test versions but do work fine in my compile of groovymame (from the supplied diff)

jimmy2x2x, try moving hiscore.dat inside the "hi" directory, I think that's necessary once 0142_hilinux.diff is applied.

[jimmy2x2x]

Mame 0.143 is out It would be a great start for the new forum if you guys are ready?

I will test the highscore today and let you know.

Thanks

[gabe]

You may be onto something with the "losing focus" deal. I'm not using a window manager - just plain old X. I autologin using SLiM, and then launch wahcade -f from .xinitrc. It works great, however I'm not really sure how window focus is handled when no window manager is used. I'll try installing a window manager to see if it makes a difference.

It could be due to Mame not getting access to the vysnc features. When GroovyMame considers the calculated refresh is close enough to the target one it disables the throttle option and just uses waitvsync as a timer, but if for some reason vsync is not working it will make it run fullspeed. But it's strange that it just happens with multithreading enabled. Try glxgears to see if vsync works.

As usual, I was over-thinking the problem. After successfully compiling GroovyMame, I generated the default config (per the documentation). I tested it the default config, and found out that it worked... So I decided to start changing things (because I'm a chronic tinkerer). In any event, I discovered that many (but not all) games suffer from speedup under the following scenarios:

Code: [Select]

waitvysnc 1
syncrefresh 0
multithreading 1

Code: [Select]

waitvysnc 0
syncrefresh 0
multithreading 1
The problem does not appear with multithreading 0. This obviously has something to do with the way Groovymame handles waitvsync (as described earlier in the thread). I would also guess that toggling triplebuffer and throttle may have an effect here.

Anyway - I'm sorry for n00bing up the thread with my incompetence. That said, I still think the multithreading link is an interesting one. I wouldn't have guessed that it would have an effect on any of the above options.

[Calamity]

The problem does not appear with multithreading 0. This obviously has something to do with the way Groovymame handles waitvsync (as described earlier in the thread). I would also guess that toggling triplebuffer and throttle may have an effect here.

So in order to make it work all the time you need to have -syncrefresh enabled?
I don't know the SDL part as well as the Windows one as far as the vsync options are concerned, I'll have a look anyway.
The triplebuffer option has no effect under Linux, AFAIK.

I'm trying to port the groovymame patches to the 0.143 version, let's see if it works...

[gabe]

So in order to make it work all the time you need to have -syncrefresh enabled?

Correct.

I'm trying to port the groovymame patches to the 0.143 version, let's see if it works...

Can't hardly wait!

[Calamity]

  I was uploading my Groovymame 0.143 binary just to realize that bitbytebit already has the new diff here: http://mario.groovy.org/GroovyMame/0143/

[jimmy2x2x]

Brilliant!

Does that .diff include all your recent changes Calamity?

Thanks

[Calamity]

Brilliant!

Does that .diff include all your recent changes Calamity?

Thanks

No, I assume those are the .12o patches adapted to 0.143.

I'm removing my diff in http://mario.groovy.org/GroovyMame/WindowsATIDrivers/ to avoid confusions.

I'll add the experimental test patches to this one as soon as I can.

[bitbytebit]

Just uploaded 0143.013 version of groovymame .  I had time to build the patch, binaries and patches are up now.

Calamity, let me know any diffs possibly that you have worked on and I will include those, if you feel they are ready.  I haven't been paying much attention to the threads here but saw mame 0143 came out last night and so have updated the patches for it, but see you've been getting some things improved to fix the frogger issues and possibly others, looks exciting.

ISO's will be up in a day or two most likely.

[saint]

Does the (do the) owner (owners) of GroovyMame want a dedicated subforum?

[bitbytebit]

Does the (do the) owner (owners) of GroovyMame want a dedicated subforum?

Sure, that sounds good to me, guessing Calamity probably feels the same.

[gabe]

Just uploaded 0143.013 version of groovymame .  I had time to build the patch, binaries and patches are up now.

Thanks! I compiled yesterday, and things are working smoothly.

[jimmy2x2x]

bitbytebit: is 0143_hilinux.diff required for windows builds?

Thanks

[Calamity]

bitbytebit: is 0143_hilinux.diff required for windows builds?

Thanks

Yes, you need to apply all of them even if you're going to make a windows build, otherwise the groovymame.diff will fail to apply.

[jimmy2x2x]

Interesting, it will compile without it for me.

Without 0143_hilinux.diff (base 0.143 + hi_143.txt + 0143_groovymame.diff)

hiscores work as expected

screen rotation works as per stock mame

With 0143_hilinux.diff (base 0.143 + hi_143.txt + 0143_hilinux.diff + 0143_groovymame.diff)

hiscore.dat has to be in the hi folder, otherwise hiscores will not work

screen rotation is upside down for me (vertical monitor), rotating 90 CW in tab/video options menu fixes this but leaves the gui upside down. I think you have to do this for each game, as I cant seem to get it right with mame.ini settings. (Calamity fixed this issue for 0.142, is this .diff essential?)

Thanks

[Calamity]

Just uploaded 0143.013 version of groovymame .  I had time to build the patch, binaries and patches are up now.

Calamity, let me know any diffs possibly that you have worked on and I will include those, if you feel they are ready.  I haven't been paying much attention to the threads here but saw mame 0143 came out last night and so have updated the patches for it, but see you've been getting some things improved to fix the frogger issues and possibly others, looks exciting.

ISO's will be up in a day or two most likely.

I've attached the diff file with the fixes I've been doing, this must be applied over after the 0143_groovymame.diff in order to work.
I'm going to sum up the different fixes before I forget about the details. Feel free to add or drop all or part of them:

emu\render.c
------------
- Moved changeres code from "render_target::get_primitives()" to "compute_visible_area", this fixes an issue when minimazing/maximizing the window that invoked many false changeres events that made this process very slow. Also, doing this fixes the aerofgts issue when displayed fullscreen on vertical monitor.
- Removed the frogger/galaxian fix
- TO DO: fix the changeres patch for the case of a vertical game displayed on horizontal monitor which changes resolutions (i.e. aerofgts). The issue here is that after a resolution change the display size obtained by the changeres patch is already rotated, say 240 x 320, but as the stored game info says it's a vertical game, the resolution is rotated again in the modeline generator producing a chopped display.

emu/switchres/switchres.c
-------------------------
- Changed the rotate options from autol, rol, to autoror, ror, as this the usual orientation for rotated monitors, otherwise the display was upside down, however it would be nice to have an option for this eventually.

/mame/drivers/galaxian.c
/mame/includes/galaxian.h
-------------------------
- Patch for galaxian/frogger. I was reluctant to patch anything on the mame part of the source code, but this patch is so simple it seems that mame devs already thought of this possibility. Actually it would be enougth to change the GALAXIAN_XSCALE constant in galaxian.h if it wasn't because some "3" values are hardcoded in galaxian.c.

/osd/windows/switchres.c
------------------------
- Commented out the part where it orders the mode table, as the swap function was not swapping the string labels, corrupting the mode table if the mode list returned by the system is not perfectly ordered already. This one was hard to figure out.
- In the find_best_mode algorithm, now interlaced resolutions are not penalized if we are looking for a virtualized resolution (I added this at some point trying to fix an issue though I'm not sure it's really necessary).

/osd/windows/window.c
-----------------------
- All the changes in this file are experimental for the new blitting thread method, so can be safely discarded, though I've come to a point where it's really stable here, so would be glad if someone wants to test (this patch was already included in the test version some people here have been using).

For a brief explanation: normal mame, when in multithreading mode, uses two processing threads: main thread and window thread. The idea is that the main thread handles the emulator thing, while the window thread deals with input and output (video). Everything is fine with this design unless you decide to vsync. As the vsync functionality is inside the video part this means that waiting for vsync freezes the window thread during instant, locking the window for input, enough to cause a noticeable input lag.

On the other hand normal Groovymame patches partially fix this issue for -syncrefresh by performing the wait in the main thread, but unfortunately -triplebuffer is still done in the window thread to allow for asynchronous blitting, keeping some input lag that's specially bad when native refresh is very different than the achieved one (60Hz vs 53Hz modeline). Additionally, this situation causes visual artifacts as more or less intermittent flashing.

Finally, this new patch uses three different threads: main thread (emulator, as always), window thread (input), and blitting thread (video). This way, we always wait for vsync in a separate thread, leaving the window thread free to process input as it comes, and additionally we can achieve a totally asynchronous -triplebuffer without video artifacts nor any input lag penalty. At least this is the idea. I don't mean this is the best possible implementation, there might be some issues left with the maximizing/minimizing process, but I think that at some point Mame devs should consider to make input and video threads trully independent to improve the emulator experience.

[jimmy2x2x]

Can I apply those fixes now, or do they need to be integrated with the 0143_groovymame.diff?

[Calamity]

Can I apply those fixes now, or do they need to be integrated with the 0143_groovymame.diff?

You can apply them right after the 0143_groovymame.diff (make sure to have applied the hi_linux diff before)

[jimmy2x2x]

ok, tried that with mame compiler 64 v1.22

base 0.143 + hi_143.txt + 0143_hilinux.diff + 0143_groovymame.diff

(all fine)

then

0143_groovymame_fixes.diff

gives this output:

Applying Diff Patch...
can't find file to patch at input line 4
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -Nru b/src/emu/render.c c/src/emu/render.c
|--- b/src/emu/render.c   2011-06-29 20:28:44.000000000 +0200
|+++ c/src/emu/render.c   2011-06-29 20:54:13.000000000 +0200
--------------------------
File to patch:
Skip this patch? [y]
Finished!
0 Hours 0 Minutes and 0 Seconds Elapsed.
Skipping patch.
6 out of 6 hunks ignored
can't find file to patch at input line 116
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -Nru b/src/emu/switchres/switchres.c c/src/emu/switchres/switchres.c
|--- b/src/emu/switchres/switchres.c   2011-06-29 20:28:44.000000000 +0200
|+++ c/src/emu/switchres/switchres.c   2011-06-29 20:45:35.000000000 +0200
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
1 out of 1 hunk ignored
can't find file to patch at input line 144
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -Nru b/src/mame/drivers/galaxian.c c/src/mame/drivers/galaxian.c
|--- b/src/mame/drivers/galaxian.c   2011-05-12 00:50:02.000000000 +0200
|+++ c/src/mame/drivers/galaxian.c   2011-06-29 21:22:30.000000000 +0200
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
3 out of 3 hunks ignored
can't find file to patch at input line 174
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -Nru b/src/mame/includes/galaxian.h c/src/mame/includes/galaxian.h
|--- b/src/mame/includes/galaxian.h   2011-04-27 07:11:20.000000000 +0200
|+++ c/src/mame/includes/galaxian.h   2011-06-29 21:23:38.000000000 +0200
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
1 out of 1 hunk ignored
can't find file to patch at input line 186
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -Nru b/src/osd/windows/switchres.c c/src/osd/windows/switchres.c
|--- b/src/osd/windows/switchres.c   2011-06-29 20:28:45.000000000 +0200
|+++ c/src/osd/windows/switchres.c   2011-06-29 21:02:04.000000000 +0200
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
6 out of 6 hunks ignored
can't find file to patch at input line 253
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff -Nru b/src/osd/windows/window.c c/src/osd/windows/window.c
|--- b/src/osd/windows/window.c   2011-06-29 20:28:45.000000000 +0200
|+++ c/src/osd/windows/window.c   2011-06-29 21:16:27.000000000 +0200
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
19 out of 19 hunks ignored

[Calamity]

Does the (do the) owner (owners) of GroovyMame want a dedicated subforum?

Hi Saint,

Yes, it would be great to have a dedicated subforum for GroovyMame, if you think it's a good idea, and probably move the Switchres thread and this one into there so we have something to start with. Newcomers will find information easier, as now there's a lot of valuable information buried in these threads that's difficult to find when needed even for us.

Thanks,

Calamity

[Calamity]

Yes, it's not finding the files because I made the diffs against my source trees that ares b/src and c/src, so if you remove the b/ and c/ from diff lines it should work.

[jimmy2x2x]

Yes, it's not finding the files because I made the diffs against my source trees that ares b/src and c/src, so if you remove the b/ and c/ from diff lines it should work.

That worked, now compiling

Thanks Calamity

[jimmy2x2x]

all done, looks great so far

I have found a couple of bits, but I will hold off until the new forum is up and running

[Calamity]

all done, looks great so far

I have found a couple of bits, but I will hold off until the new forum is up and running

Great!

I'm travelling abroad for some days so I'll probably be disconnected, will be back next week.

[bitbytebit]

Just uploaded 0143.013 version of groovymame .  I had time to build the patch, binaries and patches are up now.

Calamity, let me know any diffs possibly that you have worked on and I will include those, if you feel they are ready.  I haven't been paying much attention to the threads here but saw mame 0143 came out last night and so have updated the patches for it, but see you've been getting some things improved to fix the frogger issues and possibly others, looks exciting.

ISO's will be up in a day or two most likely.

I've attached the diff file with the fixes I've been doing, this must be applied over after the 0143_groovymame.diff in order to work.
I'm going to sum up the different fixes before I forget about the details. Feel free to add or drop all or part of them:

emu\render.c
------------
- Moved changeres code from "render_target::get_primitives()" to "compute_visible_area", this fixes an issue when minimazing/maximizing the window that invoked many false changeres events that made this process very slow. Also, doing this fixes the aerofgts issue when displayed fullscreen on vertical monitor.
- Removed the frogger/galaxian fix
- TO DO: fix the changeres patch for the case of a vertical game displayed on horizontal monitor which changes resolutions (i.e. aerofgts). The issue here is that after a resolution change the display size obtained by the changeres patch is already rotated, say 240 x 320, but as the stored game info says it's a vertical game, the resolution is rotated again in the modeline generator producing a chopped display.

emu/switchres/switchres.c
-------------------------
- Changed the rotate options from autol, rol, to autoror, ror, as this the usual orientation for rotated monitors, otherwise the display was upside down, however it would be nice to have an option for this eventually.

/mame/drivers/galaxian.c
/mame/includes/galaxian.h
-------------------------
- Patch for galaxian/frogger. I was reluctant to patch anything on the mame part of the source code, but this patch is so simple it seems that mame devs already thought of this possibility. Actually it would be enougth to change the GALAXIAN_XSCALE constant in galaxian.h if it wasn't because some "3" values are hardcoded in galaxian.c.

/osd/windows/switchres.c
------------------------
- Commented out the part where it orders the mode table, as the swap function was not swapping the string labels, corrupting the mode table if the mode list returned by the system is not perfectly ordered already. This one was hard to figure out.
- In the find_best_mode algorithm, now interlaced resolutions are not penalized if we are looking for a virtualized resolution (I added this at some point trying to fix an issue though I'm not sure it's really necessary).

/osd/windows/window.c
-----------------------
- All the changes in this file are experimental for the new blitting thread method, so can be safely discarded, though I've come to a point where it's really stable here, so would be glad if someone wants to test (this patch was already included in the test version some people here have been using).

For a brief explanation: normal mame, when in multithreading mode, uses two processing threads: main thread and window thread. The idea is that the main thread handles the emulator thing, while the window thread deals with input and output (video). Everything is fine with this design unless you decide to vsync. As the vsync functionality is inside the video part this means that waiting for vsync freezes the window thread during instant, locking the window for input, enough to cause a noticeable input lag.

On the other hand normal Groovymame patches partially fix this issue for -syncrefresh by performing the wait in the main thread, but unfortunately -triplebuffer is still done in the window thread to allow for asynchronous blitting, keeping some input lag that's specially bad when native refresh is very different than the achieved one (60Hz vs 53Hz modeline). Additionally, this situation causes visual artifacts as more or less intermittent flashing.

Finally, this new patch uses three different threads: main thread (emulator, as always), window thread (input), and blitting thread (video). This way, we always wait for vsync in a separate thread, leaving the window thread free to process input as it comes, and additionally we can achieve a totally asynchronous -triplebuffer without video artifacts nor any input lag penalty. At least this is the idea. I don't mean this is the best possible implementation, there might be some issues left with the maximizing/minimizing process, but I think that at some point Mame devs should consider to make input and video threads trully independent to improve the emulator experience.

Looks great, I added this into the git and the patch file is updated.  I'm building windows executables now and should be up as version 0143.013a with this changes shortly.  I like the frogger fix, amazing, that's definitely the right way to do it.

[DeLuSioNal29]

Does anyone know what setting I should choose for the Betson 27" Multisync monitor?

Thanks in advance...

D

[DeLuSioNal29]

Games look awesome, however I have found a couple oddities. Most notably, if multithreading is enabled, many games run at break-neck speed; unplayably fast. I'm not sure what the common thread is here, but it spans several different drivers. I'm not too concerned about it, however I find it interesting as multithreading worked fine using a vanilla install of sdlmame.

I am also experiencing this issue.  The game I'm testing all this on it UMK3.  However, I noticed that when you press the tab key to bring up the options, the game returns to normal speed.  Press Tab again and it's breakneck speed again.