It fixes a problem with Acquire call failing on certain systems and causing the config window to close immediately (pretty obscure foreground-only access vs window creation sequence issue). More importantly though there was a crash reported by some users, happening when OK button was pressed. Turns out this would prevent the new configuration from being written to the INI file.
If anyone's interested, this is a piece of code equivalent to the offending one. See if you can spot the problem :)
vector<Box>::iterator i; for (i = boxes.begin (); i != boxes.end (); i++) if (!i->valid) i = boxes.erase (i);
I've been trying to add some preliminary GUI for configuration purposes and I have to say I'm not doing so great. It's really annoying to have to fix various random pieces of code every time I change my mind about how the GUI should look/work. At this point I belive I'd be better off creating an empty project with only the GUI and then merging the thing with Makaron once I'm happy with it. Though actually it'd probably end up the other way around, that is moving emulator internals to the GUI project :)
Anyway, I've also been experimenting with various things including SH4 recompiler. That last idea didn't quite live up to my expectations, I guess I would have to rewrite it whole in order to gain any significant speedups - and I've neither time nor motivation right now.
One of my ideas was to introduce the ability to change dics in the GD drive without having to open the GUI menu. I gave Yuki a modified version where you can choose one of 4 "GD slots" by pressing keys 1 through 4 - at any time really. Kinda neat and for now saves me the trouble of implementing the switch between window and fullscreen mode - though it will be possible in future of course.
So... what do you guys think? GD slots a good idea? It will interfere with the "classic method" a bit (and you need to assign images to slots first) so having both at once might be difficult to do and/or understand. Also, how many slots and how to switch between those? Keep in mind some games require keyboard emulation so it's best to either limit the key usage, or figure out a clever system which would allow to lock the keyboard exclusively for emulation or GUI - and again, how to switch between those modes?
If there are any good ideas for the GUI functionality then I'm all ears. Menu layout, key mappings, stuff like that. I have to say I don't much like how nullDC menu works. It's great if you need to change only one or two options but for anything more you have to constantly revisit the menu bar and navigate from there. I find that all-in-one config window in pSX more... ergonomic? Though it can be a little confusing with so many things in one place.
With a decent GUI there would be no need for the on-screen F12 menu I suppose?
Oh and BTW there is provisional support for save-states now. With all the changes I make it's not stable enough to be used, but this functionality too will require key mappings or something for easy access.
UPDATE: I've only now realised that the last screenshots posted were made in December...
Some people are working on Pandora port, some are trying to get Atomiswave working, and I've been busy with this :)
Once again, great many thanks to Yuki for hunting rare VMUs and special savefiles, and to all those people who helped me out with VMU BIOS dumping (you know who you are). Took me a while :P
VMU-E and VMU-J BIOS:
"Cho Hatsumei Boy Kanipan - Asonde Kid DC DC":
"Zen Nippon Pro Wres - Giant Channel":
"Atsumete Godzilla - Kaiju Dai Shuugou":
"Gamera Dream Battle" and "Mothra Dream Battle":
"Atsumare! GuruGuru Onsen - Chiisana Kotori Uranai":
"Pinta Quest" - Skies of Arcadia minigame:
And there's more where this came from :)