codewario
Generate thumbnails for the Library Browser
Is your feature request related to a problem? Please describe.
Currently there is no images shown when browsing games through Tools/User Service/Library Browser, only when you select a particular game.
Describe the solution you'd like It's not clear if this is the intended behaviour and if it's intended why Analogue have decided to implement it like this.
Either way it would makes much more sense in my opinion to see thumbnails both in the detailed game view and in the list when browsing.
Describe alternatives you've considered Generating from an existing image set would be preferable to generating thumbnails from scratch alongside the main process, because of the existence of semi-official image set that wasn't generated using this script in the first place. That way we would be able to generate thumbnails for it too (or any other set).
Also it would be much easier to regenerate thumbnails in case if user added a couple of custom images for homebrew and such.
Additional context
User g026r on Reddit seemed to reverse-engineer thumbnails file format (https://www.reddit.com/r/AnaloguePocket/comments/1f9ff9o/comment/llmzs95/) which presumably would make it possible to generate a thumbnails file from a created image set.
Here is tl;dr for people who don't use Reddit
The _thumbs.bin file format is as follows:
A 4 byte header: 0x02465441
4 bytes indicating the size in bytes of each thumbnail image in the file; it's stored little endian as are all other values in this file. For the Pocket the value of this word is 0x1CCE0000, corresponding to 52764 bytes. (I'd be curious to know if this value is different on the Duo.)
4 bytes representing the number of images contained in the thumbs file.
Next is the section mapping games to the images contained in the _thumbs file. Each game consists of two 4 byte entries. The first is the CRC32 for the cart. The second is the offset in the file where the image starts. The second part of the first entry will always be 0x0C000100 — this is because the file reserves 64kB for library entries, or the equivalent of 8192 games.
Any space after the last entry and before byte 0x0001000C is left as zero. It seems likely that the Pocket uses the number of images entry in point number 3 to determine where to write the next offset mapping & just adds them sequentially in the order they're added to the library.
Starting at byte 0x0001000C, we get the first image entry. It appears to be the regular Pocket image format with two caveats: i) the image size in all my entries is 0x79006D00, corresponding to 121x109; and ii) I haven't translated the images back into a viewable format, so I have no idea if the image has been rotated 90º like the individual image files but I assume this is likely.
Because the images have been shrunk & cropped to a consistent set of dimensions & they're uncompressed, each game entry is 52764 bytes. From that, we can come to the conclusion that a full gba_thumbs.bin with all 2913 entries would be about 146.6MB.
A few things I haven't tested:
What happens if you remove a game from your library? Does it remove it from the thumbs.bin? My guess is no. (If that's the case then once you've added a game to your library you're stuck with that image until either you delete the thumbs.bin or manually edit it.)
The number of images appears to be a 32 bit integer. Assuming it's unsigned, that's potentially a significantly larger number than the default allocated space for entry mappings, which is only 213. What happens if you overflow that default allocated value, say by setting it to 0x01200000? (Maybe it's not a 32 bit int, some of the 0s are simply unused padding, and this isn't an issue?)
