This one's a big one with many parts to it. For now, the primary goal is to move the following tables:
system
firmware
header
from libretro.sqlite to phoenix.sqlite and change the frontend code appropriately (add a new DB class).
That's enough for pre-alpha.
Next, we need to begin building the database. Two great sources are No-Intro and Redump.
This next part, while tricky, is what'll make Phoenix special. We need to group ROMs that are just regional variants and/or different versions of the same base game into their own entries (with a good UUID that won't collide if, say the same game name is on two separate systems).
For a lot of games (most?) there probably isn't any automatic process that makes this possible. It'll have to be done by hand...
In the case of No-Intro, we can automate it somewhat as we can group all games that have a base name and system in common. No-Intro stores its game names like this: Base Name (Region) (Additional tags) (...)
athairus
commented
8 years ago
This one's a big one with many parts to it. For now, the primary goal is to move the following tables:
from
libretro.sqlitetophoenix.sqliteand change the frontend code appropriately (add a new DB class).That's enough for pre-alpha.
Next, we need to begin building the database. Two great sources are No-Intro and Redump.
This next part, while tricky, is what'll make Phoenix special. We need to group ROMs that are just regional variants and/or different versions of the same base game into their own entries (with a good UUID that won't collide if, say the same game name is on two separate systems).
For a lot of games (most?) there probably isn't any automatic process that makes this possible. It'll have to be done by hand...
In the case of No-Intro, we can automate it somewhat as we can group all games that have a base name and system in common. No-Intro stores its game names like this:
Base Name (Region) (Additional tags) (...)