I had always planned on adding image support to the XML, but never got around to adding it to the spec. Here is a quick rundown of planned XML changes. If you have ideas to make it better, by all means, let me know.
Always though it would be cool to be able load up a game thru an interface something like this.
FYI, there is a modular form of the XML for doing rom sets. Not sure if the spec was ever really announced, I can write something up for this later, just mentioning it because these changes apply to it as well.
Some website specific ties will need to be added to the XML for this to work.
XML additions:
<database> Add attribute "website" with value set to base url of database site, currently http://bootgod.dyndns.org:7777/
Something will need to define the script names to call from the site too.
<cartridge> Add attribute "id" with value set to database CartID (the profile #)
new tag <images> nested in <cartridge> No attributes.
new tag <image> nested in <images> One of these for each image available.
<image> Attributes:
"type" would be set to Cart Front, PCB Front, etc.
"id" would be set to database ImageID number.
"file" to point to a local image file. This would supercede "id" if present. You could implement a cache system this way too. Initially download it based on ID and then write the "file" attrib to the XML so in the future it would load from there.
Some additional attribs that could maybe useful:
"dpi" = source image resolution
"width" & "height" = source image dimensions
"filesize" = source image filesize
"timestamp" = when source image was uploaded
"author" = person who uploaded it
These could be used by a program to decided if it wants to download or not, or if an updated image is available, etc.
Here on the server side, I will need to write up a script to serve these images. You will be able to request a specific size of the image, width in pixels would likely be most appropriate for use in a GUI. Other params would be ImageID to request a specific image. CartID + image type for finding a suitable image when a directly linked one is not available.
One thing to keep in mind that will probably be a nuisance is that multiple images will be available per game. If your emulator is looking up a game based on CRC32, it has no way to tell which profile it should be looking at.
For example, you load up Super Mario Bros ROM, get its CRC of D445F69 and look thru the XML for matches. Currently that's 13. SMB happens to be the same across all regions. So which scan should it load? Famicom or NES? USA? The 3-screw or the 5-screw version? The one with the old seal or the new seal? The one with or without the serial number? The one bert uploaded or the one ernie uploaded? You get the idea.
Of course most apps wouldn't really care about these specifics, however I think most would want some sort of consistency rather than the first image it happens to find. So some sort of priority system should be defined.
Always though it would be cool to be able load up a game thru an interface something like this.
FYI, there is a modular form of the XML for doing rom sets. Not sure if the spec was ever really announced, I can write something up for this later, just mentioning it because these changes apply to it as well.
Some website specific ties will need to be added to the XML for this to work.
XML additions:
<database> Add attribute "website" with value set to base url of database site, currently http://bootgod.dyndns.org:7777/
Something will need to define the script names to call from the site too.
<cartridge> Add attribute "id" with value set to database CartID (the profile #)
new tag <images> nested in <cartridge> No attributes.
new tag <image> nested in <images> One of these for each image available.
<image> Attributes:
"type" would be set to Cart Front, PCB Front, etc.
"id" would be set to database ImageID number.
"file" to point to a local image file. This would supercede "id" if present. You could implement a cache system this way too. Initially download it based on ID and then write the "file" attrib to the XML so in the future it would load from there.
Some additional attribs that could maybe useful:
"dpi" = source image resolution
"width" & "height" = source image dimensions
"filesize" = source image filesize
"timestamp" = when source image was uploaded
"author" = person who uploaded it
These could be used by a program to decided if it wants to download or not, or if an updated image is available, etc.
Here on the server side, I will need to write up a script to serve these images. You will be able to request a specific size of the image, width in pixels would likely be most appropriate for use in a GUI. Other params would be ImageID to request a specific image. CartID + image type for finding a suitable image when a directly linked one is not available.
One thing to keep in mind that will probably be a nuisance is that multiple images will be available per game. If your emulator is looking up a game based on CRC32, it has no way to tell which profile it should be looking at.
For example, you load up Super Mario Bros ROM, get its CRC of D445F69 and look thru the XML for matches. Currently that's 13. SMB happens to be the same across all regions. So which scan should it load? Famicom or NES? USA? The 3-screw or the 5-screw version? The one with the old seal or the new seal? The one with or without the serial number? The one bert uploaded or the one ernie uploaded? You get the idea.
Of course most apps wouldn't really care about these specifics, however I think most would want some sort of consistency rather than the first image it happens to find. So some sort of priority system should be defined.