Gameboy Development Forum

I'm a game designer, not a programmer. I don't have the time/patience to learn assembly when I could quickly make a few prototypes in C.

First, sorry for bumping an old topic.

Second: First post! Woohoo!

On-Topic:
I *may* pick up this project. I have over a decade (off and on) of C/++/# experience. Right now, I'm learning RGBDS because I just couldn't click with the mess that is GBDK.


Some background:
I was originally working on a Wii U game that was very strictly based on the CGB's specs (to the point that I have a mostly working graphics engine written in C# that loads GB binary format tiles/maps/palettes/etc, and mimics the behavior of the background, window, GB-specific registers, memory locations, etc..) I decided if I was going to go this far, and with the "NX" coming sometime soon, I should just learn to code on the real thing, make the game, and port it over. Obviously having a C-variant environment would be ideal for porting to a modern platform so this idea has been on my mind for some time (including a GB-specific IDE, but that's for another time...)

With that being said, once I feel pretty grounded, I *might* take a stab at this (ok, I most likely will). It probably won't be very good in the beginning, and will only provide a few global shortcuts for GB register locations like LCDC, STAT... but it'll be something.


It might take a while until I get to this. Day-job and all... but it definitely seems like a do-able project. Especially since SDCC seems to already do the hard part for us.

I definitely plan on it. I'm still an assembly newbie though, so it might be a while.

NECROBUMP
POWAAA


GBDK is a huge mess, and the project was unmaintainable that a newer version had to be made instead of changing the current one.

C can feel easier to maintain, but I think that applying OOP concepts (encapsulation, mostly) greatly helps maintaining C code, and even more so ASM.
Also, there aren't more C users than ASM users. GBDK is the only large C framework, so that's why it's widely used -- but there's a project of a newer framework, that should be as easy to use (probably not, since we would drop some of the abstractions), but less of a pain to give support for.
Because honestly, when something goes wrong with GBDK-using code, nobody has any idea what is wrong. (75% of the time.)

a cat wrote:

if someone could make a modern gbdk it would be great though
sdcc(a modern c compiler) can compile for the game-boy
all that is needed is for someone to write a c standed library for use with sdcc and the gameboy and we have a awesome modern compiler for the gameboy

here's a thred on the sdcc forums about compiling sdcc for the gameboy:
http://sourceforge.net/p/sdcc/discussio … /e04ebcc5/

Dose anyone know how to write a very simple standerd library for the gameboy?

There is now an updated version of the GBDK libraries that allows to compile with a modern SDCC version. It is called GBDK-n → https://github.com/andreasjhkarlsson/gbdk-n

I used to have a lot of trouble when I was working on a game (Evoland GB) using GBDK and its old, crappy compiler. SDCC + GBDK-n solved all issues I had

I use GBDK because my existing knowledge of C# from working with Unity carries over nicely, letting me just dive into making my game without having to learn a new programming language from the ground up. I told myself long ago, before I even learned my first programming language, that I wouldn't learn assembly language unless I was being paid to do so.

Making this game was just a little side project while I took a break from my main game. And this actually taught me a lot. I didn't know about switch statements (which I just found out, while typing this post, Unity also supports) until working on this game and those will make my other game run so much better!