The NEW Build Your Own Arcade Controls
Software Support => GroovyMAME => Topic started by: dabone on May 22, 2011, 08:26:12 am
-
I'm trying to compile groovymame myself and I'm running into a problem.
I've grabbed the latest build enviroment from mame dev, and can compile 142 just fine, but when I try to patch the source with the groovy diffs its failing.
Here are the instructions.
Patches: (apply in this order)
1) 0142_hi.diff http://mamestuff.lowtrucks.net/MKChamp/hi_142.txt (http://mamestuff.lowtrucks.net/MKChamp/hi_142.txt)
- MKChamp hiscore patch
2) 0142_hilinux.diff
- Linux hiscore patch fixes
3) 0142_groovymame.diff
- Groovy Mame additional features/modeline switching and other features from Cabmame
So, I apply the first patch by having the diff files in my source root directory.
patch -p0 -E <0142_hi.diff
The first patch applies fine.
When I try the second I get the error.
patching file src/emu/emuopts.c
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.
So my question is has the original diff file changed, or and I using the wrong source.(142 no U, just straight 142).
I'm trying to roll my own to enable nonags.
Later,
dabone
-
I'm running into the same problem when trying to patch .143 with the groovymame patch. Did this ever get resolved?
(http://forum.arcadecontrols.com/index.php?action=dlattach;topic=111930.0;attach=168941;image)
(http://forum.arcadecontrols.com/index.php?action=dlattach;topic=111930.0;attach=168943;image)
D
-
You need to apply this particular patch with HeadKazes mamecompiler v1.22
http://www.headsoft.com.au/index.php?category=mame&page=mc64 (http://www.headsoft.com.au/index.php?category=mame&page=mc64)
However this version of the compiler is NOT compatable with 0.142
so you need the correct compiler for 0.142
mingw-mame-20100102.exe (0.136u1 - 0.142u3) http://www.mameworld.info/misc/mingw-mame-20100102.exe (http://www.mameworld.info/misc/mingw-mame-20100102.exe)
and then compile from the command line in the usual way.
OR
you can grab the 0.143 source + patches which will compile via command line or using headkazes mame compiler.
base mame 0.143
hiscore patch 0.143
hilinux 0.143
groovymame 0.143
then this one http://forum.arcadecontrols.com/index.php?action=dlattach;topic=110905.0;attach=168860 (http://forum.arcadecontrols.com/index.php?action=dlattach;topic=110905.0;attach=168860)
-
A couple notes to add to this:
- I am compiling from the command line.
- I tried renaming the 0143_groovymame.diff file to comply with the 8 character limit of DOS. I renamed it to gm143.diff and it still fails. I figured I'd give it a shot.
- I tried compiling with Headkaze's Mame compiler v1.22 and it patched just fine...
D
-
this particular patch has problems with carriage return and line feed characters, headkazes patches it fine, command line wont.
-
One last question... What exactly does "0143_groovymame_fixes.diff" do?
Can't I just run the hiscore diff and then the groovymame diff? What's the purpose of the last one?
D
-
Lots of things, notably fixes games and screen rotation - this is the most current build.
from Calamity:
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.
-
I've included Calamities patch in version 0139.013a patches and source/builds, so no longer need to apply that patch (since it will reject it because it's already applied).