Rom Cache System

[Tillin9]

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]

I don't really think the size should be shown by default, it's not really relevant info is it? I also think user comments / status / issues should somehow be combined.

 

[DarkJezter]

Suggestion for the status, if it's a string describing how accurately emulated the game is, perhaps a number would be a bit easier to manage than a string. (say in % accurate, or playable)

This way, a person could sort their roms by that column in the table...

If we still want to display the value as a string as opposed to a number this can be done by looking up a string in a table (eg 95-100% = Perfect emulation)

Just my 2 hundredths of a dollar

 

[Tillin9]

@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.

 

[Tillin9]

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.

 

[MIO0]

I did some digging around as a result of interest in dockable widgets in the debugger. There are libraries that provide more freeform docking, but they are not included with GTK.

There was a docking widget in libgnomeui which was moved to libbonoboui, and it may move again.

A better choice might be the docking support provided by gdl, which is used by Anjuta. It also contains a data view widget that might be useful for the debugger. Unfortunately, it is very underdocumented. I may download gdl and look at the test apps.

http://www.micahcarrick.com/10-02-2007/gdl-docking-gtk.html

 

[Tillin9]

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.

 

[DarkJezter]

An alternative I've found is the GdlDockBar, which I'll be investigating further.

Frankly, I'm seeing a bit of a convergence here... between the Win32 port issues and the docking issues, I'm seriously considering writing a frontend that is multi-platform from the get-go, which would most likely be based upon Qt, or possibly Kde4. (I know, I know... "oh god, not another windowing API")

I've just committed what should be the last major revision to the debugger branch. I'm really curious as to the patches made by Nmn in the windows port... if they are strictly GUI related, then I think that's all the more reason for us to push for a GUI that is cross-platform with as few os-specific hacks as possible.

At the very least, I think this should be seriously considered before we do begin making any drastic changes to the current GUI.

 

[Tillin9]

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.

 

[Tillin9]

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)