[GB] Advice on Colorizing Game Boy Games via Programming

[Homer177]

Howdy all,

I recently posted about desires to colorize the original Mario's Picross and Picross 2 in similar fashion to some of the DX releases. Is it possible to do this via C or C++, or would I have to go through ASM only? I'm more familiar with the first two than the third and I've actually been playing around with tutorials on coding game boy games in C.

Advice is welcome.

[FAST6191]

I doubt mode even modern C compilers will do the GB/GBC justice, not to mention you would probably be better off remaking a game at that point. It is not unheard of for people to inject C code into games (albeit I have never see it on the GB/GBC and would not expect to) and have the game jump to it but it is far from the done thing.

Anyway two approaches (or three if you count emulator only, which is less a hack most of the time and more just a colour palette not entirely unlike what the GBC hardware affords with the hold buttons during startup https://www.nintendo.com/consumer/systems/gameboyadvance/colorchange.jsp ), maybe with an ability to swap out at a given point in the game or have users do it)

1) You hack the game into being for the super game boy and go accordingly (hope also your audience can run/emulate such toys, which is a surprisingly big ask in a lot of cases -- even flash carts have trouble with this one). https://loveconquersallgam.es/post/2350461718/fuck-the-super-game-boy-introduction

2) You hack the game into being a GBC game and go accordingly (most of what you see in hacks around here that add colours). Trip the detection ( https://bgb.bircd.org/pandocs.htm#cgbregisters ), tweak any relevant header sections and go from there, sorting out any falling debris from things not being where it might have previous expected or running faster than it previously did all while taking advantage of it to add your own tweaks in there or twist it to use GBC hardware where there originally was none.

C and C++ in ROM hacking is mostly useful for making tools and if you are on a system wherein things were likely coded in C/C++ then figuring out what the likely base version of the assembly you are looking at was (either to exploit it https://wiibrew.org/wiki/Signing_bug , fix a bug or simply understand the greater flow/purpose more easily). Active work in changing the game (that is not data changed by your tool) tends to be ASM or bust.

With the recent N64/general Nintendo leaks and various decompilation efforts, to say nothing of general open sourcing and recreation, you can get a lot done with C/C++ knowledge in game modding circles, however straight ROM hacking (especially of anything that was not likely programmed in C/C++ to begin with*) of the ROM itself it has limited application.

* https://www.pagetable.com/?p=28 being a choice link at this point in time even if only as a curiosity.

Short version. Yeah assembly is in your future. The z80 a like of the GB/GBC is not so bad though. Don't know what I would suggest similar to some of the stuff I have for later systems or stuff like the 6502, especially not if you are familiar with somewhat low level coding already, so I will have to leave it at the pandocs stuff linked earlier.

[Jorpho]

Do you not remember asking about this a few weeks ago?
http://www.romhacking.net/forum/index.php?topic=31469

[KingMike]

1) You hack the game into being for the super game boy and go accordingly (hope also your audience can run/emulate such toys, which is a surprisingly big ask in a lot of cases -- even flash carts have trouble with this one). https://loveconquersallgam.es/post/2350461718/fuck-the-super-game-boy-introduction

Yes, because an actual Super Game Boy has ACTUAL GB chips inside.
So the only flash carts that would support it would be a SNES flash cart that can handle simultaneously running its own Game Boy emulator on top of what it is already doing. (and I hear there is ONE that can)

2) You hack the game into being a GBC game and go accordingly (most of what you see in hacks around here that add colours). Trip the detection ( https://bgb.bircd.org/pandocs.htm#cgbregisters ), tweak any relevant header sections and go from there, sorting out any falling debris from things not being where it might have previous expected or running faster than it previously did all while taking advantage of it to add your own tweaks in there or twist it to use GBC hardware where there originally was none.

THIS.
You need to learn ASM and how the GB hardware works, especially the palette stuff.
Undoubtedly previous attempts at a generic "colorizer" didn't work because GB/GBC is probably too slow and timing sensitive to just have C-compiled code (if it is even possible) thrown at it. I'm sure the GBC's timing sensitive video hardware only allows certain access to video hardware, which means carefully written and optimized ASM code to avoid wasting limited CPU time.
Maybe there is some specific console-optizimed compiler out there, but those I have used have just gotten bigger and more bloated over the years because they expect to run on CPUs that are faster and have more memory to handle slow and bloated code (why even a simple "Hello World" program is now over 2 MB is because it by default compiles a whole boatload of "standard" library code since it's probably not smart enough to figure out which of that code it actually needs, so it just throws it all in there anyways.)

[FAST6191]

Yes, because an actual Super Game Boy has ACTUAL GB chips inside.
So the only flash carts that would support it would be a SNES flash cart that can handle simultaneously running its own Game Boy emulator on top of what it is already doing. (and I hear there is ONE that can)

THIS.
You need to learn ASM and how the GB hardware works, especially the palette stuff.
Undoubtedly previous attempts at a generic "colorizer" didn't work because GB/GBC is probably too slow and timing sensitive to just have C-compiled code (if it is even possible) thrown at it. I'm sure the GBC's timing sensitive video hardware only allows certain access to video hardware, which means carefully written and optimized ASM code to avoid wasting limited CPU time.
Maybe there is some specific console-optizimed compiler out there, but those I have used have just gotten bigger and more bloated over the years because they expect to run on CPUs that are faster and have more memory to handle slow and bloated code (why even a simple "Hello World" program is now over 2 MB is because it by default compiles a whole boatload of "standard" library code since it's probably not smart enough to figure out which of that code it actually needs, so it just throws it all in there anyways.)

I was thinking more that there are GB/GBC flash carts that can't play nicely with the SGB/run in SGB mode on one. The relatively new EZFlash Junior being one such example (the team want to but apparently SGBs are a bit thin on the ground in China), even if it otherwise serves as a fantastic little cart for use with any other flavour of official hardware (much clone hardware being more a ROM/save dumper stapled onto an emulator which naturally does not do well with a menu driven flash cart).

But yeah it would be something quite special to do from the SNES side of things. We have seen things replicate the megacd/sega cd though, as well as all the weird and wonderful things on the SNES as far as special chips, so maybe one day.

A compilers for consoles. There has been a bit of a fad to try to make something vaguely resembling a workable compiler for older consoles this last few years which do more than max out the CPU, RAM and storage to do hello world and could almost be used to do real work (never going to make mario kart, sonic or good ai, might make a text adventure, visual novel or maybe turn based RPG). Most of the time by the time you learned the libraries (standard library tends to be cut down which is enough to make me walk out of the door for any company wanting me to play coder or interact with them) and restrictions for the older stuff you might as well have learned assembly but never the less it is a thing. I would still never use one to make any homebrew (never mind try to write something to jump to in a hack) for a console that did not see C coding in the first place but I will note it as an impressive trick.