BAGUI(still WIP name...) Cover System

Hopefully by now, this should be the last time I need to mention this. If you are unaware of my current project, please check out it out here.

One of the main reasons why BAGPlug gained popularity was due to its cover support for any file type. There was a legit noticable increase of interest in BAGPlug after I had posted the first screenshot with the NDS cover loading, than there was before I had announced the feature. So it has become apparent that cover support is indeed a much desired feature in a menu/front end/interface, and thus, is worth preserving in any new iterations of my projects, despite its negative impact of performance during its loading.

Cover support in BAGPlug was fairly simple. For NDS roms, it would read the header for the game ID, then load a corresponding image with its name containing the game ID. For other files, it just needed to load an image containing the name of the file it was linked to.

For example, a nes rom:

Code:
mario.nes //rom file
mario.nes.png //cover file

The only problem with the second method of loading covers for other files, is that there could not be a centralized database of covers. Anyone could have any of their files named differently, thus one would have to rename all their cover images to correspond with the correct naming of the game file.

Cover support in BAGUI(name pending) is now much more advanced than that in BAGPlug.

-First off, there is support for more default files.

For mp3 audio files, BAGUI can load the cover artwork that is stored in the file itself. This is quite slow due to the imperfect mp3 file structure. There is a 16 or 20 mb image size limit that can be embedded in the mp3 file. That, along with no notation for how big the image is within the header, requires one to scan each byte in the mp3 file until it finds the "image start" and "image end" markers. There is a configurable limit to how many bytes BAGUI should scan in an mp3 file to prevent it from scanning all 20mb of data, which would be slow. Regardless of such limit, scanning each byte for 600kb of data is still slow, but much more managable with only a 1 to 3 second delay for cover loading.

If an mp3 file does not contain its own artwork, then the folder in which the mp3 file resides in is scanned for any image files to use.

Due to the slow scanning for artwork, I have implemented a simple check to prevent constant reloading of artwork for audio files of the same album. Everytime a new mp3 file is selected, it's album name is compared with the previously loaded mp3, if it's the same, the artwork loading is skipped. If not, then the new artwork is loaded.

NDS Rom files work pretty much the same as BAGPlug, no need to fix what isn't broken.

Image Files now load themselves as a cover or image thumbnail and are scaled to fit the screen. There is a configurable limit to the max pixel dimension of an image can be loaded because the whole image itself is loaded into the ram. Too large of an image would exceed the amount of ram available and would not be loaded; alternatively, if there was enough ram, this prevents BAGUI from stalling too long on a file to load its image if it happens to be 10 megabytes.

Folders now display the first found compatable image in its path for a cover, following the same rules as image files.

-Secondly, there is better support for covers of indirectly supported file types.

Other Files followed the painful method of the renaming and matching with image files. Well no longer is that an issue. The covers.ini file now supports a few more arguments to control your cover loading methods.

Some files contain data within themselves, to identify or differentiate themselves from others of similar file types.For example, NDS roms contain a game ID which is unique to each NDS file. BAGUI now allows you to search for these unique identifiers on your own through the covers.ini file.

For example, SNES roms:
Code:
[sfc]
path = /_bagui/cover art/snes
offset_type = HEX
offset = 7FC0
data_len = 21

path: is the location where to load the snes cover images from
offset_type: is the format of your byte offset
offset: is the byte location in the binary to read the unique identifier from
data_len: is how many bytes to read for the identifier.

Now snes games can use a centralized database of covers! Each snes game has a game title located at 7FC0 in the snes rom which is 21 bytes in length, now we just rename all the snes cover images to use this internal name, and it will be compatable with all snes roms regardless of their file system name.

The same can be done with GBA roms:
Code:
[gba]
path = /_bagui/cover art/gba
offset_type = INT
offset = 172
data_len = 6
notice that the offset_type is set to INT(integer, being standard base 10, refering to number of bytes), and the offset to 172 bytes in the file. This is the standard location in gba files that contains a 6 alpha-numerical ID string for GBA roms.

thus giving the result of:
2012-04-07_115007.jpg


For files that do not contain a method of internal identification, you can still use the name method to link files to covers:
Such as NES roms:
Code:
[nes]
path = /_bagui/cover art/nes
use_name = 1
use_name is set to 1 indicating that BAGUI should look for a cover containing the file name in it:
mario.nes - the file
mario.nes.png - the cover

-Lastly, Covers are resized automatically by BAGUI. There is no specific image size for covers, they will all be resized and filtered in run time to fit the interface as necessary. But it would be wise to resize to the native supported size to save file space as well as reducing the load and decompression times when displaying the cover.

And that is all for the cover system for now. As you can tell, lots of progress is being made on making this menu much better than BAGPlug. More to come on other improvements as soon as they are implemented. Until next time.

Comments

G
"Covers are resized automatically by BAGUI"

Fuck yes
 

Blog entry information

Author
BassAceGold
Views
212
Comments
2
Last update

More entries in Personal Blogs

More entries from BassAceGold

Share this entry

General chit-chat
Help Users
    SylverReZ @ SylverReZ: @K3Nv2, Deez