So, I'm trying to figure out aforementioned format, found (so far solely) in "All Kamen Rider: Rider Generation" for Nintendo DS. It's a sprite-collection, essentially, but it's different from regular Nintendo DS sprite format. If anyone could help me figure this out and make things more convenient than "shift pixels constantly in CrystalTile to be able to rip anything" that would be much appreciated and I'd basically love you forever (platonically, anywho :v: ). Here's what I have figured out so far (as per usual, any unprofessional terminology can be attributed to me being a n00blet with these things 8D ) : Byte (80) WORD (varies from file to file, unknown purpose) Byte (0) WORD (20) WORD (0) Byte (60) WORD (varies from file to file, identical to the variable one above) Byte (0) DWORD (0) WORD (4) WORD (varies) WORD (1) QUAD (0) After that follows 512 bytes in Palette data. This palette data can be inserted into any standard Nintendo DS NCLR-Palette file, meaning it's essentially the same format. Following that is a block of data which I have not determined a purpose for yet. The block varies in size from file to file, but usually has data in the format "WORD (variable), WORD (0)." Could be some kind of address-lookup-table? Past that block of data begins sprite data, from what I can gather. Each sprite graphic has some header of it's own. WORD (width) WORD (height) WORD (varies, unknown purpose) WORD (varies, unknown purpose) WORD (size in byte) WORD (0) Then follows the actual sprite-data, and after that, the next file until it's all done. So, uh… can anyone here pretty please help me with this, maybe? xD; I know it's an obscure game and all that, but, yeah, I would really like to know stuff here. D: If it helps, here be an example file
I took some minutes and looked a little at the format. (although 2 files are always better than only one, so you can compare what differs) Header: DWORD: Buffer Size for data of whole file DWORD: Palette Offset DWORD: Buffer Size for palette + sprite data DWORD: decompressed data (maybe) - first DWORD is with, second one without header data WORD: (no idea) WORD: Sprite Count (here 0x68) WORD: (no idea) the other header bytes are 0 then there's 0x200 bytes of palette data at 0x220 there's a pointer table with [Sprite Count] DWORD pointers to some location (maybe data offset after loading them into NDS memory) after these 0x1A0 bytes (0x68 DWORDs) at 0x3C0 the actual data begins, which consists of [Sprite Count] Sprites each sprite consists of Sprite Header + Sprite Data Sprite Header: WORD: Sprite Width WORD: Sprite Height WORD: X-Offset (maybe similar to the HotSpot attribute in TGF) WORD: Y-Offset (same as above) DWORD: Sprite Data Size Note: there are lots of sprites that have all bytes in the header zeroed out, but they take some memory. I wrote a small tool to make the following list: Code (Text): FileID FileOfs DataLen MemOfs MemLen 00 03C0 0000 00220 038C 01 03CC 0380 005AC 038C 02 0758 0380 00938 038C 03 0AE4 0000 00CC4 03CC 04 0AF0 0000 01090 038C 05 0AFC 0000 0141C 038C 06 0B08 0000 017A8 03CC 07 0B14 0440 01B74 044C 08 0F60 0380 01FC0 038C 09 12EC 0000 0234C 03CC 0A 12F8 0000 02718 040C 0B 1304 0000 02B24 040C 0C 1310 0000 02F30 044C 0D 131C 0000 0337C 044C 0E 1328 0000 037C8 040C 0F 1334 0380 03BD4 038C 10 16C0 0340 03F60 034C 11 1A0C 0000 042AC 03CC 12 1A18 03C0 04678 03CC 13 1DE4 0280 04A44 028C 14 2070 0000 04CD0 014C 15 207C 0000 04E1C 028C 16 2088 0000 050A8 014C 17 2094 0000 051F4 012C 18 20A0 0000 05320 01CC 19 20AC 0000 054EC 020C 1A 20B8 0000 056F8 02CC 1B 20C4 0000 059C4 018C 1C 20D0 0000 05B50 014C 1D 20DC 0000 05C9C 014C 1E 20E8 0000 05DE8 020C 1F 20F4 0000 05FF4 018C 20 2100 0000 06180 028C 21 210C 0120 0640C 012C 22 2238 0000 06538 024C 23 2244 0000 06784 03CC 24 2250 0300 06B50 030C 25 255C 0280 06E5C 028C 26 27E8 0000 070E8 028C 27 27F4 0000 07374 014C 28 2800 0000 074C0 028C 29 280C 0000 0774C 01CC 2A 2818 0000 07918 02CC 2B 2824 0000 07BE4 020C 2C 2830 0000 07DF0 00EC 2D 283C 03C0 07EDC 03CC 2E 2C08 0000 082A8 00EC 2F 2C14 0300 08394 030C 30 2F20 0280 086A0 028C 31 31AC 0000 0892C 01CC 32 31B8 0240 08AF8 024C 33 3404 0000 08D44 024C 34 3410 0000 08F90 012C 35 341C 0000 090BC 01CC 36 3428 0000 09288 02CC 37 3434 0000 09554 010C 38 3440 0280 09660 028C 39 36CC 0100 098EC 010C 3A 37D8 0240 099F8 024C 3B 3A24 0280 09C44 028C 3C 3CB0 0000 09ED0 016C 3D 3CBC 0000 0A03C 02CC 3E 3CC8 0000 0A308 01AC 3F 3CD4 0000 0A4B4 012C 40 3CE0 0000 0A5E0 024C 41 3CEC 0000 0A82C 020C 42 3CF8 0000 0AA38 024C 43 3D04 0000 0AC84 018C 44 3D10 0000 0AE10 01AC 45 3D1C 0000 0AFBC 01AC 46 3D28 0280 0B168 028C 47 3FB4 0280 0B3F4 028C 48 4240 0240 0B680 024C 49 448C 0240 0B8CC 024C 4A 46D8 0000 0BB18 020C 4B 46E4 0000 0BD24 020C 4C 46F0 0000 0BF30 01EC 4D 46FC 02C0 0C11C 02CC 4E 49C8 0000 0C3E8 034C 4F 49D4 0000 0C734 02CC 50 49E0 0000 0CA00 034C 51 49EC 0000 0CD4C 028C 52 49F8 0000 0CFD8 020C 53 4A04 0000 0D1E4 016C 54 4A10 0200 0D350 020C 55 4C1C 02C0 0D55C 02CC 56 4EE8 0000 0D828 016C 57 4EF4 00C0 0D994 00CC 58 4FC0 0000 0DA60 00CC 59 4FCC 0000 0DB2C 018C 5A 4FD8 0180 0DCB8 018C 5B 5164 0100 0DE44 010C 5C 5270 0000 0DF50 020C 5D 527C 0100 0E15C 010C 5E 5388 0000 0E268 012C 5F 5394 0000 0E394 01CC 60 53A0 00E0 0E560 00EC 61 548C 0000 0E64C 080C 62 5498 0000 0EE58 0E0C 63 54A4 0000 0FC64 030C 64 54B0 0240 0FF70 024C 65 56FC 2500 101BC 250C 66 7C08 2500 126C8 250C 67 A114 1200 14BD4 128C FileOfs is the offset of the sprite header in the file, DataLen is the length of the sprite data excluding the header, MemOfs is the memory offset from the pointer table and MemLen the amount of memory the sprite takes including sprite header The last sprite takes 0x80 bytes too much memory (based on [Buffer Size] - [Memory Offset]), so the game might store some additional data. Note: I never did even a little NDS hacking, so I don't know how useful that information is. But I had some fun.
Why, uh, thank you, fellow countryman. o.o; Well, uh, This at least gives me a few pointers (pun not intended) with this, so maybe I'll figure something out later down the road -- much appreciated, at any rate. o.o The X and Y offset thingies might have something to do with rotational axis', because in this game, a character's head, body, arms, hands, legs, feet, etc. are all their own sprites and able to Mode7-rotate so as to be easy to pose flexibly.
