News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Gyroballer

Pages: [1]
1
Newcomer's Board / Understanding NES text routines
« on: February 20, 2019, 11:12:05 pm »
Hey there,

I know I recently translated DBZ II for the Famicom, and while I do know some stuff about computer science, etc., I'm having trouble with rom hacking a lot of games.

If the text is stored like DBZ II, where it's mostly character for character in the rom and there are few dictionary entries, I don't have much trouble. But I don't even know where to begin or how to understand what's going on if I can't find a string of characters like the basic tutorials say.

I'm assuming that means the text is somehow compressed. Is DTE really common on the NES or are there other things for me to look out for? How do I know which one I'm dealing with and from there, how do I go about editing the in-game text?

Thanks for your help with this noob question.

2
ROM Hacking Discussion / DBZ2 (FC/NES) - Write on [han]dakuten Line
« on: February 09, 2019, 07:41:48 am »
Hey, all. I'm wrestling with textbox space contraints on DBZ2 for the Famicom/NES.

It definitely works very similar to DBZ1,3,Gaiden that RedComet and company worked on.
I looked at his ASM source code and for now just added the dbz1vram.asm in blank space in the rom and changed pointers to the old text routine to his hack.
The text still writes well, but only on every other line instead of taking advantage of the dakuten/handakuten space.

If I change one of the vram_access_1 function to load accumulator with $0605 ([han]dakuten area), then my text will display in doubles (each character concurrently, not alternating handakuten line and main line by either characters or line) on the normal line and the line above, but it will create graphical glitches as well.


For example, it might look like this normally:


But like this (along with slight graphical glitches)
if I edit lda $0604 -> lda $0605:


Of course, I'd like it to look like this
(Directly edited PPU mem for mockup):



Code in question:
Code: [Select]
vram_access_1:
lda $0604,x ;This will read in the dakuten/handakuten information from RAM,
sta $2007 ;and load it into the nametable.
inx ;Increment X so the base character will be read next.
dey

vram_access_2:
lda $0604,x ;This loads the base character into the nametable on the line
sta $2007 ;below the previously loaded dakuten/handakuten.
inx
dey
bne vram_access_1 ;if (y != 0) {goto vram_access_1;}
;This won't happen when dealing with displaying text.


This is the closest I've come to progress. What I want is for it to alternate, starting with [han]dakuten and then base, repeating, instead of cloning base up to [han]dakuten. But if at all possible, I want all of the text to be read from the base ($0604).

What's the best way of doing this? Presumably this routine already alternates but simply grabs blank characters/spaces.

Additionally, I've been having some other troubles. I've been doing everything manually and it feels tedious since I know there are better ways to do things.

For instance, I'm manually hex editing (with tables) the script when I make a change. I've successfully dumped it without pointers with Cartographer, but I don't understand how to safely change it and reinsert it with Atlas.

This goes for testing RedComet's ASM hack as well. I had to go into DBZ1 translated and look for the routine, copy the hex values using FCEUX's hex editor, and then paste them into blank space (FFs) in a valid bank on the rom (that took me forever to find in DBZ2 -- seemingly little free space).

I've also had to manually find the pointer tables (although they're typically right above a wall of text), and manually discover their internal logic, but I've yet to come up with a tried and true "formula" for it. I take care to subtract 10 for the header in general, but the pointer table might ignore the first byte out of a 2 byte address (like if the text is at 0174BC, I'd assume the pointer will be somewhere looking like AC74, but instead there may be a value before or after AC that isn't 74 -- something to do with reading it from RAM instead of the ROM?).

Finally, for the vast majority of the script, being able to write on the [han]dakuten lines will give me effectively double the space, especially since I can take advantage of pointers, but it's possible that a text-heavy area would require a lot of pointer maintenance or even just not be possible to fit in its current bank, etc.
What would I do in that situation?
Expand the ROM? I tried this and couldn't access more than the normal amount of banks anyway.
Would I need to go with a dictionary/compression method? Any suggestions if so?

I could definitely use some direction in general, and I appreciate any help you can give this novice lol.

Pages: [1]