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. ^.^
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
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!
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...
This ... took way longer than it should have, but it's done enough that I can rebuild all the changes I wrote by hand using this patcher program. ^w^
I feel like adding new bits will go much faster now!
It was as if all of Itadaki Street was screaming in unison, in horror of what had happened to their game.
Then, calmly, everything returned to normal, almost like nothing out of the ordinary had ever happened.
Poking through system menu dialogue for Itadaki Street 2 tonight. This game does ... weird things sometimes... but at least I'm understanding better how its code is structured.
I don't even understand how I made this work, but I made it work...!
I can't do math today. 0x649F + 1 is not 0x649A... >.>;;;;;
Well... I have some things working that weren't before, now! ^w^ Almost all menu dialogue has been formatted and inserted, and things look pretty good!
flashing, glitchy graphics
And some other things, well... ... ... >.>;;;;;;;;
I still have lots of work left, I guess...
I've already fixed one of those bugs (extra spaces in names), which was caused because I didn't bugtest my code when I originally wrote my variable-width font code, and a register got clobbered. ^^;;;
The dialog boxes that I didn't recognize are actually character-specific dialogue that is in a different format from what the game expects there, so that's why they are completely broken. I'll look for those code references later, I guess...
And that flashy, glitch mess at the end... is probably caused by a bank value being wrong, and incorrectly-formatted, unterminated text being drawn, which overflows the tilemap into other parts of RAM, and eventually consumes the entire game...
I don't know exactly how I'll tackle that yet. .-.;;; It's part of a few lines that required extra work, so I left them out when formatting the rest of the menu text...
Well, I fixed what caused everything to break yesterday, and ran into a different, very annoying and also very strange bug:
When playing any game with an AI opponent, after that AI player says anything, the game clears completely wrong memory addresses when removing their dialogue box. This causes all sorts of problems, like corrupt tiles overwriting the map, the HUD disappearing, or the game soft-locking after displaying that dialogue box...
Nothing I added recently directly caused this; it is either a byproduct of something I added in my very first patcher build, or something related to how my patcher itself builds everything into the ROM.
My hand-patched build from months ago doesn't exhibit this bug, so I have no idea what is wrong...
Oh no... I isolated what is wrong here, and I am not happy at all...
It's another instance of this game always expecting its text to be in a very specific bank. It never, ever updates what bank it searches for dialog boxes in, only what address within that bank is being currently used.
That causes problems like this, where another function is looking for where it should draw (or, in this case, clear) a dialog box, but it runs off into who-knows-where and trashes memory...
It didn't happen in my hand-patched build because I hadn't moved any dialog boxes that called this function into expanded ROM space, and my code that handled AI dialogue used the original dialog box definition.
This is so frustrating...
I'm glad I documented what I was doing last here, because I hadn't marked down what needed changing anywhere else...
I'm exhausted today already, but I will try working on this later...
I finished fixing all the code that was calling the SearchDialogDefinition function last night, so ... now I have to go back through each dialog box call, and check the surrounding code for any of the old functions I just replaced, and repoint them properly...
... weh. Tedium. x.x;;
Awesome, rewriting everything that touched SearchDialogDefinitionForA fixed the corruption bug that was crashing games when AI characters said anything! ^w^
... aaaand I immediately found another corruption bug in a dialog window I didn't touch yet. >.<;;;
I don't even know how Konomi's face got corrupted...
Writing a function to center text, since the original function won't work with my new text format, or with a variable-width font...
The original code only used this centering function for displaying street names, but hopefully I can rework it so any arbitrary line of large text can be centered. We'll see... ^.^
It's so weird having code I write mostly from scratch work first try. ^w^
flashing glitches
... how do things like this even happen???
"Hmm, why is the vowel extender mark so short in this dialog box? Is there some bug with my text drawing code...?"
...
"wait a second... that's... not a chōonpu... that's a hyphen..."
Why yes, I've been having lots of fun with this project, why do you ask? >.>;;;
random glitch graphics
Ｅｖｅｒｙｔｈｉｎｇ ｉｓ ｆｉｎｅ， ｎｏｔｈｉｎｇ ｉｓ ｗｒｏｎｇ．．．
re: random glitch graphics, translation mishaps
This is what happens when you load up an invalid character ID, and the game tries decompressing random data for their character sprite.
Boom goes the tilemap. And most of WRAM.
While translating venture card-related text, I found a debugging feature left in the game ^w^
https://tcrf.net/Itadaki_Street_2:_Neon_Sign_wa_Bara_Iro_ni#Debug_Venture_Card_Function
okay, after FINALLY getting this code to work, after several hours' worth of debugging, and finding out that the original game's code makes an assumption that doesn't hold anymore with how my code works...
I can finally, finally insert new venture card text.
Itadaki Street 2 tidbit:
The Maharaja (bonus AI character who pays you if he lands on your shop) has his starting cash set to 0x7FFF7FFF (2,147,450,879 G). The game never deducts any of what he pays from his cash total, though, so he effectively has infinite cash. .w.
Another Ita2 tidbit:
There's a bit of unreferenced text near one routine that handles venture cards #61 and #62, which give stock dividends of 10%/20% normally. At first glance, though, this text seems like it would just print garbage tiles on screen...
It turns out this extra text is old enough that it expects a lowercase English font, which isn't in the final game anymore... and it also suggests you originally got paid a flat amount per stock share you owned instead!
In today's "why is this code making the game crash" adventures, spot the bug:
stack.push(tile_ID);
stack.push(tilemap_index);
stack.push(bank_number);
... // Run code here
stack.pull(tile_ID);
stack.pull(tilemap_index);
stack.pull(bank_number);
return;
... It's doing things in the same order! How can this code be broken...? ^^;;;;;
(I have since fixed this bug. ^.^)
Oof, I found at least four bugs in IS2 last night. One of them is a softlock present in the original game... .w.;;;
Spent a day or two this week figuring out what the Japanese bugfix hack for Itadaki Street 2 changed. Turns out there were some really obscure but very strange bugs in the game... .w.;;;
I can't wait to talk about these bugs I've been looking into in Itadaki Street 2, because some of them are very silly... Just have to find enough focus and mental energy that I can finish writing a post about them... .w.;;;
I haven't gotten around to writing another Patreon post in a while, because I've been working on things that aren't finished yet... .w.;;;
I'm kind of changing my workflow for the IS2 translation a lot! and it involves rewriting a bunch of the disassembly I had so it's compatible with a different program... but hopefully it will be done soon and I can ... maybe... get working on adding new things again soon... .w.;;;
@Raspberryfloof That's...unfortunate? Gosh.
Out of curiosity, are the bugfixes separable from the translation?
@BatElite Some of them are, but the way I implemented others would require me to change the implementation before they could be fully separated.
For example, one of them is a bug related to an unreachable textbox, but the text in that textbox is unterminated. The way I fixed it was by replacing the textbox with a translated version, so separating that bugfix out would require going in and fixing the original text so it was properly terminated.
Okay, fixed that. (It was a string I had explicitly skipped before, because I didn't know where it was being used.)
Still lots of work to do before I can move on to something else...