Ugh, IDA, why are you ignoring the data bank register in this disassembly?? Maybe half the memory references in my disassembly are completely bogus because IDA "helpfully" mapped them into memory, but in the completely wrong place...
This is completely wrong! "word_7Fxxxx" should be "word_00xxxx" (or "word_7Exxxx", since memory is mirrored there for the first 0x8000 bytes).
I don't look forward to fixing all these auto-generated references...
I gave up and split the auto-generated WRAM segment from $7E0000-$7FFFFF into two segments from $7E0000-$7EFFFF and $7F0000-$7FFFFF. This way I can automatically fix references into the second bank instead of rewriting them all manually, and IDA will even keep track of the RAM address's name if/when I name them.
I also figured out that I can manually rewrite code instructions, so I can turn all the one-byte BRK instructions into actual BRK instructions!...that aren't actually marked as code. >.>;; Oh well, at least it will be less ugly this way...
Also I made the colors less terrible! ^^
https://awoo.space/media/uv_skK9lHh8vfeoay0E
Uhh... what... was even the point...
https://awoo.space/media/CWnt0g7eYH_YQJjUNoY
aaaaa IDA doesn't support Unicode comments ;~; I can't just type out the Japanese text into my database as comments...
I'm stuck... in subroutine hell... x.x
I've been tracing out one function for two hours and haven't even come close to finding the end of it... x.x
I think... I'm going to bed now... and then I'll start again in the morning... x.x
I just spent a few hours adding the district and shop names to our translation spreadsheet.
I feel accomplished. ^.^
Ack, our translation spreadsheet is so huge that I can't open it on my phone anymore... >.>;;;;;
Well, I found which memory address is used for indexing which dialogue line is spoken by AI players.
Unfortunately, because I didn't finish tagging things in my disassembly, I can't cross-reference where the breakpoint I set fired with it, because that section of code is untagged...
I guess I know what I'll be doing today.
Yeesh, this is... a lot of references to this memory address. >.>;;;
I certainly have lots of work left figuring things out...
Oh wow, this is neat.
So, when choosing AI characters you can play against, there are actually two different lines that can appear! I didn't notice that there were multiple lines until I was reading through what @WTCGames@twitter.com had translated so far.
If you choose most characters, you get the first line ("Player # will be ____, right?")... but if you choose Konomi, you get the second ("I'll join as player #, alright?")
I guess Konomi really does host the whole game!
Oh, I had more control codes implemented in my custom code than I thought... I guess I can actually insert some of this text then ^^
Writing a system for dynamically inserting text and automatically updating text pointers.
Using a disassembly would probably be easier, but... that requires a fully reassemblable disassembly...
I probably won't have much new to show on the IS2 project until this is working though. Sorry...! ^^;;;
Hmmm.... That's better, but... if what's causing this problem is what I think it is, I'll be very, very annoyed...
When IS2 draws a dialogue box on screen, it uses a particular 3-byte memory address for loading the window parameters from; and since all window parameters are in the same bank, it never updates the bank byte in that address.
I've moved all my custom code out into a new bank, though, including window parameters, so I have a hack in place that saves, replaces, and restores that bank byte when it loads custom text...
Except... the continue arrow also references those parameters, but the bank has already been restored when it tries drawing it, so it's using incorrect/invalid data when determining where it should draw that arrow.
I'll probably just have to find the continue arrow code and hook it somehow, just like my custom text code...
Yep, there's our culprit, just like I thought. That "func_SearchDialogDefinitionForA" call ends up going off into outer space instead of where it should be looking.
Hopefully copying and modifying this function won't be too hard...?
After two months of severe depression and no work on this project, I've finally gotten back working on the patcher.
I hate writing text parsers. x.x
I finished enough yesterday on stream that I can get a (mostly) working ROM using this! ^w^
Next will be adding additional definitions for all ... 2200+ ... dialogue lines... x.x
(If I was actually a decent coder, I would automate this. I am not, so I am doing it by hand. This is a terrible idea.)
Okay there is no way I'm doing this by hand. My wrists already hate me x.x
I'll ask @Xkeeper if they could do it for me instead with a PHP script or something...
Oh, bleh. A realization about character dialogue hit me...
There is a function used during character dialogue in-game that copies data from a temporary buffer into a particular location, which is read later when drawing character dialogue on-screen. This function only copies 64 bytes of data. (There might only even be 64 bytes of free space available in this location; I don't know for sure.)
That means that, unless all dialogue in our translation takes less than 64 bytes, I'll be rewriting this function call, and possibly be looking for extra empty space in RAM I can use for a text buffer instead of where IS2 usually reads from. :S
Annoying, but doable...
I also threw together a small tool for testing how dialogue will look before inserting it in-game!
You can play around with it here, if you'd like:
https://raspberry.rosenthalcastle.org/itadaki-street-2/bigtext-vwf.php