Author
|
Topic: Defining text position on GBA (Read 477 times)
|
stev
Guest
|
 |
« on: May 30, 2007, 02:11:26 am » |
|
I'm pretty new to ROM hacking, but thanks to this site, I've already learned how to make tables and hack pointers in GBA. This is my first post on the forum, so first I'd like to say hey to you all! Anyway, I'll get to my question.
Pointer definition for GBA ROMs seems straightforward and universal, so I am curious if there's also a standard way to define the starting position of text? I'm tinkering with the possibility of doing some ROM translating and this would come in handy for positioning text in situations where it's not in a text box (like for a prologue).
Any explanations or links to any helpful docs would be appreciated.
|
|
|
|
|
Kajitani-Eizan
Guest
|
|
« Reply #1 on: May 30, 2007, 03:07:17 am » |
|
it will often be done with a move command in assembly. get the VBA tracer program and trace what you want to edit. if you find a move command that uses a value like, say, 3, if the message is being printed on the third tile of the screen, try changing that 3 to some other value and see if that affects where the text is positioned when you run the game. if so, success. if not, change it back and try another one, or try to actually figure out what the code is doing. remember to also look for values plus or minus 1 from the one you might expect. for example, if it looks to be the third tile onscreen, it could potentially be stored internally as 2 or 4.
|
|
|
|
|
Tauwasser
Guest
|
|
« Reply #2 on: May 30, 2007, 03:46:41 am » |
|
There is no standard way of doing that. One possibility is x/y which is often used. Another is direct tilemap offset. Then you also need to take into account that some games use the vram location also as tilemap location. Meaning for one layer every tile is in vram and you just need to write to vram to make the tiles appear where they should be.
cYa,
Tauwasser
|
|
|
|
|
stev
Guest
|
|
« Reply #3 on: May 30, 2007, 11:18:53 pm » |
|
So, I checked out the VBA debugger and I tried logging when the text came up. WOW, I maxed out the 20,000 instruction limit I set! I found some values set within the "mov" command that matched the possible text offset, but all the ones I tried changing didn't do anything and there are WAY too many. I think I will definitely have to learn assembly if I wish to make these changes. It's better than guess and check for weeks and weeks.
I see that there are many assembly docs on the site and I'll have to check those out, but there's one thing I'm wondering about. What do you do to actually display the source code in a readable format? Yeah, I know it's assembly so it's not going to be THAT readable, but I doubt anyone is code hacking in a hex editor.
Thanks for the help. I realize I'm in for a long haul if I decide to edit code, but I'm cool with that.
|
|
|
|
|
DaMarsMan
Guest
|
|
« Reply #4 on: May 30, 2007, 11:53:50 pm » |
|
Assembly is pretty readable once you get used to it. Find out how a gba write to the screen. Buy no$gba debugger and set a breakpoint. Then you will know where the text is coming from. Probably using DMA.
|
|
|
|
|
Spikeman
Guest
|
|
« Reply #5 on: May 31, 2007, 12:35:56 am » |
|
No$GBA is REALLY worth it, if not for the debugger, especially for the documentation. It has a pretty definitive help file on the GBA hardware and has cheatsheets on things like DMA. Really helpful.
|
|
|
|
|
KaioShin
Guest
|
|
« Reply #6 on: May 31, 2007, 05:13:41 am » |
|
It has a pretty definitive help file on the GBA hardware and has cheatsheets on things like DMA. Really helpful.
You don't have to pay for that it's freely available on the homepage http://nocash.emubase.de/gbatek.htm (and here in our archieve as well of course. I don't want to say the opposite of everyone else, but I would suggest against using tracelogs and use breakpoints instead. I never saw what's so great about looking through thousands of lines of code when a well-placed breakpoint gives you the right code spot on. |
|
|
|
|
Nightcrawler
Guest
|
|
« Reply #7 on: May 31, 2007, 07:39:49 am » |
|
A trace log gives you surrounding code right away. and can easily help give you a broader picture about what's going on in the code.
Is it better or worse than breakpoints? That depends on what you're doing. Example: Trace logs are probably better suited for decompression routines. A breakpoint can help you find one, but that's about it. you use trace logs when you're examining a routine.
|
|
|
|
|
KaioShin
Guest
|
|
« Reply #8 on: May 31, 2007, 10:38:56 am » |
|
I guess it's a work philosophy preference. I see what you mean about having a good overview, but I'm not good at learning with such a setup. I rather step through the code live in a debugger and see it. Of course it's exactly the same as in a trace, but seeing it in action gives me a different impression of the code somehow.
|
|
|
|
|
stev
Guest
|
|
« Reply #9 on: June 01, 2007, 12:35:52 am » |
|
Thanks I'll check out No$GBA when I really "get into it". Right now I'm just fiddling with the script with a hex editor and soon I'll deal with larger chunks with romjuice and atlas. I'm a little ways away from the fancy stuff.
|
|
|
|
|
|
RHDN Forum Archive
