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.