The VG Resource

Back in the early 2010s there was a push to rip sprites from the 2005 (2006 NA) DS game Dragon Quest Heroes: Rocket Slime. A lot of the sprites ripped during this time seemingly were done via the emulator screenshot method where you just take a bunch of screenshots and try and create a cohesive sprite sheet from it.

This (revival?) project aims to try and directly rip sprites from the ROM itself. Main reasoning for this is that there is a bunch of unused content that was shown in early screenshots of the game in japanese magazines that are not seen in the final game. Some of these still exist in the game files which I discovered through my own exploration of the binary files contained inside the ROM (extracted via Tinke and DSLazy)

For example, take this "giga"/"cyclops" enemy which is NOT seen at all in the DS game, but was an enemy in the original 2003 GBA game Slime Mori Mori Dragon Quest: Shōgeki no Shippo Dan.

One of the issues I've come across however is that due to how they're stored as 8x8 tiles, a lot of the big enemies are split up into disconnected 8x8 chunks, like this:


(graphics data from TileGGD of the aforementioned giga/cyclops enemy)

Which requires quite a bit of manual work to put together. I've managed to get 3 sprites put together which took a few hours of trial and error.



I've been using TileGGD to explore and rip these assets. These are the settings I've found that work:


I've tried using other programs like TileMolester, ImageMagitek/TileShop, and Crystal Tile, but I've found it a lot more difficult to get good results in those compared to TileGGD.

Due to the labour intensive process of ripping these sprites, I'm posting here wondering (hoping) if some other people could join in and help preserve the beautiful artwork in this game as-well as potentially discover cut content.


Some more information:
* For the obj_*.bin files, the palettes are always stored at the end of the file. Easiest way to find them is to go to the end of the file by going to offset 9999999 (which will just put you directly to the end of the file) and then, using a skip size of 16 colors and pressing the home button a few times (or whatever the skip palette backwards shortcut is for you). This is also the same for all the npc_*.bin files and sl_data.bin

* Toy_*.bin files mostly seem to contain no palette information at all. A lot of them are also extremely small file-size wise and you can see the entire file in the palette viewer and see there's no palette. I'm not sure what to do about these outside of using an emulator to get the palette from them but this may be difficult in the case of objects that are only seen at specific parts of the game or impossible in the case of cut content.





From the top of my head, this is what needs to be ripped:

• Thousandweight
  
• Lightning staff
  
• Chilli pepper
  
• Devil's Tail
  
• Gold Bar
  
• Unknown amount of town slimes (a lot of the slimes are just different palettes of the same 'base' sprite, but I can see that there are a bunch of missing 'base' sprites on the spriters resource page for this game)
  
• All 6 bosses
  
• All but 3 enemies (20+ sprites!!) 
  

Example of the cool stuff found in the files. This is a beta version of the tank engine apparently only seen in promotional material in Japan before the game's release as-well as the animated trailer.

Discovered the palette in alchemy_data.bin which lead me to another discovery, that they reuse a bunch of palettes for items and other stuff which has let me discover palettes for a bunch of sprites that didn't have any palette data in their file.

Here's another thing I ripped:


This was inside korkoro_data.bin and is interesting for two reasons:

• Contains a bunch of unused ammo/item sprites (balloon, flower, molotov, pacifier)
  

• Contains a beta version of the tank shell ammo (top most sprite)
  

A few more rips containing sprites that are found no where in the game.





Also, I didn't mention, but yes these will be eventually all uploaded to spriters resource.

Hi,
Well you seem to do fine. Ripping directly from ROM is the way to go !

(08-02-2025, 04:57 PM)kilburto Wrote: [ -> ]Hi,
Well you seem to do fine. Ripping directly from ROM is the way to go !

Not doing particularly fine as it may seem. There's a number of troublesome graphics that are nearly impossible (for me) to rip because they require manually putting together like a jigsaw puzzle due to how they're stored as 8x8 tiles which causes large enemys to become a bunch of disconnected graphics.

Take, for example, **some** of the sprite sheet of an unused bird NPC/enemy/boss (purpose unknown) stored in obj_bird.bin (appears to be ramia from the main series)


This sprite appears nowhere in the final game so we don't have a reference to what the final sprite would look like, and nearly the entire sprite is split up into disconnected 8x8 chunks. I've tried myself, but it would most likely take me days or weeks to figure out how to piece this together which is why I require some help from experienced rippers who might have a keener eye than me for this kind of stuff.

This is also by far no the only sprite that requires manually putting together like this. All bosses are extremely large sprite and look like the bird in the binary file (and as far as I can tell, no one has ever ripped any of the boss sprites from this game)

I understand, 16x16 are easy but larger becomes tedious.
At the end of the files (obj*, toy*), between the tiles and the palettes, there is what seems to be the sprite mapping data but I can't figure out the format...
I'll keep trying.

*OK, I have mostly understood the format but Garamonde is working on it too so I leave it.

Yeah there's some sort of information there, but it could be anything. It seems to be a file format that closely follows the NitroSDK's various data structures for palettes and graphics. There's another person inside Fans Translator discord that has been working on reverse engineering the code of Rocket Slime, specifically the file loading part, to start working on processing the graphics automatically