Pandora Pandora Emulator Frontend

[Flam]

Yes sure send me the template and I'll try it!

 

[Aimless_E]

Yes sure send me the template and I'll try it!

CODE

//filename;Title;Publisher;release date;Emulator;Developer;system;genre;flyer //
puckman.zip; PuckMan (Japan set 1, Probably Bootleg); Namco;1980;MAME;unknown;unknown;unknown;puckman.png;



In the filename avoid all special characters,spaces,and capital letters. (example:"Super Mario All Stars + Super Mario World.smc will need to be supermarioallstarssupermarioworldu) The name on the SD card wont need to be changed the program when searching will remove all the unwanted characters and formating when making the comparison. When it make the Game list it will use the original name so the emulator will be able to find it. I'm working on a way to look at the MD5 sums to make the detection more fool proof, but It slows the program down too much at the moment.

This is the game list db as you probably guessed. The options list and the user editable list will follow the same pattern but may have a different order.

 

[Flam]

Can you send me an example? I'm not quite sure what exactly I'd have to do?


Also would it be possible to add a description for each game? Not now but sometime in the future when all basic functions are working?

 

[Aimless_E]

Can you send me an example? I'm not quite sure what exactly I'd have to do?


Also would it be possible to add a description for each game? Not now but sometime in the future when all basic functions are working?

Oh sorry Flam

Just Copy and paste the above "Code" into a text editor like notepad (not word) and follow the pattern.

actually I guess you could try to open it in excel if it will allow you to set the delimiter you should be able to edit it easier that way.

A description is a good Idea I'll see what I can do.

 

[Flam]

Ok I think I understand it, but will every game need it's own file or should all games be on one file?

 

[Tiptup300]

Thinking into the future, shouldn't you probably make it using a sql database?

Like with a Game Information table

gID,Title,Publisher,ReleaseDate,Emulator,Developer,System,Genre,Flyer

then an MD5 hash table

hID, Hash, gID

as the columns. Then have a separate table with the current collection

fID, gID, Filename, PlayAmt

then have a gamesaves table

sID, gID, Nullable SaveTitle

I don't see how you could manage all this and not run into problems on a flatfile database. The SQL option just seems like a duh move to me.

 

[Wertigon]

Thinking into the future, shouldn't you probably make it using a sql database?

Why?

SQL Databases are great, but when it comes to actual files, isn't it better to, you know, store the information about a certain file in an ID3 tag or similar? Just asking.

 

[Vorporeal]

Thinking into the future, shouldn't you probably make it using a sql database?

Why?

SQL Databases are great, but when it comes to actual files, isn't it better to, you know, store the information about a certain file in an ID3 tag or similar? Just asking.


Because that's transmitted with the file. People aren't going to be obtaining ROMs from a central repository. They'll be getting them from wherever they get them from, and then Zib will use this database to match the ROM with the information about it. ID3 tags wouldn't work at all.

 

[Wertigon]

Because that's transmitted with the file. People aren't going to be obtaining ROMs from a central repository. They'll be getting them from wherever they get them from, and then Zib will use this database to match the ROM with the information about it. ID3 tags wouldn't work at all.

ID3(ish) tags would be great for a number of things actually. Like, developer/publisher, date released and so on - information that won't change at all. Also, no genres, just use tags instead. That way, Castlevania: SotN can be regarded as a platform game, AND an Adventure game. Favorite ratings should also come with the file, but there should be an option for the frontend to remove all ratings.

As for game saves and cheats, those should always be stored locally, in your home folder.

Using an SQL database for something where plain old files work just perfect is just a whole lot extra complication and overhead for nothing...

That said, a centralised database that tags up your rom files automagicly would be nice, too.

 

[Vorporeal]

Because that's transmitted with the file. People aren't going to be obtaining ROMs from a central repository. They'll be getting them from wherever they get them from, and then Zib will use this database to match the ROM with the information about it. ID3 tags wouldn't work at all.

ID3(ish) tags would be great for a number of things actually. Like, developer/publisher, date released and so on - information that won't change at all. Also, no genres, just use tags instead. That way, Castlevania: SotN can be regarded as a platform game, AND an Adventure game. Favorite ratings should also come with the file, but there should be an option for the frontend to remove all ratings.

As for game saves and cheats, those should always be stored locally, in your home folder.

Using an SQL database for something where plain old files work just perfect is just a whole lot extra complication and overhead for nothing...

That said, a centralised database that tags up your rom files automagicly would be nice, too.


You still missed the point. ID3 tags are linked to the file. We would need some way of getting the data that would be put into the ID3 tags. This is what the SQL database/flatfile database would be for. You can't just fill out the ID3 tags for any ROM you download out of thin air.

 

[Tiptup300]

Can you even add ID3-like tags to any rom you want to without some problems occuring from the emulators?

 

[Vorporeal]

Oh, and on top of the problems I listed below, ID3 tags are almost exclusively in use for media files. Not to mention that adding them requires the addition of data to the file itself, something which could cause issues with ROMs, and would DEFINITELY break compatibility with any emulator that didn't support the tags.

 

[CyruzDraxs]

An SQL database is much better. that way the emulator programmers don't have to rewrite their rom loader every time you want to add new tag types.

 

[Aimless_E]

First off, and I'm going to be a dick about this. I WILL NOT BE USING SQL ON THE PANDORA OR IN ZIB! The current file format is for adding large lists into a true DB file No Not SQL or mysql or prostgres, Yes I know that there are benefits to using a MySQL none of which I care about at the moment.

Regardless to how it goes from one file to another the user shouldn't care because ZiB will do it for them. It is correct that ZiB will have to have master lists for each emulator, but they will be provided and or generated for each new version.

More on what and how later.

 

[Tiptup300]

First off, and I'm going to be a dick about this. I WILL NOT BE USING SQL ON THE PANDORA OR IN ZIB! The current file format is for adding large lists into a true DB file No Not SQL or mysql or prostgres, Yes I know that there are benefits to using a MySQL none of which I care about at the moment.

Regardless to how it goes from one file to another the user shouldn't care because ZiB will do it for them. It is correct that ZiB will have to have master lists for each emulator, but they will be provided and or generated for each new version.

More on what and how later.

Is there any specific reason you are avoiding sql?

 

[PoisonedV]

Why use SQL? Thats just stupid to me. Why not just code your own minimal database system, like he seeems to be doing? I suggest corroborating with the goodtools author

 

[ashaw]

Minimal Database ... SqLite.

 

[Tiptup300]

Minimal Database ... SqLite.

That's what I was personally thinking would be best. Although, I must admit, I never really integrated Sql into any of my applications except in PHP which doesn't really count. SqlLite seems very lightweight and portable though, it was used in XBMC for the xbox.

 

[ashaw]

Look at the link below, it looks verry easy to do.

CODE
http://www.sqlite.org/cintro.html



edit - unmangled link

 

[Aimless_E]

I have no real problem with SQL and to be honest I didn't even consider sqlite. It was the configuration headache that I was trying to avoid. I am still confident that ZiB will work fine without it so if I am proven wrong you all can rub it in as much as you see fit.

My wife and I just (as of Friday) have had a baby. So I might sound a little testy from time to time and I assure you I don't mean it.

I thought that if I used flat files for the import/export (like most DB programs do) we could distribute/edit the files easier. Where it ends up doesn't mater much. Regardless I have decided to do a "Feature freeze" and I should be able to use this time off to get all of this sorted out.