ROM Hack Help in extracting graphics from Theresia: Dear Emile

[ami-chan]

Hello!

I've been trying to rip the graphics from this game on and off for a while and need a little help. Theresia stores it files/graphics in .dat and each .dat stores a separate Nintendo graphic format.

nanpack.dat
ncepack.dat
ncgpack.dat
nclpack.dat
nscpack.dat

There's a file called bgdata.dat also located inside the rom. It controls what graphic will come onto the screen by looking at 8 bytes. Deleting one of these strings (more of the first one) absolutely screws what graphic comes onto the screen and nearly break the game. Found that offset 25B0 controls the very first image that appears on the screen ("Licensed by Nintendo", BE 0B 14 00 BE 0B FF FF). Hex editing this to any of the strings already in the file will show a different image such as a blue hole thing (04 00 04 00 04 00 FF FF) or a partial image of "family" that should appear on the touchscreen in-game (72 07 64 00 E2 05 FF FF).

Spoiler

The first image comes from the top of the file.

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF 03 00 03 00 03 00 FF FF
04 00 04 00 04 00 FF FF 05 00 05 00 05 00 FF FF
FF FF FF FF FF FF FF FF 07 00 07 00 07 00 FF FF
FF FF FF FF FF FF FF FF 09 00 09 00 09 00 FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

Excluding the first and fifth string (doesn't really show anything), I was able to look at these graphics in nitro paint using a dump I made last year (basically I split ncgpack.dat and nclpack.dat based on if it saw the header for the two formats after removing a bit of data from the start of each file). The code snippet above goes with the first five NCGR and NCLR files in each corresponding .dat file but that's all I know. The part that confuses me the most, and the one I need help with, is how it calls the two .dat files. Minus FF FF, I know what two of the bytes are for and have guesses for the rest.

For example, The work of fiction screen

Spoiler

BD 0B 14 00 BD 0B FF FF

14 00 controls how the image is displayed on the screen. Changing this to 64 00 makes it similar to the "family" image above. 14 00 makes the image cover the entire screen. Most of the strings uses 64 00 and 14 00 except the code section above and Bock 1F40-226F.
I think the first BD 0B controls the NCGR and the second one controls the NCLR used but I'm not completely sure.

Any help would be greatly appreciated!

 

[FAST6191]

Will probably have to have a look at the game itself but for now just pondering the usual stuff

nanpack.dat
ncepack.dat
ncgpack.dat
nclpack.dat
nscpack.dat



So I am guessing those would be expanded out to be the standard Nintendo provided formats for 2d graphics
NANR -- animation files
NCER -- layout/mapping/metatile
NCGR -- graphics resource
NCLR -- colour files/palettes
NSCR -- height/width for the most part as the images can get to be fairly high resolution relative to the screen resolution and what people normally think of when tiled image formats are used.

http://problemkaputt.de/gbatek.htm#dsfiles2dvideo
https://www.romhacking.net/documents/[469]nds_formats.htm

I guess then each dat focuses on that file type respectively. As not every file will use every format there I would be surprised to see them all match up (like might be the case for a giant spreadsheet with some cells being blank as it were, could be a bit of a speed boost in some styles of coding. Though runs of FF might be that kind of padding as you could code it to ignore those) and instead probably going to be some kind of fetch me file say 16 in this dat file and 5 for its corresponding animation and it knows that each entry contains so many bytes thus making it an easy multiple. Normal things to see in archive files are
File names (presumably absent here as they are generally irrelevant to the running of the game and the devs would have the original files there to shrink down to DS res (and shrink less if they made a PSP, phone or whatnot port afterwards) if they edited those).
File locations. Three styles of pointer as ever, doubt I will ever see sector based for DS games. Those being normal (values are exactly where the files are), offset (where the values are the location but added a bit, usually the length of the pointer section so all pointers effectively start where the real data begins) and relative (the pointer is the value plus the location of the pointer itself, hangover from older styles of computing but still has use cases here).
File sizes, have had archives be a list of file sizes before as well and had them include file sizes as well as pointers. Have also had things shifted (as in logical shift, or multiply/divide by some multiple of two as it is binary maths we are dealing with much like multiplying by 10 in decimal maths shifts the decimal point) before, even not in compression scenarios. Have also had higher bits be used as indicators (32 bits is some 4 gigs, losing the top bit means you only have 2 gigs to play with but not a nice bit to indicate compression, subdirectory, dev's favourite files... it really does not matter), indeed the popular NARC format Nintendo provides (though this game I guess went the other way despite leaning into it here) uses such a thing.


"Deleting one of these strings"
As in highlight, press delete everything shifts backwards by however much you just deleted? If so yeah that breaks a game in a hurry in most cases as everything that was assumed to be a fixed location before no longer is. At best then if you delete the length of the pointer-size-whatever section then everything after it will be a valid. Even blanking it out can be tricky if it tries to either interpret that as a location or grabs things from that location and tries to feed it to the graphics/text/music/level/whatever decoder and it gets very invalid data.
First image in the game during normal operation might not also be the first thing the devs coded in and instead you can place reasonable money on it being a thing you add in either at the end or when you integrate your collection of proof of concepts for levels/effectively minigames together that different teams were working on. Can be nice to know if you are just ripping things to posterity/fan games as you can feed all the other pointers to it and just reset the game every time you load a ROM rather than doing whatever.

Anyway in these scenarios I tend to figure out the locations of the files within the file. Ideally you would have the pointers/sizes sorted out but if all the sub files are known Nintendo formats then you can easily enough do a search for their respective magic stamp (detailed in the links above), take that list from your hex editor, feed it into a spreadsheet and develop a simple batch file for
https://web.archive.org/web/20170218180937/http://min.midco.net/cracker/filecutter.zip
that will slice out the relevant portion of the file and put it into a new file that is standalone. For ease and basic fiddling at this point I might shove them back into a DS ROM and load that in crystaltile2 as its graphics options for this sort of thing are pretty nice (click on the little DS icon on the right of the menu to bring up the DS ROM file viewer, right click on hopefully your nicely extension having files and you can get it to load those aspects in the relevant viewer). You might load the wrong palette for the graphics you have visible but easy enough to try another, and that works for both ripping for posterity and hacking proper (you know which correspond to what and at that point it does not really matter how you know).

 

[BattleLegendRed]

Hello!

I've been trying to rip the graphics from this game on and off for a while and need a little help. Theresia stores it files/graphics in .dat and each .dat stores a separate Nintendo graphic format.

nanpack.dat
ncepack.dat
ncgpack.dat
nclpack.dat
nscpack.dat

There's a file called bgdata.dat also located inside the rom. It controls what graphic will come onto the screen by looking at 8 bytes. Deleting one of these strings (more of the first one) absolutely screws what graphic comes onto the screen and nearly break the game. Found that offset 25B0 controls the very first image that appears on the screen ("Licensed by Nintendo", BE 0B 14 00 BE 0B FF FF). Hex editing this to any of the strings already in the file will show a different image such as a blue hole thing (04 00 04 00 04 00 FF FF) or a partial image of "family" that should appear on the touchscreen in-game (72 07 64 00 E2 05 FF FF).

Spoiler

View attachment 339441

View attachment 339442

The first image comes from the top of the file.

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF 03 00 03 00 03 00 FF FF
04 00 04 00 04 00 FF FF 05 00 05 00 05 00 FF FF
FF FF FF FF FF FF FF FF 07 00 07 00 07 00 FF FF
FF FF FF FF FF FF FF FF 09 00 09 00 09 00 FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

Excluding the first and fifth string (doesn't really show anything), I was able to look at these graphics in nitro paint using a dump I made last year (basically I split ncgpack.dat and nclpack.dat based on if it saw the header for the two formats after removing a bit of data from the start of each file). The code snippet above goes with the first five NCGR and NCLR files in each corresponding .dat file but that's all I know. The part that confuses me the most, and the one I need help with, is how it calls the two .dat files. Minus FF FF, I know what two of the bytes are for and have guesses for the rest.

For example, The work of fiction screen

Spoiler

View attachment 339453

View attachment 339454

BD 0B 14 00 BD 0B FF FF

14 00 controls how the image is displayed on the screen. Changing this to 64 00 makes it similar to the "family" image above. 14 00 makes the image cover the entire screen. Most of the strings uses 64 00 and 14 00 except the code section above and Bock 1F40-226F.
I think the first BD 0B controls the NCGR and the second one controls the NCLR used but I'm not completely sure.

Any help would be greatly appreciated!

Sorry to get off topic, but what do you intend to do in the game? I would like to create a discord server to gather people who like this specific game to gather media and lost media as well as try to hack the game

 

[ami-chan]

Sorry to get off topic, but what do you intend to do in the game? I would like to create a discord server to gather people who like this specific game to gather media and lost media as well as try to hack the game

Just wanted to back up all the cg/backgrounds used in the game along with seeing if there is anything left behind. Made thread intially cause I was just a bit lost plus there are a ton of files inside nclpack and ncgpack (thought bgdata.dat might help give me a slight clue but kinda stopped a few days after this thread).

Anyway, am interested in this discord server.

 

[FAST6191]

Why discord and not the perfectly usable forums that might be discovered by those browsing the internet one day?
I don't get the desire to have things like this on discord at all.

 

[BattleLegendRed]

Why discord and not the perfectly usable forums that might be discovered by those browsing the internet one day?
I don't get the desire to have things like this on discord at all.

Can I create a Post here to get people together to browse all sorts of media for this game? Isn't it against the rules?

 

[FAST6191]

Including files gets tricky (especially if you can essentially rebuild the ROM and it is not related to what you are specifically doing) but a thread along the lines of
Theresia: Dear Emile
[Listing of files contained within the game]. In this thread we are pulling apart this game to see how it works, what files are responsible for what, and make listings of the formats, specifics of the code handling and whatever else

That is is something that has been done on this and a dozen other forums, wikis and whatnot for decades now.
https://datacrystal.romhacking.net/
https://wiki.tockdom.com/wiki/Main_Page
https://wiki.multimedia.cx/index.php?title=Category:Game_Formats
http://wiki.xentax.com/index.php/Game_File_Format_Central
https://www.pokecommunity.com/forumdisplay.php?fn=rom-hacking-center
https://forums.serenesforest.net/index.php?/forum/8-fan-projects/
https://www.smwcentral.net/?p=memorymap&game=smw&region=rom
https://forums.warsworldnews.com/viewtopic.php?t=14246
http://jul.rustedlogic.net/forum.php?id=37
https://forums.therockmanexezone.com/guides-research-f10/
https://nsmbhd.net/
This list can go on for a long time but I hope the point is made, see also the dates on some of those.

and that is also ignoring the far more questionable disassemblies and decompilations.

Does not have to be on this site (certainly welcome to though) but I would suggest something other than discord as nobody will find discord just randomly, it is a friction to join (though same might be said about forums, wikis and such and maybe they already have an account), and when Discord goes pop as all other proprietary chat protocols have before it, or you get banned because you can't run your own servers and Discord have a history of dubious moderation you had better hope someone backed it up.