- 1
- Posts
- 6
- Years
- Houen Chihou
- Seen Mar 2, 2020
Hi everyone! I'm making a translation of Pokemon R/S to Russian and I've faced a few issues with the build system of pokeruby. I have quite a bit of experience with C# and a bit with C++, so I feel comfortable coding in C, but I have no idea on how do build scripts and build chains work.
For my translation I wanted to undub quite a few things.
1) I was trying to import the japanese title logos into pokeruby. It worked almost fine, but for some reason a few pixels in the new logo flashed with the logo animation and then became solid black. Upon further investigation with no$gba's palette viewer I noticed that the vanilla english rom happens to apply the same flashing effect to color #26 (at adress 0x05000034) that also gets applied to color 0...and I observed that the japanese rom doesn't have this behaviour. So I tried to fix it to behave like the japanese game...and at that point I realized the first problem: The debugging symbols are stripped away from the ROM, so I can't see function names in the no$gba debugger. And also loading the elf file doesn't work either(I assume the elf binary the emulator docs are talking about are that produced by GCC or something, not agbcc). How am I supposed to get symbols to work? Also how do I add a breakpoint in the source code?
2) So then I thought that I could use some sort of debug print output to try to guess which function was running at the time the memory write(with change) to palette data breakpoint occured. I found that there's a thing called AGBPrint, and that emulators support it. So I tried using the function a few times, yet it resulted in no text output. Then I realized I have to comment out #define NDEBUG...so I did. And from doing just that I got a whole bunch of linker error messages like this:
So, what am I supposed to do for this to link properly?
For reference:
I'm doing all the editing on Windows and compiling the project in a Linux(Ubuntu 19.04) VM(because agbcc did not want to compile properly on Windows).
Also I did all this testing without changing the way things are built(so I didn't touch the makefile nor the linkerscript), only later I tried to edit a few options, but this didn't lead to any different results.
For my translation I wanted to undub quite a few things.
1) I was trying to import the japanese title logos into pokeruby. It worked almost fine, but for some reason a few pixels in the new logo flashed with the logo animation and then became solid black. Upon further investigation with no$gba's palette viewer I noticed that the vanilla english rom happens to apply the same flashing effect to color #26 (at adress 0x05000034) that also gets applied to color 0...and I observed that the japanese rom doesn't have this behaviour. So I tried to fix it to behave like the japanese game...and at that point I realized the first problem: The debugging symbols are stripped away from the ROM, so I can't see function names in the no$gba debugger. And also loading the elf file doesn't work either(I assume the elf binary the emulator docs are talking about are that produced by GCC or something, not agbcc). How am I supposed to get symbols to work? Also how do I add a breakpoint in the source code?
2) So then I thought that I could use some sort of debug print output to try to guess which function was running at the time the memory write(with change) to palette data breakpoint occured. I found that there's a thing called AGBPrint, and that emulators support it. So I tried using the function a few times, yet it resulted in no text output. Then I realized I have to comment out #define NDEBUG...so I did. And from doing just that I got a whole bunch of linker error messages like this:
Spoiler:
For reference:
I'm doing all the editing on Windows and compiling the project in a Linux(Ubuntu 19.04) VM(because agbcc did not want to compile properly on Windows).
Also I did all this testing without changing the way things are built(so I didn't touch the makefile nor the linkerscript), only later I tried to edit a few options, but this didn't lead to any different results.