I'm a sucker for pattern searching (and for Clash Royale too), so I got instantly hooked on decoding these files.
First: as for the images, this script can extract them all: https://github.com/123456abcdef/cr-sc-dump/
Second: even with the new script version, some sc files can't be extracted, namely the attached list. They exit with the error below:
- open script clash_royale.bms
- set output folder 1.5.0\error\sc
offset filesize filename
00000023 36034 building_mega_bomb
Error: the compressed LZMA input is wrong or incomplete (0)
Info: algorithm 445
input size 0x000017c5 6085
output size 0x00008cc2 36034
result 0xffffff9c -100
Error: the uncompressed data (-100) is bigger than the allocated buffer (36034)
Last script line before the error or that produced the error:
28 clog NAME OFFSET SIZE XSIZE
Third: now this is what you guys were waiting for. With the .sc files that quickBMS could extract, I googled for their headers and found nothing useful. So I dug Notepad++ and an hex editor plugin and started researching the binaries for patterns and such. I focused on ui_spells.sc (the card's pictures on your card collection), because it's a neat grid and patterns would emerge quickly. Among the text strings inside I found "atlasgenerator_texture_rgba5656", which could be a clue, but Google doesn't know much about it. This is what I found so far (addresses are in hex):
- numbers are INT16 Little Endian: first byte is the least significative part, second byte is the most significative. So a pair e6 03 is 998, not 58883.
- 00-01 - total number of effective sprites mapped in the file
- 02-10 - ??
- 11-12 - number of IDs/strings (these are mentioned in the CSV files)
- 13-xx - a list of IDs for each string, 2 bytes each
- a list of strings. Each is preceded by a byte with the string's legth.
- 17 00 00 00 00 1A 00 00 00 00 (constant?)
- block(s) of 10 bytes, starting with 01 05, one for each image mapped in this file. The image extracting script appends an "_" on the filename for each image on the same _tex.sc file. The last 4 bytes are the image's width and height
- blocks starting with byte 12, one for each sprite: these map the sprites on the image, and vary in size. These have 5 '00' bytes between blocks.
- 2 bytes: length of the block
- 00 00
- 2 bytes: sprite ID (not the same as string ID, but they're associated later)
- (lots of bytes to decode)
- for static, rectangular images: final 16 bytes are the coordinates (xy) of the 4 corners, normalized between 0000 and FFFF. Just multiply by (image_dimension/65535)
- blocks starting with byte 08, not sure how many, not sure what they are, same size rule as 12-blocks. These have 5 '00' bytes between blocks.
- blocks starting with byte 09, not sure how many, not sure what they are, same size rule as 12-blocks. These have 5 '00' bytes between blocks.
- blocks starting with byte 0C, one for each string, same size rule as 12-blocks. Bytes 5-6 are the same IDs from address 13 onwards, bytes 22-23 are the IDs on the sprite blocks. These have 5 '00' bytes between blocks.
Again, this is based on a study of ui_spells.sc, which are static and mostly rectangular images (legendary cards are hexagonal and their 12-blocks are structured differently). In time I'll try to get some sense off of the animated ones. Any constructive feedback is appreciated.