ROM Hack Trying to rip sprites from Rocket Slime

[algo_home]

Hey team! New to the rom hacking community & this forum, so apologies if this is in the wrong place/not a good way to post.

I'm trying to hard rip sprite sheets from the DS game Rocket Slime, but running into a brick wall -- all the sprite ripping tutorials I've found deal with file formats that my ROM doesn't have, outside of the audio files it looks like all the graphical data is stored in binary files. Are there any tools/strats I can use to decode the binaries into sprites, or is that not a possibility? lmk if more information would be useful

Appreciative of any input/resources!

Edit: Quick update: Opening the .bins in crystaltile is giving me something that looks like a tilesheet, just shuffled around or something -- i guess my current goal is to find the palette for the sprites (?) and find a way to un-shuffle them? I'll keep looking and update if i figure it out, again I'm real new to this so apologies if this is a dumb issue & please lmk if I'm on the wrong path or something!

Another edit: Got the sprites the right shape! Palette is still off though-- anyone know how to find a sprite sheet's palette or a resource that could help me? Thanks!

 

[FAST6191]

You still have the option of emulator ripping (all those nice VRAM/BG/OAM viewers in various emulators are there for a reason), possibly assisted by cheats*. Bit tedious but will get it done and spares you having to play hacker.

*If you are say ripping the sprites for all the weapons in a RPG. You could play the game to the end and do the 30 hour sidequest to get the ultimate weapon, or you could get to the first shop, figure out the inventory format (two main approaches really) and make an inventory cheat to get it there. If if it is enemies you might still be able to figure out what values correspond to the enemies in battle and use that to cycle round some rare enemies.


Anyway palettes.
You can rip them from emulators. Get to a point in the game when the sprite is displayed (or the same colours are used) and it will be there to grab from emulators, savestates and other things.

Beyond that you get to play ROM hacker. I like to grab a palette (does not necessarily have to be the one for the thing you want) from the game and search the game for it. That way you can find out how it is stored in one and that will usually go for all.
For the DS then I also tend to look in the same directories as where I find the graphics (if there is a small file with a similar name then worth checking that out), at the start of files, at the end of files. In a tile editor it will usually look like a jumbled mess of pixels (as opposed to like an image or blank), though I can't necessarily spot things reliably in such scenarios like I can with other things that are not graphics or are compressed graphics.

I do have a bit in https://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/ on the matter.

If you are using crystaltile2 then in the hex window is the option to set the cursor somewhere and then press a button on the left hand side along the lines of hex -> pal to dump a palette like that. Be careful as just below it is the other way around and will dump the palette into the hex window and possibly break the game, and the undo command is dubious at best with that program.

 

[algo_home]

Gotcha, thanks for the intel! as I said I'm really new to this so all that information was super useful, especially the hex->palette function in crystaltile2.

I found one functioning palette (in crystaltile2 I used the nds filesystem viewer -> edit -> view icon), looked at the hex for that palette and searched for code that started with the same few hex values in case all the palettes have the same header or something. Doing that I got a bunch of lines of hex that look like palettes, and they look almost normal on some of the sprites!!

I'm gonna keep messing with it for now, still have no idea how to match the sprites with their palettes beyond trial and error, but I've been having fun learning how this stuff works so hopefully I can figure it out!

Also, you mentioned that you can get useful data from savestates-- how do you do that, like generally? I tried to crack open a savestate file and see what it's like and I have no clue how to parse any off the data, do you have tools for it or is it grindier/hackier than that?

Thanks again for the help!

 

[FAST6191]

The savestate thing was more for pulling a palette -- some tile viewers will even be able to grab palettes from savestates directly (tiled2002 being able to grab from VBA savestates for instance).

You can use savestates for other things -- they are literally a copy of memory (though for no$gba you might need to go to options and turn off compression) so can be edited like you might run some cheats, and technically I suppose you could use them to grab any graphical data that has been shoved into memory (a normal tile viewer working for this). I would not necessarily rip things with it but I would have it as an uncompressed and unencrypted (not much encryption on the DS) copy of whatever custom compression/encryption I am trying to find -- if I know the source and know the final result then filling in the blanks can be somewhat easier.
We did also use such things to rip some custom audio that had information generated at runtime the other month for a DSi game but that I don't expect to see as much on the regular DS.

The view icon thing is probably a bit different to most other things in the game -- the icon is part of the header of essentially every ROM (and download play) and is a known format. Games can colour outside the lines somewhat here, to say nothing of dynamic palettes, palette animations and the like.
If recursively searching to see if there is some option, or just to find a palette you need if you have it in game at the time, I would instead grab the palette from a point where it is loaded in the game (savestates or memory viewer or whatever) and search the game for that or a fragment of it*. Palettes, unlike graphics, are usually too small to gain any real benefits from compression for so tend not to be. From there you might be able to tie it back to a file (the status bar in crystlatile2 will tell you what file the cursor location corresponds to, or you can figure it out from whatever tool you like that lists file locations) and see if there are any names, extensions, directories, sizes, header values, footer values, magic stamps or other constructions that might serve to showcase what goes.


*if the game has some animations (you can see it fairly obviously by going into the palette viewer and setting update in real time/continuously and just watching it) in a later slot in the palette then what comes before that is otherwise unchanged (or after if that is static) might be visible with whatever placeholder value is there.