The GAME file tells more than just the simple visual things, it has checksums, information about other data (covers, cheats, etc) and is compressed. Rather than have to worry about 3-5 major compression libraries I only have to worry about one. It also helps with hierarchies of games, I don't want to see 30 versions of the same game that have only a few minor differences for instance, better to group them under one heading and then be able to select the version.
well that does sound interesting, but still, not being able to play games not listed in the database is a huge disapointment.
IMO there should be some generic loader with maybe a warning that the game wasn't found in the database, and it may not play correctly.
Also without some form of database some games simply cannot play, they need to tell the emulator certain things like what is in the cartridge. Some people prefer some custom database to do it, I prefer changing ROMs because it means going forward people can write or release their own games without having to update everyones database.
are you talking about bad dumps or dumps with incorrect headers?
i'm aware theres alot of nes games that have currupt headers. but games that do follow the ines format correctly for example, shouldn't need a database afaik.
(if not then please give some examples)
also most games with corrupt headers are still playable if you follow the 'generally followed rules'.
for example: if byte 15 is NOT zero, then assume bytes 7 to 15 should be zero, and treat the game as if it has save ram.
As for the sega console, i don't have experience with it, but probably a similar situation...
What are your system specs like? Since I don't have any old graphics cards anymore it makes it harder to test on the <2006 circa cards that a lot of people still have.
The only crashes I get are sometimes loading bad NES roms, I haven't handled all the "bad cases" yet on INES loading, apart from that I haven't had a single crash. So I believe it is to do with the more lower range systems. There is still a lot of work to be done to get things tuned up a bit for lower end systems, I have been a bit uncaring about allocating 60+MB of RAM for a rewind buffer on SEGA-E for instance.
PC configuration
AMD X2 4400+ @ 2.921 Ghz
G92 8800 GTS 512mb
4GB DDR2 RAM
its not the highest end pc, but it should be sufficient for this
most of the crashes were from switching between different nes roms after i had one loaded and wanted to change it.
but i also had a crash when i tried to view the credits page.
all the crashes seem to occur while selecting gui stuff, and i think after i have already entered the virtual game room and loaded something.
RetroCopy is really aimed at the future and not at the "single core, 2d accelerated 1GHz PC" market. There are plenty of other emulators which do that stuff fine! So I do want to fix crashes, yes, because I believe even those on poor PCs should be able to get a taste of the future even if it is a bit slow. But I'm not going to go out of my way to make single core CPUs very playable, it's out of my hands to some extent because you can't really have a threaded application on Windows/Linux that also uses 3D stuff without weird "lag" issues coming up (it's a thread priority issue).
well regardless of the hardware speed, stability should be important.
unless your code is using unsupported instruction sets/features, it should still run just as stable on older cpus.
Yeah I agree, we both have a passion about GUIs

. The thing is most people who do emulators don't really want to "waste time" doing a custom interface, I'm not sure why. Back in the day every DOS emulator worth its salt had one, Meka, Nesticle, Callus, ZSnes, Genecyst. These are some of the most remembered emulators. Most games and entertainment applications come with their own distinct interface, emulators are supposed to be entertainment not business apps which sit on the taskbar looking like everything else!
well when you're emulating high-end systems, its not like you have alot of time to focus on the GUI, nor do you want to waste much resources on them.
furthermore the simplistic approach sometimes is alot more effective, since you don't have to 'learn' the application, but instead it has a ui similar to what you are used to.
this is an important strategy in many profession apps designs.
i'm not saying its bad to do otherwise; but instead saying that theres benefits to a simpler gui, just like there may be benefits to a fancier gui.