Rom Cache System

Since IRC has been pretty dead, I'd thought I'd bring this to the forum. Here's a peak at what I've been up to in the RCS branch (besides tracking down memory leaks ):

Here's my idea of what info. the rom browser should have with (D) standing for default, and (O) standing for optional.

What we already have:
Country (D) (moved flag into this column)
GoodName (D)
Size (D)
User Comments (D)
File Name (D)

New ROM compatibility database (added to mupenini):
Status (D) - A short string, like Won't Load, Buggy, Good, Excellent, Perfect to describe how well we handle a particular ROM.
Issues (O) - A longer string to describe any known issues and suggest graphics plugin.

Useful for cheats / general ROM ID:
MD5 Hash (O)
CRC1 (O)
CRC2 (O)

Rice's Hi-Res Textures make use of this:
Internal Name (O)

Misc:
Compression Type (O)
Image Type (O)
CIC Chip (O)

If we want any other info. visable, it would be best to discuss this now. I currently implemented a pop-up menu on the rombrowser header where these fields can be turned on or off. Possibly there might also be options inside the configuration dialogue.

@Slougi:
The user comments are for the user. These are for things like keeping track of which games are played, game preference, game progress, etc. The Status / issues are for us to document known issues. I don't think we should combine those two categories. As far as moving size to optional, I don't mind.

@DarkJezter
Having a percent is just screaming for flame wars over how well a ROM is supported, especially if it plays different on different systems. The idea for broad categories is partly to prevent this. The sorting function can be set to sort by how well supported for Status rather than a strcmp, so we get the desired sorting effect.

Also... two other categories I thought might be useful for the future:

Rumble (O)
Players (O)

Finally... is there any semi-official documentation on ROM country codes? With a full GoodName set, some country codes are missing (one of the Australias and three Europes) and some clearly marked U and J games are classified as unknown.

Slougi and I had a discussion on IRC, suggesting a 0-5 star status and moving any known issues to a web based wiki.

Something like this (I didn't actually start classifying ROMs):


Also, what's the opinion on the GtkHandleBoxes for the toolbar? I don't think Gtk has a Qt-like dockable toolbar (which is what I really want), but I'm not a Gtk expert, so maybe there's something out there I don't know about.

Finally... this is with the Issue 93 fix using my KDE3 Gnome icon theme override.

I took a look at Anjuta and its dockable widgets behave exactly like Qt dockable widgets and work well with the Gtk-qt theme engine. This is great for the debugger and rombrowser, but still not good for the toolbar / filter.

Anjuta's toolbars seem to be using just GtkHandleBoxes (with some extra code to allow for smarter rearrangement) but that makes them look rather poor with the Gtk-qt theme engine. This makes me think that a proper solution doesn't exist, and the best thing to do for now is just make them locked with a viewable option in the upcoming View menu.

The Windows port issues are not primarily GUI related (I actually just posted what I believed the issues were in that thread), though there is some concern there. Gtk is sufficiently cross-platform as GIMP runs under Windows and Gtk can be compiled with MSVC, though as usual the documentation to do so is sadly lacking.

I'm all for advancing the KDE4 / Qt GUI to the point were we can consider using that for the Windows port. While I seem to have spent a good deal of time working on the Gtk GUI myself, I'm no Gtk expert, I was actually taught on KDE3 / Qt3.

After the RCS is finished and a few other issues are tackled (mainly 7zip support) I plan on spending some time working on the KDE4 GUI. Slougi let me know of a few code issues I can address, and of course I'd want to add similar RCS integration as I am to the Gtk GUI.

Okay... RCS is nearly done. It probably can be merged to trunk as-is, but I want to make the front-end / back-end interactions a little nicer.

Here's a teaser, hopefully good enough that some other people will download the branches/r0402-rom-cache code from svn and try it out.



I would love some help getting all the ROMs in the .ini to the level of completion that the (V1.0) OOT example is. The fields that aren't extracted from the ROM itself are:

Status
SaveType
Players
and
Rumble

Checkout the code (romcache.c or Issue 65 for info. on how to help flush out the .ini)