RC4b10 comments

Romcenter 4 support discussion. Please do not post roms requests or illegal links, posts will be deleted. After discussion in this forum, please report any new bugs here.

Moderator: Wanderer

Forum rules
No roms requests or illegal links
User avatar
Wanderer
Board master
Board master
Posts: 791
Joined: Wed Oct 03, 2001 10:37 am
Location: Milky way

RC4b10 comments

Post by Wanderer »

OK, i currently have some free time and also the will to play with RC a little. It seems to me we're up to a point where some cosmetic comments could be made since RC's engine seems to be in a somewhat good state, so i started playing with some TOSEC collections i have, to see how it behaves in that area.

One problem i have noticed here (which i had feared would appeared since RC4's design time) is that it's pretty difficult to handle a large number of dat files. TOSEC for instance has several dats for a single system, with which certain steps must be performed in order for RTC to handle:

1. Each dat has to be converted to a database.
2. At least one rom path must be added to the database.

This repetitive set of tasks must be done manually for a large set of dats (i.e Amiga:49 files, Atari ST: 40 files, C64: 180(!) files) one by one (RC won't at least accept drag-n-drop of multiple dats). Well, for systems like C64, this would simply be torture. It would take several hours to do those two tasks and i don't want to think what will happen when the next update gets released by the TOSEC maintainers.

So far, RC4 seems to play pretty nice with TOSEC dats but IMO when the 4.0 final version is released, a new functionality to help with large number of DATs should be discussed and designed. Since the engine will be sharp and ready, this should mainly be a GUI thing.

What are your thoughts on that Eric? Do you think it would be a nice addition to RC at that point? If so, how could anyone contribute? Discuss about design ideas and let the implementation to you? Help in the implementation perhaps?

User avatar
RomCenter
Author
Author
Posts: 1519
Joined: Fri Sep 28, 2001 12:34 pm
Location: France
Contact:

Re: RC4b10 comments

Post by RomCenter »

It's a good improvment imho. This can make the difference with other rom manager tools.
We could discuss the design and I can do the coding.

First, we need to load all dat at once (drag and drop or multi select).
Then I see two options:
  • One dat per tab
  • All dat merged and one tab
I think the second option would be better. We can also have some kind of different nodes in tree view to identify original dat.
...
Eric - RomCenter developer
Report bugs here.

User avatar
Wanderer
Board master
Board master
Posts: 791
Joined: Wed Oct 03, 2001 10:37 am
Location: Milky way

Re: RC4b10 comments

Post by Wanderer »

Well, here's what i have in mind (anyone else can jump in of course and express any ideas). Please read it all before processing individual parts of it, as some things may be better explained later on. This may require either a separate database (with perhaps a different extension ?) or maybe some significant restructuring of the current one (probably adding things, not altering much the existing ones). My preference would be a new, "superlevel" database, which would just contain info about the multiple databases - one for each datafile.

I'll take as an example the Amstrad CPC TOSEC dats and analyse my idea.

Amstrad CPC - Applications - [BIN] (TOSEC-v2014-10-28_CM).dat
Amstrad CPC - Applications - [DSK] (TOSEC-v2015-05-07_CM).dat
Amstrad CPC - Compilations (TOSEC-v2015-05-07_CM).dat

Excluding the part in the parenthesis (which is actually the TOSEC release), the rest is just a directory structure separated by " - ":

GRAPH(1)
Amstrad CPC
----Applications
--------[BIN]
--------[DSK]
----Compilations

Each actual dat would be in a separate database. When the user adds all three dats from the UI, he would do that in a "superlevel" database which would just contain the names of the three child databases and any other info that may come up in the process (perhaps each database version - the stuff within the parenthesis). The user would have the ability to either open each dat database standalone (as done today) but for easier handling of all of them, he can open the "superlevel" DB which would automatically open the other three.

The UI part now. At the leftmost part of the window (left of the "tabs" area), another tree would be added which would contain what's shown in GRAPH(1) - when the user adds something of course. The names of the folders in the treeview will be taken from the relevant TOSEC dats. The user would be able to define one base path by rightclicking on the system branch (Amstrad CPC). From that, the actual rom paths would be derived for each dat by taking the base path and adding the names of the folders to it. Like this:

GRAPH(2)
Amstrad CPC (an example of the path selected by the user would be: C:\MyData\TOSEC\Amstrad CPC - Plain folder/just organizational)
----Applications (the actual path would be: C:\MyData\TOSEC\Amstrad CPC\Applications - Plain folder/just organizational)
--------[BIN] (the actual path would be: C:\MyData\TOSEC\Amstrad CPC\Applications\[BIN] - Actual ROM path of the respective rdt database file)
--------[DSK] (the actual path would be: C:\MyData\TOSEC\Amstrad CPC\Applications\[DSK] - Actual ROM path of the respective rdt database file)
----Compilations (the actual path would be: C:\MyData\TOSEC\Amstrad CPC\Compilations - Actual ROM path of the respective rdt database file)

The logic behind the setting of the base path is to automatically add a rom path to every new rdt when their databases are created (this could be optional). Doubleclicking on any of the branches marked as "Actual ROM path and also rdt database file" would just open a new tab at the right part of the window, as is now.

An additional idea is for this process (altering the superlevel database - adding, updating or deleting dats and rom paths) to work in an "offline mode". This mode could be a functionality selected by the user (i.e. selecting "offline database modification") on the "superlevel DB". In that mode, the user would add the dat files in the tree, define the base path of each system and add the rom paths in each RDT but while doing that, no actual action will be taken. When he finishes defining everything, he could press an "update databases" button and then all DB creations and rom paths loadings would be made massively. This might require a new window though.

OK, there may be many things i'm missing here but more or less, that's the general idea. I know it's quite some work which might require some restructuring but IMO such an approach would help the user organize things in a way that seems natural and compatible with the dat naming and folder structure TOSEC uses. Perhaps if well designed it will not need much restructuring after all. I've tried to extend the current RC4 UI logic in order to accommodate the multiple DATs logic of TOSEC without making many alterations in the way things work now (which is rather nice).

Closing, please have in mind that the logic of this approach is heavily TOSEC-dependent.

User avatar
RomCenter
Author
Author
Posts: 1519
Joined: Fri Sep 28, 2001 12:34 pm
Location: France
Contact:

Re: RC4b10 comments

Post by RomCenter »

:super:
Let me think about all that...
Eric - RomCenter developer
Report bugs here.

Post Reply