-> Participate in Romcenter version 4 design!

[Wanderer]

It's always interesting to see someone in the community making an effort to create something nice and useful. I just visited TOSEC's site and through that i visited RomVault. It seems there's a guy who is trying to create a ROM manager as a replacement for the old TOSEC's TIM. Here's an image of how the ROM manager is looking so far.

Having seen that, i realized that even though this ROM manager is still in an early stage and romcenter is much better than it, there's a crucial element that TIM had, romvault has it too but it's missing from Romcenter. A way to manage a global set of emulator's roms.

Currently, RC has a database for a specific datafile which corresponds to a specific emulator so in order to manage several emulators' roms, one has to continuously load and unload databases. TIM's implementation (or at least what they meant to create) was pretty nice. I wish we could have something similar to romcenter too. It seems that RC3 is a much more stable and better-designed release than RC2 with more potential so making such an addition would create a very organized and solid all-in-one ROM manager.

Being a programmer myself, i could perhaps throw some ideas on how to design such a thing and i'm pretty sure there will be others interested in discussing and eventually seeing such a thing in RC.

So, Eric, what do you think? Would you be interested in discussing the matter and perhaps design such a solution? IMO, it could very well lead to RC4. Perhaps it could also be a team job, if you agree and others are interested on the matter.

[RomCenter]

Hi Wanderer
First, thank you for pointing this new software.

I have downloaded it and I will give it a try this week.
I agree with you that team development is a good thing, but I think we're far from it. First, rc is still coded with delphi, and this language is less used than before, so it will be hard to find coders.
I have in mind to migrate to visual studio c#, as it is the editor I currently use at work. So I have to move to vs, and then to c#.

So, shall I enhance the current romcenter to quickly have a full featured software, or start the migration and then add new features (with a team)?

Anyway, we can start thinking of how to implement this new feature. About the database, we have two choices: one big db with all systems, or one db per system. First solution is easier, second is faster. We can probably design the big db so that rc only have to update parts of datas, but it will still be slower.

The gui is another thing to take care. If you have ideas, go on ! The gui will show 100000+ files in a treeview. The treeview must be loaded from the db, and then kept up-to-date during operations.
Current delphi version use a virtual treeview. Visual studio doesn't have a similar component (no so compleat as delphi).

[Wanderer]

I have in mind to migrate to visual studio c#, as it is the editor I currently use at work. So I have to move to vs, and then to c#.

So, shall I enhance the current romcenter to quickly have a full featured software, or start the migration and then add new features (with a team)?

Hmmm, what to do. Tough choice.

IMO, the first thing you should do is to see if there's any real interest from others in helping with the development. The good thing with VS is that you can recruit developers that write in different languages because VS can compile items from the various supported languages to one EXE (at least it is supposed to do that). In any case, i believe that since RC has reached a pretty good and stable point, an addition like the one i propose (which looks like a major one) might be better to be added in an all-new version. If a devel team can be assembled, you certainly have the experience to guide it, help in design and development and perhaps in parallel make minor adjustments to the existing RC version in order to have a working tool, compatible with the latest emulator versions, until the new version can be released.

IMO, another thing to keep in mind if you decide to move to VS it to keep compatibility to a MONO-supported level (currently .NET 2.0), if possible. That way, we may finally see the first rom-manager natively supported by Linux.

If you believe a worthy enough team cannot be assembled at the moment (competent and determined to contribute to the task ahead), then it will be up to you to decide what to do.

In any case, if this turns to be a team-job then it will certainly be a long-term one.

Anyway, we can start thinking of how to implement this new feature. About the database, we have two choices: one big db with all systems, or one db per system. First solution is easier, second is faster. We can probably design the big db so that rc only have to update parts of datas, but it will still be slower.

I don't know, perhaps several small dbs might be better. After all, many users will not be interested in support for all emulators. Also, emulator versioning might be of interest to some users (i.e. having several DBs, one for each mame version) so IMO, the design could be like this: a master DB and one DB per emulator or emulator version. The master DB would contain some common things like user settings and would also be a connection point for the other DBs. That way may be easier to support special needs in specific emulators by adding extra fields in tables of the specific emulator DB.

The gui is another thing to take care. If you have ideas, go on ! The gui will show 100000+ files in a treeview. The treeview must be loaded from the db, and then kept up-to-date during operations.
Current delphi version use a virtual treeview. Visual studio doesn't have a similar component (no so compleat as delphi).

I don't believe it's necessary for all leaves of the treeview to be loaded at once. When an emulator (or version) is clicked to be expanded, its actual contents could be loaded from DB at that moment. If another emulator is already loaded and shown, it's contents could be unloaded, its branch collapsed and the new emulator's contents could be loaded and expanded (the first level only).

[RomCenter]

The gui is the big part of the vs migration, and mostly the treeview/listview.
I can in a first time try to move to vs using delphi prism, wich is a pascal implementation in vs editor. And then making additions in c#...
Before that, I want to be sure how to design the display and I have to take into account the new features which could impact it, such as categories and multi-dat.

My idea was to include categories (using mamecat for example) at the same level as dats to allow users to affect a dat or a category to a folder...
I have to do a clean design for that...

[Wanderer]

As i said before, RC3 has reached a pretty mature point and it's a great and working tool. The idea i propose is mostly a change in GUI and not in the core rom-management part so if you really want to move to VS (which seems like the proper thing to do IMO), perhaps it would be better if the existing RC version was somehow transferred to VS and then start implementing changes.

IMO though, there are some fundamental questions that need to be answered before proceeding and you must give the answers because RC is your child.

1. Do you wish to go on alone or try to assemble a team?

2. If you wish to try going on with a team, do you wish to...
-> a. have a design-only team (have help in design but do the implementation by yourself)
-> b. have an implementation-only team (do the design yourself but let others be involved in the implementation)
-> c. hear other people's ideas but at the end design and implement it yourself.
-> d. do both design and implementation with a team.
In plain words, what do you want your role to be in this new version?

3. Some of the above options may mean starting an opensource project (mostly opts 2 and 4). Do you wish to go that way?

4. If an implementation team is involved and you choose to move to VS, should the implementation be done in one language only or take advantage of VS's multiple programming language support?

I think these clarifications are essential so that other people know how they can contribute to this new RC version.

[RomCenter]

It is hard to decide what to do. Going with a team requires a lot of administrative work (took on my rc project time). And you know that sometime I don't have much...

I started to get info on how to implement various part of romcenter in vs (namely treeview, listview (or datagridview ?), localization, zip, database, linux compatibility).
I also started a gui prototype.
I think the first part where I can get help is the gui. If someone has ideas, or even can makes prototypes under vs, it will be welcome. The goal is to have something similar to current romcenter, but with some new features (I added a third listview for roms for example). Of course, keep in mind that it has to be mono-compatible.

About the core design, I think it will be really hard for someone to re-design the object model from scratch. I already did the work two times, and I know exactly the design approach. So I prefer to go for it myself.

Of course, if someone has ideas about some features, it's the time to speak.

Once the vs version will be ready, I could eventually release the source code for improvment and code fixing help.

About the language, the better will be all in c#. But it is possible in a first time that some part of the code remains in pascal delphi (prism), to speed up the migration. I don't want to read c++, vb, c# and pascal in the same project...

To summarize, if you want to help, build a gui prototype of how you want romcenter to be and post an exe. It doesn't have to be dynamic, simply put components on a form and add items, menus, icons, pictures ...

[Wanderer]

About the core design, I think it will be really hard for someone to re-design the object model from scratch. I already did the work two times, and I know exactly the design approach. So I prefer to go for it myself.

...

About the language, the better will be all in c#. But it is possible in a first time that some part of the code remains in pascal delphi (prism), to speed up the migration. I don't want to read c++, vb, c# and pascal in the same project...

First of all, i agree with you about the core design. There is no sense on letting anyone else mess with this part and after all, you've done a pretty good job with it in RC3 so... case closed.

About the GUI, RC's GUI is already pretty nice but what i'm thinking is that what looks "nice" to someone may look "not-so-nice" to someone else. I'm wondering if somehow the core can be separated from the GUI (i.e. placed in a DLL or something) so that one can build his own GUI if he wishes to do so. That may also be one way to create a more active community, with ideas not only for RC's GUI but for addons too.

RC3 is currently like IE. Does the job but doesn't have any fancy features. On the other hand, Firefox also does the job with it's Gecko engine, has a relatively simple GUI but its great power is the addons. You can literally transform it to anything you wish. It would be nice if RC4 could be made expandable like Firefox. This way there is no need for "project management" too and you get the benefit of having several people feel like contributing to RC. I'm not talking about addons messing with the core engine here but perhaps with the GUI only (in the beginning at least).

As for RC's GUI, i'll try to make a prototype of how i imagine it but for now i wish to make one observation about something i don't like in RC for quite some time (since RC2 in fact): RC3 has mixed the concepts of "Program Settings" and "Database Properties" in one dialog. "Preferences" menu item does not get enabled until you load a database. So, why do you have to load a database in order to configure "auto detect devices insertion" or "check for updates on startup"? IMO, there should be a "Program Settings" menu item (with a corresponding dialog) containing common program settings and a separate "Database Properties" dialog containing database-specific settings.

[RomCenter]

I agree with you on the add-on concept. I have it in mind since the beginning of rc. That's why I did the signature plugin.
Addons is a little bit complex and I don't know how to do that . Maybe if someone has knowledge on that, he can contact me. I mean, how to design the source to make it add-ons aware. I know for example mediamonkey can be enhanced with vb scripts.
Also, which kind of add-on can we add to romcenter ?

About the gui, the new one will be independent (following mvc design). Maybe with xaml we can also make it customizable (I never used xaml as it apears in framework 3 and vs2008, does it work with mono ?). The core could be in a dll, why not.

Program settings. This is one part I will re-design. The current one is almost full, and I will design it like modern settings with two panels (like word 2010). Or maybe like firefox settings...
And thank you for your good remarq.

PS: Maybe you could rename this thread with something like 'Romcenter version 4 help needed', or something like that, and put it as sticky ?

[Wanderer]

Also, which kind of add-on can we add to romcenter ?

i'm not sure either but i bet if a developer community is established, others will find some things to add.

Addons is a little bit complex and I don't know how to do that.

How about peeking into Firefox sources for some ideas?

(I never used xaml as it apears in framework 3 and vs2008, does it work with mono ?)

Don't know about that, sorry. I'm guessing though that since mono is currently supposed to be .NET 2.0 compatible, it may not work. We'll have to check the mono site for that.

Program settings. This is one part I will re-design.

Great to hear that. It needs some refreshing.

Maybe you could rename this thread with something like 'Romcenter version 4 help needed', or something like that, and put it as sticky ?

Nice idea. I changed the name. Perhaps a new "Romcenter 4" forum should be created and maybe in the future when RC4 gets active, both RC and RC4 forums can be merged. This post could be the first one in the forum.

[RomCenter]

Xaml is part of the wpf, and is not implemented in mono.
So we are sticked to winforms.

[RomCenter]

I spoke with a friend about mono development, and it is not that simple. You have to take care of a lot of things in the code, you can't use some assemblies... The best is to develop under mono and then move to .net. The problem is that the interface won't be a windows style interface.

Also, winforms is almost dead, replaced by wpf which is much much better and offer a lot of possibilities. On the linux and mac side, GTK seems to be the way to go.
I think the better solution is to have an up-to-date windows version (wpf/xaml framework 3-4) and then find someone to maintain a GTK port. It could maybe just be an new gui sharing the same data model/controller (a gtk# version is available in c#).

So, the first steps will be:
- Design the new wpf interface
- Bind the database items to the interface
- Migrate the rc engine (with prism and/or c#)

For now, the gui design is the hardest part cause I don't know anything about wpf, and it is not like winforms at all . If someone used to build such interface with a treeview/listview and a database, he can contact me.
I already found some books and some code sample on the net.

[Wanderer]

Well, from what you're saying, it seems your main concern is the GUI.

IMO, there are two things to check out. The first would be to see if the core RC engine can be translated to c# and can be successfully compiled under mono without any changes (or at least with minor changes only). The second would be to see if the databases can be shared between linux and windows and work in both OSs without changes. If those two conditions are met then you or someone else can create a separate GUI for linux (if possible) and everybody should be happy.

What do you think?

[RomCenter]

If my main concern is the gui, it's because it is the critical part of the migration. Database is available for linux and will run with no changes, engine can be translated to c# and compiled for linux (with some changes).
But a common mono gui won't be ready for current os like seven and I think a modern gui is a big part of rc success.
The same apply for linux. A gui designed for linux and using linux features will be far better than a common windows-linux gui.
I think the gui with datas bindings is half of the work.

Note that there are also other points to take care like localization, plugins or zip libraries.

[Wanderer]

Database is available for linux and will run with no changes, engine can be translated to c# and compiled for linux (with some changes).

Nice to hear. So it seems relatively easy to maintain a .net-mono compatibility up to this point.

and I think a modern gui is a big part of rc success.

I fully agree here.

The same apply for linux. A gui designed for linux and using linux features will be far better than a common windows-linux gui.
I think the gui with datas bindings is half of the work.

OK then. So as i said before, if you can successfully migrate rc core to c# and maintain .NET and mono compatibility at the same time, then the linux gui can be some other guy's project if you do not wish/can't get involved. You'd only have to provide documentation for the API so someone can "communicate" with the core.

Note that there are also other points to take care like localization, plugins or zip libraries.

IMO, for this part, two different sets of localization and zip dlls should be created (one for windows and one for linux), but both having the same set of external interfaces (objects/properties/methods/events). That way the RC code could use them instead of having specific windows/linux code inside it. Perhaps all the OS-specific parts in the code should be transferred to external dlls. This might also make it more easy to transfer to other OS's in the future.

[RomCenter]

I started the wpf gui...
I have to start from scratch as it is radically different than win32 api.
Right now, it has treeview, datagrid, log memo and a brand new ribbon control. I'm fighting with the bindings to make all this work together.

I will publish an interface concept if possible.

[Wanderer]

I started the wpf gui...

Great news.

I will publish an interface concept if possible.

It would be very nice if you can do it.

[RomCenter]

I'm back from vacations. I tried to post a version 3 weeks ago before leaving, but an unexpected bug prevent me from posting. It is not solved yet.
I think I will fix remaining bugs for an ultimate 3.5x version before sticking to the 4.00.

[Wanderer]

I'm back from vacations. I tried to post a version 3 weeks ago before leaving, but an unexpected bug prevent me from posting. It is not solved yet.
I think I will fix remaining bugs for an ultimate 3.5x version before sticking to the 4.00.

Hi Eric, welcome back.

Great news. In what state do you consider the new version to be? Alpha, Beta? Is it working at all or it's just some screens?

[RomCenter]

Only the gui is in alpha stage. I can load a database and display its content. There are nothing else, no preferences, no tools, no fix.
I will post a wip as soon as possible.

[Wanderer]

Hi Eric

In your first post, you wrote:

Anyway, we can start thinking of how to implement this new feature. About the database, we have two choices: one big db with all systems, or one db per system. First solution is easier, second is faster. We can probably design the big db so that rc only have to update parts of datas, but it will still be slower

Have you decided what to do yet? It seems to me that one DB per system might be a better way to go, with perhaps a central DB containing info on what DBs to load.

My idea: In a way similar to adding rompaths to an existing DB, you could also create a Main DB in which you could add sub-DBs for each system. So, you could have something like this:

My Main DB1
--> SubDB1 (Mame 0.140)
--> SubDB2 (Mame 0.139) <- Two different mame versions in the same Main DB. I wonder if it's possible and what problems might arise.
--> SubDB3 (RAINE v0.51.0)

My Main DB2
--> SubDB1 (Mame 0.140)
--> SubDB2 (SEGA Model 2 Emulator v0.9)

So, you could load only one Main DB per time but you could add multiple subDBs in it, and each subDB could have multiple rom paths associated with it.

Any progress on v4 so far?

[derebo]

Hello there,

I just read the thread after kindly being forwarded to it by Wanderer from my post "search MULTIPLE databases at once-find game in dif platforms" at
http://forum.romcenter.com/viewtopic.php?f=2&t=2132. My viewpoint is end-user and I'm not into coding but I could help betatest. BTW, I also did the TOSEC, RV tour

there's a crucial element that TIM had, romvault has it too but it's missing from Romcenter. A way to manage a global set of emulator's roms.

Bingo! IMO, it'd be a huge step if RC could load multiple databases and allow running a search in all databases at once. The search box should be used recurrently, I think that's the term.

so in order to manage several emulators' roms, one has to continuously load and unload databases

Yeah, I realised about that, so that's why I wrote my post.

Current delphi version use a virtual treeview. Visual studio doesn't have a similar component (no so compleat as delphi).

My opinion: stick to delphi then, virtual treeview is much helpful. But you're the coders so you rule.

After all, many users will not be interested in support for all emulators.

Well, don't be so sure! I should disagree Game researchers love tracing all instances of a particular videogame in different platforms! I'm a game researcher so... I won't write in this technical topic but I'll keep an eye on it

Greetings,

[Wanderer]

but I could help betatest.

That would be great. Thanks for offering to help.

[RomCenter]

Yes, everyone is welcome to help test or code.

The wpf gui is quite good now and I manage to solve many problems (wpf was totally new for me). I'm working now on a working preview and it will be released very soon (don't expect to much..., it is just a gui preview so that you can see what' going on).

It can actually load a database, display files, roms, games and various flags, and you can browse and... that's all.
If some of you have knowledge in wpf, the're welcome to improve the interface.

[RomCenter]

One more thing, Keep posting ideas and improvments. They will be taken into account during the core structure design, even if they're not developed now.

[RomCenter]

About multiple db, If the only need is to do a search among xml/rdb files, I could simply add a new node with all dat, and using the search box on this node could filter the games.
It will not be possible to fix all games in all dat in one click. I need to convert a dat in a db file to query games and keep track of what has been fixed or not.
Maybe I could append a dat to an existing db, and add a sub node for this dat (Wanderer subdb), but keep in mind that a full mame db is already 100MB, and the biggest, the slowest.

Another solution would be to load several db at a time, and switch between them when needed (fix or display for example). Of course, each db will act as an independant database, and belong to a stand-alone node in the tree.

But then, is it really needed to implement that ? You can already go to file/open and switch to another db... If it's too long or too complicated, I could add a database combobox to allow fast switching (like in old romcenter).

[derebo]

Hello,

I said I wouldn't write but the topic isn't too techie so I can say something

About multiple db, If the only need is to do a search among xml/rdb files, I could simply add a new node with all dat, and using the search box on this node could filter the games.

Fantastic! If you can achieve that, that'd be of much help already. I understand all db's would not be displayed in treeview but the search could be run against all available db's, right? If it's so, then it's ok.

Another solution would be to load several db at a time, and switch between them when needed (fix or display for example). Of course, each db will act as an independant database, and belong to a stand-alone node in the tree.

That'd be optimal! Treeview and mutiple db search.

But then, is it really needed to implement that ?

Well, I do think so. As far as I've seen rom managers are rather limited concerning searches. Either no search is possible (RomVault) or only one database can be searched at a time (Offlinelist). Developing this feature would definitely make RomCenter stand out from the rest. And not only that, take into account many may think of RomCenter as a MAME manager. With MAME it's all in one pack so it's just one db. However, usually that's not the case. Take Apple system for instance, there's many db's one per each system. Same applies to Atari, Commodore, ETL, Luxor and many many more systems. And even with each system there are databases (dats) for each category (usually file-extension based). I think we should forget about db's being monolithic one-file databases (eg. MAME) and broaden the scope to embrace systems whose databases are stored in different dats (think of TOSEC as a matter of fact) Not only would RomCenter benefit from being top of the tops but it would also gather new users from those different systems.

You can already go to file/open and switch to another db... If it's too long or too complicated, I could add a database combobox to allow fast switching (like in old romcenter)

Not really. I've done that combobox way too many times in Offlinelist and let me tell you, when you have to check say two databases, it's ok. But when you want to check say Commodore database you actually have to check 172 different dats! That'd be way too much.

BTW, I have one more suggestion: SHA1 hashing. It's being implemented more and more in the 8-bit scene at least. It's stronger, more secure and safer, so why not?

Greetings,

[Wanderer]

Hi Eric.

Another solution would be to load several db at a time, and switch between them when needed (fix or display for example). Of course, each db will act as an independant database, and belong to a stand-alone node in the tree.

What i have in mind is something similar to the "Solution\Project" concept of Visual Studio IDE, as it appears in the tree in the "Project" window of the IDE. The "Master Database" i'm referring to (which could actually be a simple xml file) would be the "Solution". In it, several dat's ("Projects") could be added (or removed ) by the user (which will be instantly converted to rdb databases of course, as is done in RC3). Each project would have its own set of rom paths. The "Project" nodes could be as is now in RC3. I'm simply suggesting to add a "super node" under which multiple "Projects" could be added.

The "Fix" button could be inactive for the "Solution" node if you wish, but it would be active for each of the "Project" nodes, giving the user the ability to "fix" a whole project (like currently done). The search button of course could be active in the "Solution" node, to be able to do a multi-project search. All projects should be visible and expandable in the tree, without the need for any combo-boxes for selecting a DB (which would add some extra loading time when a combobox item is selected). TIM was like that and it seemed very convenient.

In RC4, you could rightclick on the "Solution" node and select "Properties" from the context menu. That could bring up the generic program properties (nothing emulator-specific here, only stuff like "Language" for instance). On each "Project" node you could do the same and select the specific "Project" properties (like "emulator location" and other stuff that currently exist in RC3's properties dialog).

Last-minute idea: one could load a "solution" to RC4, RC4 would read the "solution" file and discover that it contains 3 separate projects (each being actually a sub-db) and starts loading all of them simultaneously and adding them to the tree using multi-threading. That should be much faster to work with than having to select a different subdb from a combobox. After all, the user would be free to create solutions containing as many "projects" he wishes and face the consequences (large loading times).

I think i'll stop for now. I'll wait for you to release a demo of the interface.

[RomCenter]

Thank you for all these ideas. It is interesting and it could work (I think)...

The idea to store all dats in separate db could be the solution. With multithreads, it can even be almost as fast as for one db.
I will release the wip rc4 interface soon, and I will try to add these new nodes to see how it can work (of course without anything behind for now).

[RomCenter]

First Wip release can be found here.

[Wanderer]

Well, it seems pretty nice. Very promising design.

Can you give some more details (Version of VS used, version of .NET required)? Language is C# as you said in an earlier post, right?