Wip

General news and announcements. Subscribe to the feed. Image
Post Reply
User avatar
RomCenter
Author
Author
Posts: 1519
Joined: Fri Sep 28, 2001 12:34 pm
Location: France
Contact:

Wip

Post by RomCenter »

Hi

Still working every day on rc4.
I started to optimize database updates while fixing operations.
It was something I would like to do, but later. Unfortunatly, I came across some problems and I decided to do it now.
I reworked the database design and simplify it a bit. Some meaningless info have been removed to improve speed and most queries have been optimized.
Now, I'm updating source code to reflect database changes.
In the current state, with a mame database and more than 100 roms folders, I can rename roms and update display and db in real time !
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: Wip

Post by Wanderer »

Hi Eric.

That's nice to hear. Do you have any statistics to share, like a speed comparison to RC v3.x? Are there any improvements? Is RC4 faster or slower than v3? Is there any room for improvement?

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

Re: Wip

Post by RomCenter »

I don't have a speed comparison yet. I would do it when fix will be fully working. But Rc4 is faster than v3.

The first version won't have much improvments. The goal is to stabilize the version. There will be a new user interface with 3 views, like in the alpha release one year ago.
One thing I added is the possibility to set config and filter games (cps1, 2, 3, neogeo, bad dump, disk...) before importing mame datafile.
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: Wip

Post by Wanderer »

Wow. Nice news. I'm really curious about it.

Will there be simultaneous multiple dat support in the first version?

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

Re: Wip

Post by RomCenter »

Yes, one tab per 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: Wip

Post by Wanderer »

RomCenter wrote:Yes, one tab per dat.
:? Not all of them as branches under a tree?

For instance TOSEC's "Amstrad CPC - Applications - [DSK] (xxxxx)" could appear as Amstrad CPC\Applications\[DSK] tree branches.

Visually it would be more appealing and user friendly (especially if one could eventually move files from one folder to another via drag'n'drop). I'm not sure what problems might occur during implementation though. If you care to discuss it (now or at a later version perhaps), just say the word.

Anyway, not to appear a cry-baby, tabs are certainly better than having to work with a single dat file and have to reload the next one.

How complete is RC4 BTW? are we looking at 50%, 70%, 90%? I'm not asking for an estimated release time. The answer to that is "it will be released when it's ready". ;)

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

Re: Wip

Post by RomCenter »

You can currently load several databases at once and each one is located on a tab you can detach.

A list of available dat in the tree is a good idea, but I have to find a good solution to display databases and datafiles together.
For example, in the current implementation, it is quite simple to display a dat without importing it in a database. Of course, you couldn't add any rom folder in it.

For now, I will publish a first version, and then add more features to it.
It is 70% complete due to the reworking of the database.
Eric - RomCenter developer
Report bugs here.

MELERIX
Street fighter II
Street fighter II
Posts: 53
Joined: Fri Feb 24, 2012 5:57 am
Location: Chile
Contact:

Re: Wip

Post by MELERIX »

thanks for the news!

anyway, I'm wondering if you need more help from others developers ?

because seems you are doing all this work alone and nobody helps you.

maybe is time to move to OpenSource ? Github could be an idea that you may consider in a future.

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

Re: Wip

Post by RomCenter »

It's something a often think about, but maybe I will make a pro version with Advanced features. It would be very cheap, and you would pay only one time to grant access to all updates. In this case, it would be difficult to use github...
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: Wip

Post by Wanderer »

RomCenter wrote:A list of available dat in the tree is a good idea, but I have to find a good solution to display databases and datafiles together.
OK, taking the idea from another program (i believe it was TOSEC's TIM), i'll try to describe below a procedure i have in mind. I'm brainstorming here in an attempt to generate ideas on how to implement everything in a tree, i'm not saying i've thought of everything. The idea is to have one tree structure only, containing a combination of the database and the actual rom folders contents and show each of them in different colors according to whether it is proper, fixable or unfixable (green, yellow or red). Filtering should of course exist, perhaps as is now (separate buttons for rom folders and db items).

1. The user creates a new database, blank at the beginning, he just gives a name.
2. He decides which dats it will contain, so there should be an "import dat" procedure. In that dialog, there could be a "create subfolders from filename" checkbox to define if the dats names are segmented (or "TOSEC-style" compatible). I'm using TOSEC as an example because their dats filenames have specific format (items separated by dashes). In the same dialog, he could define the separator (dash in TOSEC's case, in other dats it could be something else). Each item in the dat filename could be converted to a folder in the tree, for instance "Amstrad CPC - Applications - [DSK] (xxxxx)" could appear as Amstrad CPC\Applications\[DSK] (the (xxxxx) at the end should be discarded), so the database branches would be filled by the dat's filename and the actual files would be shown in the list when the last branch of the tree is selected (i.e. [DSK]).
3. The user could also mass-select dats and add them to the database or update an already existing database structure if a previous version of the dats has already been inserted to it. Branch (name of the db folder) renaming should be possible in case it's needed. Perhaps a "change rom folder loction" should also exist, in order to be able to keep the cached contents of a rom folder in the db and just change its location/name (eliminating the need to close and reopen the rom folder which is time consuming).
4. In order to select the rom folders, the user would be able to right-click on a tree folder and through a menu item (i.e. "Select rom folders"), select the data folders bound to that tree item. The selection dialog could have a "recurse" checkbox so if someone has a rom folder containing a subfolder structure which is the same as TOSEC's naming (name of the tree item should be the same as the name of the folder on the disk), he could select the main folder (i.e. "Amstrad CPC"), define a roms location for it and RC would bind every subfolder of the tree to the appropriate rom folder on disk.
5. In the tree, each item could appear with the normal RC color coding (green, yellow, red, dark grey for unknown files/roms). In the tree, completely missing roms (zips existing in db but not on the rom folder) could appear with a different shade of red or perhaps light grey).

Notes:
- This idea is pretty straight-forward assuming there is a 1-1 relationship between db folders and rom folders. If one wishes to have more than one rom folders then it becomes a little complicated. In order to view a specific branch, perhaps in the rightclick menu of the tree folder, there could be a "open in new tab". Then RC would open a new tab which would display the specific db folder only and its roms folders of course in the same way as RC 3.x currently does. Just the selected db folder, not subfolders (if it has any).
- In every folder of the tree, other items should exist in the rightclick menu (i.e. "fix folder", "reload", refresh" and several others currently existing in RC3.x).
- In the top level only, a "rom bucket" could exist in order for the user to be able to define folders containing roms he does not know where they belong or what their correct name is. Those should be checked against every dat file in the tree (perhaps only manually because i guess it could take quite some time).
- For simplification reasons, this idea assumes that all roms are compressed. I guess an "uncompressed roms" structure of the type "FOLDERNAME\ROM FILES" would be pretty difficult to support together with all of the above, except if there could be a way for the user to define that a selected rom folder is "uncompressed" (its contents are in the form "SUBFOLDER\ROM FILES").
RomCenter wrote:For example, in the current implementation, it is quite simple to display a dat without importing it in a database. Of course, you couldn't add any rom folder in it.
The user could still load the dat, as is currently done. A "Save in database" could be added as a menu option and then the dat could be saved in a new or added in an existing db.

User avatar
SFX Group
Street fighter II
Street fighter II
Posts: 59
Joined: Tue Nov 12, 2002 10:40 am

Re: Wip

Post by SFX Group »

Looking forward to it...
Many Thanks
Ashley

© Copyright 2024

Post Reply