Far out! This is nuts! Just about to walk out the door but I'm looking forward to returning to this... Well done!
I had thought that porting the Groovy patches to MESS would involve some work but the amazing thing is that the *exact same patch* did the job. Actually the only slightly complicated thing was figuring out how to invoke the games using my existing roms.
Here, etabeta provides some hints on properly using software lists and clrmame to simplify the loading command:
http://mamedev.emulab.it/haze/2012/05/15/ume-is-go/comment-page-1/#comment-21556I must admit that the MAME / native resolutions stuff had captured my attention for the last two years and I had somewhat abandoned any other platform specific emulator, in part due to the pain of setting video up in the old fashion.
Those of you who have used the VMMaker stuff know that we need a separate list of video modes as input for the modeline generator (ReslList.txt) so we can support systems not included in MAME. These video modes are considered as 'static'. This means, in the most obvious case, that you need to create separate modelines for PAL/NTSC games. Some emulators don't allow you to specify the refresh rate to pick, for instance Kega Fusion. The only way to force Kega Fusion to run PAL games at 50 Hz is to create an unique modeline for the target resolution, say 320x240 at 50 Hz. If you happen to have another modeline for 320x240@60 present in the system (you'll have it for sure) chances are that Kega Fusion will pick this one and not the other so it'll run at the NTSC speed instead (I know NTSC is actually the *right* refresh for Megadrive stuff).
Another emulator with this problem is WinX68kHighSpeed, for the Sharp X-68000 (
http://postback.geedorah.com/foros/viewtopic.php?id=1425). The X-68000 video modes run at 55.45 Hz. You can easily define these modes with VMMaker, but you need to create an special mode table for this system alone, otherwise the emulator will pick whatever video mode with the same resolution that the o.s. reports first. This involves running VMMaker and restarting the system each time you want to enable the right video modes for this system.
Actually the Switchres program would have helped with the above problems to some extent, at least that was the idea.
But it's even worse than that: unlike MAME*, most emulators expect the exact resolution to be used, otherwise they'll stretch things. So we can't usually round vertical resolutions to reduce the mode list, as we do for MAME (i.e. 224--->240). This adds a lot of redundancy to the mode list, and we soon run out of space (remind we can only store up to 120 modes).
*only true for DirectDraw
The point I want to reach is that from this perspective, the possibility of emulating every system with a single video core is a godsend. For instance, PAL/NTSC modes will be generated automatically just by selecting either the 'megadriv' or the 'genesis' system. You don't need to care about that anymore. But it's even better: many systems do change resolutions while in the game, and this has been usually impossible to achieve with existing emulators. The GroovyMAME patch already supported this functionality for arcade games so it just works out of the box for systems like SNES.
Today v0.146 is out and the UME target is now officially included. I'm thinking of moving the development over the MESS source base and making GroovyUME the main build. Compiling times will substantially increase, but not so much. It's actually a bigger executable, but its a matter of a 17 vs 22 MB .rar download. I'd like to hear your thoughts.