The main thing I would like to see in Gens is the ability to disable FM sound channels. That would be an awesome feature, and I don't think there are any Genesis emulators that do this yet.
You said you would be writing an SH2 core or something. How Gens specific is it going to be, I might just see if I could try to make a C68K + SH2/GS saturn emu, that is when I get even better with C/C++. One question, when making an emu from existing code, is it just setting clockspeeds and the "virtual pinout" of the emulation cores, or is it much more complex?
This is planned for "eventually". This is also planned. It will be part of the audio mixer plugin when I add audio support to MDP. My rewritten CPU emulators will be designed to be independent of Gens/GS. For memory and I/O access, they'll use pagetables, which are essentially structs of various read/write functions and/or memory pointers. (Currently, the emulators have separate memory I/O functions and instruction fetch tables. This would be just fine if the CPUs were Harvard architecture, but they aren't.) Also, the hardest part of Saturn emulation isn't CPU emulation. The hardest part is emulating both VDPs, and neither of them are remotely similar to the MD's VDP.
I like to see: RAM Search & RAM Watch. Memory viewer to view the memory while playing the game instead of going to the Debug menu. Dump - FM YM2612 Registers, Channels, DAC , PWM, PSG, RAM, VRam TLP Format Palette, Z80. Import Dump - FM YM2612 Registers, Channels, DAC , PWM, PSG, RAM, VRam. YM2612 Debuger and PSG Debuger.
That last part, do you mean like a virtual snapshot of the system state. That does seem like a good idea.
I don't know how feasible this is, but I would like to see a Qt4 interface for Gens/GS. GTK+ and KDE don't seem to mix well on my system, and I prefer Qt UIs over GTK+ ones overall, no matter what DE I am using.
I have a few suggestions: 1.) Add OpenGL support to the Win32 version of Gens/GS: OpenGL headers and such are out there for Win32, why not port the Gens/GS OpenGL renderer over? 2.) Mac OS X port: Before people gripe about Gens (and Gens/GS) utilizing x86 assembly as well as C/C++, Apple has discontinued all support for the PowerPC platform since the release of Mac OS X 10.6 Snow Leopard. And since X is usually available (either from the install disc or downloaded from XQuartz), it should (in theory) be portable over to OSX. 3.) Support for more compression formats for ROM images: .7z/LZMA comes to mind, any others would be even nicer. 4.) UPX-compression for the executable (and any applicable plugins): Granted it means Gens/GS would need to load into memory in its entirety, but for PCs made in the last 8-10 years, loading everything into memory isn't a big issue unless one is also running memory-intensive applications such as AutoCAD, making this a storage v. convenience issue. 5.) Boss Key: A customizeable key combo that when pressed, hides the window, from appearing even on the taskbar (press again to make Gens/GS reappear)
Somebody is already making one iirc. Also, once c68k gets implemented, at least the Genesis and Sega CD parts will be portable right? Just get some kind of desktop manager with multiple desktops, taskbar's are isolated to each one. Thats how linux is anyways =P
I definitely agree with 1, 3, and 5. Number 4 is somewhat of a problem, since many, many antivirus applications automatically believe it to be a virus and wipe it out, so I don't think that would be smart. If a Qt interface was written, then we would probably easily have the Mac OS X port, since Qt 4.5 and higher can target Cocoa instead of Carbon quite easily, without using any Obj-C code. Older versions of Qt4 would target Carbon though. Cocoa is supported in PPC and Intel on Leopard with Qt 4.5.x. I think Qt 4.6 drops PowerPC support though.
This stuff is all planned for a future debugging plugin. I'm planning on eventually completely abstracting the UI from the base emulator code, so a Qt UI will be possible. 1. This will be done eventually. 2. Considering the way Apple has been treating its developers recently, I don't think I'll be porting anything to OS X anytime soon. I will, however, be working on getting Gens/GS on PowerPC Linux for Release 8, once I port the Z80 and 68K emulators to C. 3. 7z has been supported for a while. 4. UPX causes issues with antivirus scanners as well as NX support. 5. Use a virtual desktop manager. That way, you can have a "boss key" set up for everything, not just Gens/GS. (Also, you probably shouldn't be playing video games at work, anyway. :P)
I don't know if this has been mentioned but saving screenshots in a format that preserves the correct pallete information rather than full colour images. That'd be a huge help and its the one let down I've alway felt gens had over Genecyst. (which I'd still use for that purpose but it wont run on my pc)
The only problem with this is that it doesn't work correctly for raster effects, I.e. games that change the palette mid-frame. In particular, the Sonic series does this for water levels.
Pity, most of my work back in the old days when dos emulators were at large was dumping several screenshots, editing the pallete directly in paint shop pro and once I got a result I liked I wrote it directly into the rom, I only used hacking utils for touch ups and quick fixes once id implemented the basic palete idea I liked. Its such a... pain... to resort to utilities cos my prefered emulator don't do everything id like, especially to aid with pallete editing. Ahhh, back in the old days....*drifts off into a daydream* LOL. Its ok, I figured I'd put my 2 cents in for a shot of luck.
On the other hand, there *is* the in-progress VDP debugging plugin, which, among other things, will let you modify the palette in-game. I'm not sure how it'll handle locking the palette right now, but this is all planned. (The VDP plugin is currently on hold while I'm reworking everything into Gens/GS II.)
Im assuming such a method would work in hexadecimal values and that it would be simmelar to editing the pallete in a savestate (remains untill refreshed) if so your a god! I never thought the idea of testing palletes in the emulator... in real time would be possible. Awsome! Ya see im working on a big pallete project, a quick and easy site to download masses of patches for every single (or at least most ) genesis sonic titles, in cluding pallete themes that spread accross multiple zones and game titles. So when dealing with one rom hack palletes arn't too much of a problem but when dealing with potentially dozens per zone accross 5 games it get irritating to switch between emulator to utility too often... im a perfectionist! LOL.
EDIT: Sorry, this post was a bit crappy, allow me to add in some context: As far as future features for Gens/GS, I'd like to see a sound utility of some sort. YM2612 debugger that can view voice data and do dumps of voices and whatever else is reasonable. Allow dumping of voices into VOPM format and I'll give you extra credit.
