The NEW Build Your Own Arcade Controls
Main => Software Forum => Topic started by: Mike on March 04, 2002, 10:04:41 pm
-
I decided to start a new thread the other one was getting a little long. Basically I think everyone agrees we need some kind of backend whether it be an xml file or some kind of lite database. Also I think everyone agress we need an api of sorts to interface it and perform basic functions usable by all FE's. Maybe if we start defining what kind functions we need it will help point to the correct backend. Here's some of the functionality I'd like to see. I'd like to see a one to many setup for categories so I can have a game in as many categories as I want. Also it should be flexible enough to accept user defined categories. So this means it should be updatable. So it needs to be something the user can get into the database and modify or have an interface to modify it. Also I'd like not to store reduntant information. So if I have a clone rom I'd like it to pull data from parent rom if it's applicable and data doesn't exist for the clone rom. So I load pacman and don't have a cabinet picture but I do have one for puckman so I get the picture of the cabinet for puckman instead. Also in the api i should be able to pull a list of all roms, All parent roms, all clones, all clones by parent rom. I should also be able to grab roms by date range, category, or any other possible search criteria someone can think of. And lastly it needs to be simple to use. For example if I want to get the roms by category it needs to be an easy call like romList()= getRomsByDate(1999, 1990) nothing complicated because that defeats the point of creating it. Ok those are my thoughts.
-
Doing a db wouldn't be hard to do. Why, because I essentially did all that work already for my frontend.
My FE is in flash. Flash does no db. So I made a commandline interface to my access db using vb.
Now, someone might say they don't want to use access, but want MySQL. Easy enough. It'll be open source. Chagne the connection string and compile:)
I have ideas on how the layout of the db should go (and relationships).
First, a good start is to make one just for mame, then expand it to make it general.
If you are curious about what my vb backend does give me an email. It takes some explaining as it was made to work with flash (ie output is in webform text).I also emailed mame.dk about their db. I see it was mysql (cool). They have a great db that would be a great start for relationships.
Example of a feature I put into my db, you can rename the game name. Like pacman (since that is my fav game). You do a listfull in mame you get these:
Pac-Man & Chomp Chomp
Pac-Man (Hearts)
Pac-Man (Midway)
Pac-Man (Midway, harder)
(games with different revisions have this problem too)
Now lets say for your FE you JUST want to show "Pac-Man" which will point to the midway version and don;t show others. My DB will be keeping track of that.
Questions about mame for this project:
Can you get parent/game rom relationships?
Bios roms?
Clones?
-
You can get those no problem. My Access database has all of that. Specifically 'gamecloneof' and 'gameromof'.
-
You can get those no problem.
-
I have not tried yet. My image for the snaps, marquees, and flyer are built on the fly. This is the easiest way for me since it requires not logic or real processing at all. I just look at the game name of the current rom, then subsitute it in for the required images.
I think it might slow it down if I had to check for a parent rom. I might give it a try today and see what happens.
-
Use the baFileExists function in authorware to see if child marquee, banner, or screenshots exists. If so just display it, if it doesn't display the parent whether is exists or not. It shouldn't really slow it down. Verification of file names is really fast usually.
-
This is all good stuff guys... for those of you who haven't go check out my "middle-end" thread... it's somewhat releated.
Checking to see if it's a clone or not is by far the easiest way to check for multiple instances of the same game btw.
(sorry SP)
Oh and on the file exists checking thing .... It will cause a slight slowdown... I've been experimenting with it for beta 6 and it looks like up to a 15-35 millisecond delay. (A virtual eternity in computer terms :) ) I wasn't using vb's functions btw but rather the windows api, which should be the fastest method. Still that's not too bad.
-
my network at home is !@#!@ for a bit.
-
In director it does not slow it down that much...
I check:
romname, then clonof, then rom of, then name of emulator, and if that is not found a dummy...
so 4 checks ;-)
Peter
-
In the -listinfo you can find out if you are a clone of something else.
I, since I didn't want to keep a million images around, only look at the parents images.
This also helps load since I usually get 3 or 4 images next to each other.
The other advantage of keeping track of the parent/clones, is that if the status of the emulation for a parent sucks (and no-clones is set) then I check to clones to see if any of them have a better status. Popeye was one fo the only ones that I ran that used this feature, and it's fixed. But there are still a few others.
-
This is all good stuff guys... for those of you who haven't go check out my "middle-end" thread... it's somewhat releated.
Checking to see if it's a clone or not is by far the easiest way to check for multiple instances of the same game btw.
(sorry SP)
Oh and on the file exists checking thing ....
-
I actually wrote a program to move all clone images into another directory (and then I deleted them).
why?
cleared up a !@#!@# load of space.
I'm trying to make CD's that have catver games seperated with all thats needed by mame on each. Mainly as a backup, but I also have friends who would love to play them every so often.