Author
|
Topic: Help wanted with GBA vwf (Read 4087 times)
|
Cless
Guest
|
 |
« Reply #75 on: January 23, 2007, 02:07:15 pm » |
|
No. Knowing what an instruction does is the easy part, usually. Though there a small syntax thing or two that confuses me sometimes...
I have a great deal of difficulty understanding the big picture; what it's doing in the long run and why it's doing that.
I also have a lot of trouble with emulator debuggers... the ones I've tried don't seem to even come with any documentation at all about how to use them.
|
|
|
|
|
Kajitani-Eizan
Guest
|
|
« Reply #76 on: January 23, 2007, 05:03:10 pm » |
|
i'd say my issue is with the pre/post conditions, basically. where is the original routine? where are things in memory? what registers am i supposed to use? etc.
seems to me that once you have all that information, coding the thing is actually (relatively) easy...
|
|
|
|
|
KaioShin
Guest
|
|
« Reply #77 on: January 23, 2007, 05:19:13 pm » |
|
i'd say my issue is with the pre/post conditions, basically. where is the original routine? where are things in memory? what registers am i supposed to use? etc.
seems to me that once you have all that information, coding the thing is actually (relatively) easy...
You can use all registers, you can always push the old values onto the stack and pop them back once you're done. Finding the original routine is just a matter of using a breakpoints, if you have it and you understand it somewhat you get the needed memory addresses for free with it. |
|
|
|
|
Tauwasser
Guest
|
|
« Reply #78 on: January 24, 2007, 06:37:47 am » |
|
Well. If the original routine doesn't use any RAM at all (because it wouldn't need to) besides the tile# and source character, then you need to find a different offset, in your example it's 2005000 and 2005001 that you use. I don't know if you just randomly picked the values, however, if so, then how were you sure you didn't overwrite something?
cYa,
Tauwasser
|
|
|
|
|
KaioShin
Guest
|
|
« Reply #79 on: January 24, 2007, 07:08:14 am » |
|
Well. If the original routine doesn't use any RAM at all (because it wouldn't need to) besides the tile# and source character, then you need to find a different offset, in your example it's 2005000 and 2005001 that you use. I don't know if you just randomly picked the values, however, if so, then how were you sure you didn't overwrite something?
cYa,
Tauwasser
They are randomly picked. At the beginning of the game were I do all my testing the complete SlowRAM (2xxxxxxxx range) is more or less completely empty. I'm pretty sure that part may be overwritten sometime along the game, but it's only a matter of changing the define value and reassembling to change that then. When that happens RAM should be more filled and it will be easier to find a place which actually stays empty. There is a bug with the world map having flickering problems suddenly, that might already be a effect of RAM conflicts. |
|
|
|
|
Nightcrawler
Guest
|
|
« Reply #80 on: January 24, 2007, 09:06:47 am » |
|
I don't know how GBA games are, but I generally have the best luck picking the very end of the addressable RAM region on the SNES. Few games I've seen on that platform utilize RAM all the way to the end.
|
|
|
|
|
KaioShin
Guest
|
|
« Reply #81 on: January 24, 2007, 02:30:02 pm » |
|
I want to expand my vwf to the 8x8 font used in battles and menus now and there is a little potential problem (I say portential because I haven't tried yet and I often see problems where there aren't any).
In the core, adding support for 8x8 is a joke, I just have to change the loop which goes over 16 rows to 8 and that's it. The problem is related to the script formatting and to the end of lines / words. Right now, I added code to the control code which jumps to a new line and the one whcih scrolls the text, to print the spill over before changing lines. Otherwise there is the problem of unfinished letters at the end of lines. For dialogues this is no problem of course.
However, in menus, there are no end of line control codes and stuff used. The different lines are tilemapped - so, how do I handle this, how can I do it that every menu option is printed completely, and not just half of the last letter. I don't know yet what will happen if I insert some end of line control codes there, but I doubt it's good. The only idea I had was to create a new control code, which prints out the remaining spill over - but doesn't do anything else. However, I don't know if I can do that, the code which handles the control codes looks very very complex, used jump tables and stuff embedded in code, if I add anything to that it will overwrite stuff and shit :p
Any advice, experiences?
|
|
|
|
|
Tauwasser
Guest
|
|
« Reply #82 on: January 24, 2007, 03:38:28 pm » |
|
Well. You might want to check, whether menus are created all thru one or two routines. If so, then you can just replace the routine, that calls the text routine to first reset the counters 2005000/1 and then proceed (also increase tile counter or whatever else needed), so that would then work in most of the menus that use the generic routine.
That's how I always handled such things. Of course for gb games it's totally different because you cannot anticipate much because of room problems and no 'identifiers' for different ingame situations.
cYa,
Tauwasser
|
|
|
|
|
KaioShin
Guest
|
|
« Reply #83 on: January 24, 2007, 03:47:25 pm » |
|
Well. You might want to check, whether menus are created all thru one or two routines. If so, then you can just replace the routine, that calls the text routine to first reset the counters 2005000/1 and then proceed (also increase tile counter or whatever else needed), so that would then work in most of the menus that use the generic routine.
That's how I always handled such things. Of course for gb games it's totally different because you cannot anticipate much because of room problems and no 'identifiers' for different ingame situations.
cYa,
Tauwasser
Hm, I'm not sure if such a routine exists in this game. The game just draws every menu string in VRAM in one single ine and produces the line breaks simply though the tile map - afaik there is no routine involved in this I could change. |
|
|
|
|
Nightcrawler
Guest
|
|
« Reply #84 on: January 24, 2007, 05:56:43 pm » |
|
I think you answered your own question. You can add a new control code to handle end lines. That's probably the easiest option.
This control code will only be processed by your routine. The game shouldn't know it's there if you plan it out good. Use a 'standard' value that appears as a normal letter to the game. When it gets to your routine, you do your thing and print the spillover and nothing else. As far as the game is concerned, nothing has changed.
|
|
|
|
|
KaioShin
Guest
|
|
« Reply #85 on: January 24, 2007, 05:59:17 pm » |
|
This control code will only be processed by your routine. The game shouldn't know it's there if you plan it out good. Use a 'standard' value that appears as a normal letter to the game. When it gets to your routine, you do your thing and print the spillover and nothing else. As far as the game is concerned, nothing has changed.
Ohhhhh, you are so damn right, how couldn't I think so far >_< I don't have to mod the original games code at all ... Thanks, all the knowledge is there, but sometimes you don't see the tree within the wood. |
|
|
|
|
DaMarsMan
Guest
|
|
« Reply #86 on: January 24, 2007, 11:08:01 pm » |
|
This is how I do 90% of my double line hacks. I just pick a new hex value, add a check for it at the appropriate location and the rest is pretty simple.
|
|
|
|
|
|
RHDN Forum Archive
