I have searched online to find any documentation for Asphalt Urban GT, and there's none. I have looked at multiple guides and attempted to learn ARM assembly, but I feel like I'm missing something. Can someone please help point me to tools and resources for me to learn and document this? I remember seeing a file directory in the game, although I cannot access it as of now.I have little to no experience coding, so any advice would help.
- Thread starter dmannorflo
- Start date
- Views 584
- Replies 2
Heh. There were some that looked into this game before, though nowhere near to the level of something like Mario Kart.
I don't have things to hand to have the usual quick look over of the game (in this case it is an old game so in some ways more likely to do odd things as formats were not fully developed yet).
Anyway have you read https://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/ https://gbatemp.net/threads/the-ultimate-nintendo-ds-rom-hacking-guide.291274/ https://www.romhacking.net/start/
Pulling apart a game into its constituent files is usually not so bad. ndstool (frontends in dslazy and dsbuff), crystaltile2 (click on the little DS icon), nitro explorer 3, tinke and many more things will give you the option to do this.
From there the would be hacker is on his own give or take https://www.romhacking.net/documents/[469]nds_formats.htm http://wiki.xentax.com/index.php/Game_File_Format_Central and such like. You might try to find text with a relative search (if nothing else eliminating that file and maybe a whole directory of similar files as being a level or audio or something you care about for your hack), most DS games used the SDAT audio format ( https://gbatemp.net/threads/the-various-audio-formats-of-the-ds.305167/ ). Graphics might pop into plain or plain enough view with a tile editor, or you could snatch something from RAM when the game is running and search the ROM for that (not so useful on the DS as it uses a lot of compression, though worth a try, especially for palettes as little benefit to compressing those).
If you find say level files and they are all separate you might try swapping them around such that level 2 plays instead of level 3. At this point you know the level files have to contain the data used by the game to construct the level, and most times they are going to be fairly similar to the final result (why waste resources doing all kinds of silly conversions on a Read Only Memory/ROM that will be the same 10 years and 100 years from then?) so you can try to figure out the basics of the level (if 3d then probably going to be triangles and whatnot as per http://problemkaputt.de/gbatek.htm#ds3dpolygondefinitionsbyvertices , and maybe even mirroring it in the level data itself -- the 3d model of the level and the actual what is track/boost/wall/dirt/... data might be something else albeit following similar patterns). For 2d levels in some ways it is easier still (I do have an example in the guide above) as you are probably dealing in layers and you either have coordinates (this item at X, Y in the level) or the level itself is basically a say pixel/tile level chart of what appears where.
You can make some cheats ( https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial ) so try to explore aspects of the engine -- say you find the current speed (speed up, slow down, do searches using cheat engine throughout that), whatever alters the speed (which you can tell using a debugger breakpoint set to watch for writes, usually bpw aka breakpoint write in more debugger setups, the location of the speed will be a calculation involving acceleration (even if it is infinite) and thus you can alter the acceleration which might well change the game quite radically beyond what levels, text and graphics might do. There will probably also be something that controls the maximum speed (hopefully it is not as large as the game is programmed to handle -- if you ever wondered why many games use the otherwise random numbers of 32, 64, 255/256, 1024, 2048 and so forth as limits then that is because computers are binary and those are usually powers of 2 rather than powers of 10 from normal counting. You can get beyond these limits but it is quite annoying as you get to reprogram things to handle the new numbers and also will trouble multiplayer unless you are both using the same hack) and that might even read from a file within the ROM (think stats page).
All that is doable quite before you have to get really down and dirty with the game's code and most line by line/function by function/systematic analysis methods that have a fairly high barrier to entry, time requirements and are pretty tedious to boot.
I don't have things to hand to have the usual quick look over of the game (in this case it is an old game so in some ways more likely to do odd things as formats were not fully developed yet).
Anyway have you read https://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/ https://gbatemp.net/threads/the-ultimate-nintendo-ds-rom-hacking-guide.291274/ https://www.romhacking.net/start/
Pulling apart a game into its constituent files is usually not so bad. ndstool (frontends in dslazy and dsbuff), crystaltile2 (click on the little DS icon), nitro explorer 3, tinke and many more things will give you the option to do this.
From there the would be hacker is on his own give or take https://www.romhacking.net/documents/[469]nds_formats.htm http://wiki.xentax.com/index.php/Game_File_Format_Central and such like. You might try to find text with a relative search (if nothing else eliminating that file and maybe a whole directory of similar files as being a level or audio or something you care about for your hack), most DS games used the SDAT audio format ( https://gbatemp.net/threads/the-various-audio-formats-of-the-ds.305167/ ). Graphics might pop into plain or plain enough view with a tile editor, or you could snatch something from RAM when the game is running and search the ROM for that (not so useful on the DS as it uses a lot of compression, though worth a try, especially for palettes as little benefit to compressing those).
If you find say level files and they are all separate you might try swapping them around such that level 2 plays instead of level 3. At this point you know the level files have to contain the data used by the game to construct the level, and most times they are going to be fairly similar to the final result (why waste resources doing all kinds of silly conversions on a Read Only Memory/ROM that will be the same 10 years and 100 years from then?) so you can try to figure out the basics of the level (if 3d then probably going to be triangles and whatnot as per http://problemkaputt.de/gbatek.htm#ds3dpolygondefinitionsbyvertices , and maybe even mirroring it in the level data itself -- the 3d model of the level and the actual what is track/boost/wall/dirt/... data might be something else albeit following similar patterns). For 2d levels in some ways it is easier still (I do have an example in the guide above) as you are probably dealing in layers and you either have coordinates (this item at X, Y in the level) or the level itself is basically a say pixel/tile level chart of what appears where.
You can make some cheats ( https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial ) so try to explore aspects of the engine -- say you find the current speed (speed up, slow down, do searches using cheat engine throughout that), whatever alters the speed (which you can tell using a debugger breakpoint set to watch for writes, usually bpw aka breakpoint write in more debugger setups, the location of the speed will be a calculation involving acceleration (even if it is infinite) and thus you can alter the acceleration which might well change the game quite radically beyond what levels, text and graphics might do. There will probably also be something that controls the maximum speed (hopefully it is not as large as the game is programmed to handle -- if you ever wondered why many games use the otherwise random numbers of 32, 64, 255/256, 1024, 2048 and so forth as limits then that is because computers are binary and those are usually powers of 2 rather than powers of 10 from normal counting. You can get beyond these limits but it is quite annoying as you get to reprogram things to handle the new numbers and also will trouble multiplayer unless you are both using the same hack) and that might even read from a file within the ROM (think stats page).
All that is doable quite before you have to get really down and dirty with the game's code and most line by line/function by function/systematic analysis methods that have a fairly high barrier to entry, time requirements and are pretty tedious to boot.
Thank you! I have tried pulling the game apart, but looking back I really didn't. I definitely jumped into the deep end, so I will definitely try some of the things you suggested. If it's not much trouble to you, I would love to see other attempts into this game, as it would help a lot with documenting and learning about this game.
Similar threads
-
The Real Jdbye
*is birb*
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
@
NormalCatelol:
i know that there is a forum for this question but, what would you guys name the switch successor? -
-
-
-
-
-
@
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/
-
-
-
-
