I wanted to extract some sprites from Harvest Moon DS and watched a tutorial on how to get the graphics from Mario Kart DS there were .carc files but in the Harvest Moon DS rom only .bin files does anyone know how to get the data? (and sorry for my English)
.bin is a generic name used by a thousand different formats (indeed within the average DS ROM there are at least 5 different types just making up the ROM) and any dev that just needs a quick extension.
To that end you will have to figure out some things.
First if you can get what you want with the sprite viewers (by all means use cheats in the game -- how much can you get if you never get tired and have infinite money?) and you only want the sprites to play (if you want to edit them and insert back into the game then read on) then various options menus in desmume and no$gba and probably some of the others will tend to have what is on screen and what is about to be on screen or could be on screen. You can rip those with a print screen command.
If you want to edit things or rip things not available easily within the game* then time to play ROM hacker.
Graphics are comprised of two aspects, three if you count animations.
The tile data itself. All the pixels form a very boring paint by numbers (malen nach Zahlen?) really.
The palette data, which holds the colours.
You need both to do most things, though if you know one sprite is one colour in the final game you can edit a more abstract way. You can rip palettes from the emulator when the right one is loaded up (like if the thing is on screen), some tile editors might even load savestates and grab it from that but I have not any DS examples right now.
Sprites. You want a tile editor to look at.
https://www.romhacking.net/utilities/818/ is one of the better tile editors.
Open the ROM, you can click on the little DS icon on the right to get a DS file viewer up and double click to set the hex/assembly/graphics/... window to the location of that file.
The DS uses GBA like graphics (GBA 4bpp and GBA8bpp) so you have to try both options as different things within the game might use different things.
https://www.romhacking.net/utilities/112/ is another tile editor I like.
https://www.romhacking.net/utilities/646/ is more of a viewer but still very good. Does not use the console name conventions of other graphics viewers though.
*do check you can't swap files around -- as well as cheats then the final end boss sprite, though I get that this is not a game with a final end boss, might well be able to be swapped a file level and loaded up in the first dungeon instead).
DS files are often compressed, though the type of compression is well known and documented. (if the file in a hex viewer starts with 10 or 11 hex and is followed by what could be the size of the file then that is a well known type of LZ compression used by many games, and even supported in the system BIOS). Crystaltile2 might even detect it.
http://www.romhacking.net/utilities/826/ has tools to extract such files, and recompress later.
If that is not enough then you are into ROM hacking proper.
https://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/ has a guide to such things. There did used to be some nice German ROM hacking sites (romresources.net being one) but it appears to have stopped working since I last visited if you prefer that.
To that end you will have to figure out some things.
First if you can get what you want with the sprite viewers (by all means use cheats in the game -- how much can you get if you never get tired and have infinite money?) and you only want the sprites to play (if you want to edit them and insert back into the game then read on) then various options menus in desmume and no$gba and probably some of the others will tend to have what is on screen and what is about to be on screen or could be on screen. You can rip those with a print screen command.
If you want to edit things or rip things not available easily within the game* then time to play ROM hacker.
Graphics are comprised of two aspects, three if you count animations.
The tile data itself. All the pixels form a very boring paint by numbers (malen nach Zahlen?) really.
The palette data, which holds the colours.
You need both to do most things, though if you know one sprite is one colour in the final game you can edit a more abstract way. You can rip palettes from the emulator when the right one is loaded up (like if the thing is on screen), some tile editors might even load savestates and grab it from that but I have not any DS examples right now.
Sprites. You want a tile editor to look at.
https://www.romhacking.net/utilities/818/ is one of the better tile editors.
Open the ROM, you can click on the little DS icon on the right to get a DS file viewer up and double click to set the hex/assembly/graphics/... window to the location of that file.
The DS uses GBA like graphics (GBA 4bpp and GBA8bpp) so you have to try both options as different things within the game might use different things.
https://www.romhacking.net/utilities/112/ is another tile editor I like.
https://www.romhacking.net/utilities/646/ is more of a viewer but still very good. Does not use the console name conventions of other graphics viewers though.
*do check you can't swap files around -- as well as cheats then the final end boss sprite, though I get that this is not a game with a final end boss, might well be able to be swapped a file level and loaded up in the first dungeon instead).
DS files are often compressed, though the type of compression is well known and documented. (if the file in a hex viewer starts with 10 or 11 hex and is followed by what could be the size of the file then that is a well known type of LZ compression used by many games, and even supported in the system BIOS). Crystaltile2 might even detect it.
http://www.romhacking.net/utilities/826/ has tools to extract such files, and recompress later.
If that is not enough then you are into ROM hacking proper.
https://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/ has a guide to such things. There did used to be some nice German ROM hacking sites (romresources.net being one) but it appears to have stopped working since I last visited if you prefer that.
I took a peek just for fun and noticed that there are at least some files that are encoded as GBA 4bpp 8x8 tiles. This is from touchanimal.bin:
So it doesn't look like the ROM is compressed. I'd guess you can just scroll through to find stuff. Only question would be figuring out where the palette files are for the sprites (though if you're just editing them that's not even necessarily needed).
Hope that helps!
So it doesn't look like the ROM is compressed. I'd guess you can just scroll through to find stuff. Only question would be figuring out where the palette files are for the sprites (though if you're just editing them that's not even necessarily needed).
Hope that helps!
DS ROMs are rarely compressed in and of themselves (not enough memory to usefully decompress things) and instead individual files might be. Sometimes files will be compressed, sometimes not. Usually there is no great rhyme or reason -- at best I see some very small files not be compressed owing to lack of gains, and sometimes speed/latency sensitive stuff might be left decompressed, and the sound files (usually .sdat) tend not to be touched either as PCM/ADPCM wave is already compressed as part of its nature.
On palette files. Yeah if just editing and you can handle the oddities there (be careful as depending what tile editing you are doing the default palette might have the same or very very similar colours in multiple slots, usually some of the more old school ones where they defaulted to a given game) then you can get away with it. I tend to leave that for very simple edits of one colour to another but if you can handle it then go for it; it is not like when people using a hex editor when there are better tools available.
I tend to find palettes either in the same file as the graphics (usually in a tile viewer it will be a section that looks like noise right at the start or right at the end), in the same directory (usually a small thing with a similar name, maybe even one of the known palette extensions) or in the directory above if it broken down into multiple subdirectories. If just for editing and you are not editing the palette then you can also rip it from the game -- get to a point where the data in question is on screen or maybe just loaded into RAM and the corresponding palette file will tend to be there too. Bonus is you can usually search the ROM for said palette and find it that way -- being so small they also tend not to be compressed, if it is a dynamic palette or one colour is kicked to animation do a search for which fragment is bigger from before and after the changing section, or use a wildcard. Hopefully you don't have a truly dynamic palette (I usually use examples from summon knight on the GBA for this which has both animations and options in the menu to change colours for GBA, GBA SP and GB player) though you might be able to get something done with a relative search.
Bonus 2. If using crystaltile2 then the hex window has data-pal and pal-data. It will convert the location of the cursor to a palette and vice versa (be careful as it will overwrite parts of the ROM). Older tile editors for other consoles (my other main choice of tile editor in tiled2002 supporting VBA savestates) might even be able to rip palettes from savestates (what is a savestate if not a dump of everything in memory).
Bonus 3. Crystaltile2 will also put down a character you type when in the editor section according to the font settings. I tend not to find it useful for normal font editing but if you have stylised stuff like the picture above you can probably get something done.
On palette files. Yeah if just editing and you can handle the oddities there (be careful as depending what tile editing you are doing the default palette might have the same or very very similar colours in multiple slots, usually some of the more old school ones where they defaulted to a given game) then you can get away with it. I tend to leave that for very simple edits of one colour to another but if you can handle it then go for it; it is not like when people using a hex editor when there are better tools available.
I tend to find palettes either in the same file as the graphics (usually in a tile viewer it will be a section that looks like noise right at the start or right at the end), in the same directory (usually a small thing with a similar name, maybe even one of the known palette extensions) or in the directory above if it broken down into multiple subdirectories. If just for editing and you are not editing the palette then you can also rip it from the game -- get to a point where the data in question is on screen or maybe just loaded into RAM and the corresponding palette file will tend to be there too. Bonus is you can usually search the ROM for said palette and find it that way -- being so small they also tend not to be compressed, if it is a dynamic palette or one colour is kicked to animation do a search for which fragment is bigger from before and after the changing section, or use a wildcard. Hopefully you don't have a truly dynamic palette (I usually use examples from summon knight on the GBA for this which has both animations and options in the menu to change colours for GBA, GBA SP and GB player) though you might be able to get something done with a relative search.
Bonus 2. If using crystaltile2 then the hex window has data-pal and pal-data. It will convert the location of the cursor to a palette and vice versa (be careful as it will overwrite parts of the ROM). Older tile editors for other consoles (my other main choice of tile editor in tiled2002 supporting VBA savestates) might even be able to rip palettes from savestates (what is a savestate if not a dump of everything in memory).
Bonus 3. Crystaltile2 will also put down a character you type when in the editor section according to the font settings. I tend not to find it useful for normal font editing but if you have stylised stuff like the picture above you can probably get something done.
Similar threads
-
Xdqwerty
what are you looking at? -
Psionic Roshambo
-
K3Nv2
-
-
-
-
-
@
Psionic Roshambo:
I have 16GBs of DDR4 that I have been using forever lol 3200 with extremely low latency
-
-
-
-
-
-
-
-
-
-
-
-
-
-
@
Psionic Roshambo:
32GBs is the baseline for 4K video editing these days and lots of recommendations for 64GBs but for games 16,GBs is honestly plenty for a long time.
-
-
-
-
-
-
like a 250 dollar kit back when DDR4 was Intel only