I already try this way, but I will retry for you. And here's the result:
I precise something important I used crytaltile2 to extract the file 0.bar from a nds rom and here's the list of file:
I precise something important I used crytaltile2 to extract the file 0.bar from a nds rom and here's the list of file:
I have seen things with the extension .bar in several games*, and they were often different. While probably not as obvious as .bin or .arc or something it is still up there with obvious extensions of things to pick.
To that end you are going to have to analyse it yourself and figure out what goes.
*one had bar as a sound archive but as I am seeing a reasonable size sdat there I don't know what to think. I have seen mixed sound format games before.
To that end you are going to have to analyse it yourself and figure out what goes.
*one had bar as a sound archive but as I am seeing a reasonable size sdat there I don't know what to think. I have seen mixed sound format games before.
Analyse the hexadecimal code ? I don't kow how to do this.
And my goal is about find a formula. Damage formula like pokemon. And find sprite, I want most of the sprite use in this game.
I already extract the sdat sound file and it contain ALL SOUND FILE from the game, I listened every single tracks and there was all here in just sdat file.
So I think that the bar file contain the rest of the ressources(like sprite for example).
If you can get the game working in an emulator you can probably rip the sprites from that if you just want them. Use cheats to make sure you don't fail in the game and get through quickly and you can get most things easily enough.
I mainly mentioned the sound as an example of how things can vary, though if all the sound is in the other files then that helps narrow things down more.
Damage formulas is usually something I would learn from play, or from debugging. Technically you could learn it from files (it would almost certainly be in the ARM9.bin or an overlay file though rather than any BAR stuff, at best the BAR stuff would contain the initial stats it uses) but that is not something I would do lightly and if you are shying away from pulling apart an archive.
Anyway pulling apart archives is not usually so bad. They tend to have a start, maybe some names, maybe some locations or file sizes and the the files themselves. Compare big ones and small ones to see what differences there might be. If you see a file type you know in there (in the other parts I see a narc file so probably uses something known elsewhere) when scanning through with a hex editor note where it is and see if any numbers at the start make more sense than they initially did.
Post a picture of the hex editor with one of the BAR open in it, or copy and paste a sample, and we might be able to give some assistance.
I mainly mentioned the sound as an example of how things can vary, though if all the sound is in the other files then that helps narrow things down more.
Damage formulas is usually something I would learn from play, or from debugging. Technically you could learn it from files (it would almost certainly be in the ARM9.bin or an overlay file though rather than any BAR stuff, at best the BAR stuff would contain the initial stats it uses) but that is not something I would do lightly and if you are shying away from pulling apart an archive.
Anyway pulling apart archives is not usually so bad. They tend to have a start, maybe some names, maybe some locations or file sizes and the the files themselves. Compare big ones and small ones to see what differences there might be. If you see a file type you know in there (in the other parts I see a narc file so probably uses something known elsewhere) when scanning through with a hex editor note where it is and see if any numbers at the start make more sense than they initially did.
Post a picture of the hex editor with one of the BAR open in it, or copy and paste a sample, and we might be able to give some assistance.
I don't know how to debug anygame, I think i should use another version of no$gba
I already start to take many screeshot of teh game to get sprite, but I don't think it's an efficient way to get them so that's I was wondering for a faster way to get all of them.
here's the hexedit: or 0.bar the hugest bar file in the nds file
I already start to take many screeshot of teh game to get sprite, but I don't think it's an efficient way to get them so that's I was wondering for a faster way to get all of them.
here's the hexedit: or 0.bar the hugest bar file in the nds file
Attachments
Last edited by bosskay,
Emulators will have a tile viewer to save you having to cut them out of screenshots. Depending upon how the game works (and if there is some kind of bestiary or library then so much the better, not to mention you can use cheats to speed things up if not).
Loading a savestate in a tile viewer might also get you something.
Beyond that then yeah you get to figure out the formats. If you only want to rip then you can spare hunting for the palettes if you want as emulators will give you those (as well as a tile viewer you should also have some options to export them), if you want to edit or change things then palettes tend to help with that one.
You might not even need to know the formats -- if the BAR files are simple archives (more on that in a bit) then who cares and you just load them up in a tile editor and see what you can see.
That BAR file. That looks like a series of pointers to me -- each pair of numbers (might have to flip them) appears to be increasing in size each time.
Quick test. If you go to 03d7 (the address column is on the left in case you were unaware, though it might say 03d0) what do you see? What happens if you go to 07EC (which would be the next value in the list if that is what I think it is)? Now 09E8, 0B91?
Loading a savestate in a tile viewer might also get you something.
Beyond that then yeah you get to figure out the formats. If you only want to rip then you can spare hunting for the palettes if you want as emulators will give you those (as well as a tile viewer you should also have some options to export them), if you want to edit or change things then palettes tend to help with that one.
You might not even need to know the formats -- if the BAR files are simple archives (more on that in a bit) then who cares and you just load them up in a tile editor and see what you can see.
That BAR file. That looks like a series of pointers to me -- each pair of numbers (might have to flip them) appears to be increasing in size each time.
Quick test. If you go to 03d7 (the address column is on the left in case you were unaware, though it might say 03d0) what do you see? What happens if you go to 07EC (which would be the next value in the list if that is what I think it is)? Now 09E8, 0B91?
The only emulator that can run DSiware game is No$GBA actually, and I don't know if it's possible to get a tile viewer in the emulator, and I dont even know if any cheat exist for this game(I don't think so)
Which tile editor ? Any of them ?
I don't really understand what are you asking me :/... Should I check this type of information in the same time that I playing ? In this case I don't really know how to do that, BUT I download the no$gba debugger and maybe this kind of thing could talk to you:
Is it the right direction ?
Crystaltile2, tiled2002 (though it struggles with some of the big dimension backgrounds) and tiledggd ( https://www.romhacking.net/utilities/646/ ) are all good tile editors. Some older tile editors will not do the GBA8bpp format (limited to just 4bpp) so I tend not to suggest them for anything DS related.
no$gba debug should have some nice viewers for the things in the video memory. I do like desmume's a bit more for some things but no$gba always did fine when I wanted it.
As for the addresses then I saw you had already opened the file in a hex editor. Open it again back in the hex editor (no emulator needed) and go to the locations mentioned in the previous post -- the start of most archive files usually describes all the files to come (maybe how many files there are, possibly sizes, names, any additional info/formatting) and that one looked like the most basic take it by being a list of locations of the files. However as I don't have it in front of me to test with I had to get you to have a look to see what is there (and possibly another picture of the things just above and below that address*)
*I would be looking for things like the numbers I tweaked to give those suggestions above to end and instead it starting to look like a normal file.
no$gba debug should have some nice viewers for the things in the video memory. I do like desmume's a bit more for some things but no$gba always did fine when I wanted it.
As for the addresses then I saw you had already opened the file in a hex editor. Open it again back in the hex editor (no emulator needed) and go to the locations mentioned in the previous post -- the start of most archive files usually describes all the files to come (maybe how many files there are, possibly sizes, names, any additional info/formatting) and that one looked like the most basic take it by being a list of locations of the files. However as I don't have it in front of me to test with I had to get you to have a look to see what is there (and possibly another picture of the things just above and below that address*)
*I would be looking for things like the numbers I tweaked to give those suggestions above to end and instead it starting to look like a normal file.
Hmm. Looks like it is still counting up in each of those (just some of the 00s are now filled as it presumably got past FFFF and needed more space to go into). Such things happen often enough in this sort of thing.
My next step would be to go find the end of the counting up sequence, wherever that may be*, and then try those numbers again.
*hopefully you see the pattern in the images above where it is ?? ?? 02 00 and then ?? ?? 02 00 where the second set of ?? ?? (assuming you read it backwards as it were**) are bigger than the first. Then the same thing but with 03, 04 and finally 06 in the last one.
I don't know where it will end up but it the pattern you see there will likely continue for a while and then stop and do something else -- I have some super scientific methods for pulling apart formats but often it comes down to "looks different" or "pattern stops".
**technically you want to do a 32 bit flip as the way the DS CPU works means it prefers numbers in that order. I don't know if that editor has the function though.
My next step would be to go find the end of the counting up sequence, wherever that may be*, and then try those numbers again.
*hopefully you see the pattern in the images above where it is ?? ?? 02 00 and then ?? ?? 02 00 where the second set of ?? ?? (assuming you read it backwards as it were**) are bigger than the first. Then the same thing but with 03, 04 and finally 06 in the last one.
I don't know where it will end up but it the pattern you see there will likely continue for a while and then stop and do something else -- I have some super scientific methods for pulling apart formats but often it comes down to "looks different" or "pattern stops".
**technically you want to do a 32 bit flip as the way the DS CPU works means it prefers numbers in that order. I don't know if that editor has the function though.
So 0F60. I agree that looks like the end of the pattern for this file.
In that case what is at 1C97 (that is 0F60+0D37)? Does it looks like a break between files?
After that you can try 174C (that is 0F60+07EC).
1948 is next if the pattern holds (that is 0F60+09E8).
See where we are going from here?
If is the format the game uses then I can make a simple script with a program called filecutter to rip all the files into individual components. If you just want simple then you can delete everything before 0F60 and at that point everything will "line up" as it were.
If not there are a few other things to try/look at. We would also then have to look at other files to see what happens for them. I am also slightly curious as to why there are no values indicating how many pointers (or indeed files) there are in that but it is not mandatory so eh.
You can also try viewing the tiles at 0F60 in a tile editor -- that does not look compressed (way too many repeated values) and does not look random enough to be text (again too many repeated values, nothing that would plausibly be a space) so might be some graphics of some form. Remember to try both 4bpp GBA and 8bpp GBA in the settings for them (tiledggd does things slightly differently).
In that case what is at 1C97 (that is 0F60+0D37)? Does it looks like a break between files?
After that you can try 174C (that is 0F60+07EC).
1948 is next if the pattern holds (that is 0F60+09E8).
See where we are going from here?
If is the format the game uses then I can make a simple script with a program called filecutter to rip all the files into individual components. If you just want simple then you can delete everything before 0F60 and at that point everything will "line up" as it were.
If not there are a few other things to try/look at. We would also then have to look at other files to see what happens for them. I am also slightly curious as to why there are no values indicating how many pointers (or indeed files) there are in that but it is not mandatory so eh.
You can also try viewing the tiles at 0F60 in a tile editor -- that does not look compressed (way too many repeated values) and does not look random enough to be text (again too many repeated values, nothing that would plausibly be a space) so might be some graphics of some form. Remember to try both 4bpp GBA and 8bpp GBA in the settings for them (tiledggd does things slightly differently).
1C97: (weird sequence, i don't know if it's a end of file)
174C: (this one really look like an end of file)
1948:
How I suppose to found something in this mess x) ?? (crystaltile2 > tile viewer)
I try to handle crystaltile with your advise but it's a little bit hard for now
174C: (this one really look like an end of file)
1948:
How I suppose to found something in this mess x) ?? (crystaltile2 > tile viewer)
I try to handle crystaltile with your advise but it's a little bit hard for now
Crystaltile2 should have a bunch of options down the left hand side like magnification (will be a percentage), tile size, row size and whatever else. Towards the end there will be a format and that will allow you to select GBA 4bpp and GBA 8bpp (that one looks like a 1bpp format of some form so look for that phrase in there to get given options).
Those would appear to be good candidates for end of file, though I am also unsure about the very first one*. I was kind of hoping we would see some kind of known DS format in that (or another BAR file) so we can confirm it (all those nice formats https://www.romhacking.net/documents/469/ tend to have file size contained within them and start in predictable ways).
*sometimes the first value in a pointer era is how many files it contains, when the end of the sequence/section is or something similar which means if you treat it as a pointer it might lead you astray. As it is not a pointer we are left with file count and 0F60 is a massive number (better part of 4000 files) which is not the case here as there are not even 500 entries to correspond to files.
Those would appear to be good candidates for end of file, though I am also unsure about the very first one*. I was kind of hoping we would see some kind of known DS format in that (or another BAR file) so we can confirm it (all those nice formats https://www.romhacking.net/documents/469/ tend to have file size contained within them and start in predictable ways).
*sometimes the first value in a pointer era is how many files it contains, when the end of the sequence/section is or something similar which means if you treat it as a pointer it might lead you astray. As it is not a pointer we are left with file count and 0F60 is a massive number (better part of 4000 files) which is not the case here as there are not even 500 entries to correspond to files.
I don't really know how to access to CrystalTile advanced functionnalities as GBA 4bpp/8bpp, but it's not a shame if I can get all the sprite. I actually aklmost finished all my screenshot, and it's for me. I want to focus on the way to get the calculation that compute the damage taken by a monster when it hit, or the hit rate for example. you said that all of this type of calculation is contains in the arm9.bin.
Then I did some research on it, and I found this:
https://gbatemp.net/threads/unpacking-arm9-bin.147251/ → in this topic someone say that: "arm9.bin is not a pack, it's the game's executable code. There are usually blocks of data embedded into it, but no distinct "files"." So it's a king "executable code"
So my question is the same, how is it possible to convert arm9.bin to a language that I can understand(like C++ or C or assembly language).
So here's a topic that's talk about it(this guy have litteraly the same goal as me):
https://gbatemp.net/threads/anyone-could-explain-me-how-to-edit-a-decompressed-arm9-bin.483240/ → but on this topic, the answer isn't interesting because it diverge a lot from the question.
I push my research a little bit and I found this: IDAPRO.
https://www.hex-rays.com/products/ida/ → on this link they explain that they could traduct binary sources to asembly language then C language.
I search a lot about it and weirdly there is no many post about it, so I don't think it's bring solution or it's just difficult to get the software.
So my question is, is it possible to translate the entire code of arm9.bin to a readable language for human ? Or just extract some part of the binary code and then translate them ? And is IDAPRO could answer to my expectation in this case ?
Then I did some research on it, and I found this:
https://gbatemp.net/threads/unpacking-arm9-bin.147251/ → in this topic someone say that: "arm9.bin is not a pack, it's the game's executable code. There are usually blocks of data embedded into it, but no distinct "files"." So it's a king "executable code"
So my question is the same, how is it possible to convert arm9.bin to a language that I can understand(like C++ or C or assembly language).
So here's a topic that's talk about it(this guy have litteraly the same goal as me):
https://gbatemp.net/threads/anyone-could-explain-me-how-to-edit-a-decompressed-arm9-bin.483240/ → but on this topic, the answer isn't interesting because it diverge a lot from the question.
I push my research a little bit and I found this: IDAPRO.
https://www.hex-rays.com/products/ida/ → on this link they explain that they could traduct binary sources to asembly language then C language.
I search a lot about it and weirdly there is no many post about it, so I don't think it's bring solution or it's just difficult to get the software.
So my question is, is it possible to translate the entire code of arm9.bin to a readable language for human ? Or just extract some part of the binary code and then translate them ? And is IDAPRO could answer to my expectation in this case ?
The tile editing stuff should not be that troubling to use. There are some odd options but all the basics should be pretty out in the open and no "have to select the right layer and select the region" like a big boy image editor.
Crystaltile2 has a disassembler, and that earlier no$gba shot before you went back to the hex editor was also a disassembler (in this case a live one made during runtime so you know you are in the right mode at least).
idapro will also do it, though I don't think the free version does ARM.
Simple conversion does not exist really. Any disassembly you might have seen like the pokemon ones, mario ones, sonic ones and the like are the product of a lot of work, and I doubt we will see anything like the decompilation stuff we saw for Mario 64 a little while back in the near future. Even getting a disassembly you can simply assemble and be left with a working game is a feat.
For damage algorithms though you would not really need all that. Start with cheats and work backwards from there -- you have to pick your target (you or the enemy in the game depending upon what you are looking for)
Now find where their health is in RAM (basic do damage, search, do damage, search... type cheat finding method. For the GBA but covers good stuff https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial if you or someone else reading needs something. https://doc.kodewerx.org/hacking_nds.html covers the DS codes.
Once you have the health you are most of the way there. Anything that harms the health will do so following a calculation on it.
Two main choices. You will be playing with the debugger at this point.
1 you set a break on read so if the game reads it before it does the calculation (99% of the time it will but there are some exceptions) you get to follow all the next steps as to what it does. Alternative is set a break on write so when it writes back the health value you look back up to see what was done.
Rinse and repeat understanding what each variable is (might be luck, might be your atk/def and on and on) until you can write the equivalent of https://www.dragonflycave.com/mechanics/gen-i-capturing but for this game. Assembly, especially on RISC processors, is long winded and tedious (everything is little tiny steps towards a goal rather than some nice maths, or even some of the stuff you see in C) but it will get you there.
Crystaltile2 has a disassembler, and that earlier no$gba shot before you went back to the hex editor was also a disassembler (in this case a live one made during runtime so you know you are in the right mode at least).
idapro will also do it, though I don't think the free version does ARM.
Simple conversion does not exist really. Any disassembly you might have seen like the pokemon ones, mario ones, sonic ones and the like are the product of a lot of work, and I doubt we will see anything like the decompilation stuff we saw for Mario 64 a little while back in the near future. Even getting a disassembly you can simply assemble and be left with a working game is a feat.
For damage algorithms though you would not really need all that. Start with cheats and work backwards from there -- you have to pick your target (you or the enemy in the game depending upon what you are looking for)
Now find where their health is in RAM (basic do damage, search, do damage, search... type cheat finding method. For the GBA but covers good stuff https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial if you or someone else reading needs something. https://doc.kodewerx.org/hacking_nds.html covers the DS codes.
Once you have the health you are most of the way there. Anything that harms the health will do so following a calculation on it.
Two main choices. You will be playing with the debugger at this point.
1 you set a break on read so if the game reads it before it does the calculation (99% of the time it will but there are some exceptions) you get to follow all the next steps as to what it does. Alternative is set a break on write so when it writes back the health value you look back up to see what was done.
Rinse and repeat understanding what each variable is (might be luck, might be your atk/def and on and on) until you can write the equivalent of https://www.dragonflycave.com/mechanics/gen-i-capturing but for this game. Assembly, especially on RISC processors, is long winded and tedious (everything is little tiny steps towards a goal rather than some nice maths, or even some of the stuff you see in C) but it will get you there.
Similar threads
-
-
-
-
@
The Real Jdbye:
don't mind me, just liking all of SDIO's posts, they deserve it for https://gbatemp.net/threads/usb-partition-use-partitioned-usb-hdds-with-the-wii-u.656209/ -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
@
BigOnYa:
Kinda silly. But cool I guess. Its like painting your 2by4 wood studs in a wall, before covering with drywall.+1 -
@
BigOnYa:
I heard a good one at the bar last night, made me think for sec. - "If you are cold, go stand in the corner, because corners are always 90 degrees."+2
-
-
-
-
-
