Gameboy Development Forum

Thanks for your help. But I am just a beginner and I am not a professional programmer (C# a little bit). I only want to make my ideas into a game. However, I appreciate your suggestion.

Robbi_Blechdose wrote:

You'd be better off learning Assembly immediately.
There are a few reasons:
GBDK is bad.
More people will be able to help you with ASM.
ASM is waaaaaay faster.

I started with GBDK, and I would not recommend it. It took a while to get me over to ASM, but it is a lot better.

Oh, and ZGB is also based on GBDK, so don't use that either.

Says you...
GBDK is not bad, it is actually an awesome library. As I have said many times the problem is the version of the compiler that was availbale back them
ZGB uses the latest version of SDCC so it doesn't have that problem and I am usually here to help

Use ASM if you have plenty of time to learn and want to really squeeze the hardware limits. Use GBDK or ZGB if you want to make a game quickly

WARNING: huge post incoming. But there's a tl;dr at the end if you don't feel like reading any of this! ^^

Jonas wrote:

I agree. If you are a beginner and try to code your first game in assembly, you are very likely to fail and end up with nothing. The few simple lines of code provided above in C would take a page or so in assemby and be completely incomprehensible to anyone who doesn't understand the hardware. There are good reasons for some of the best homebrew games for the Game Boy being coded in C...

That's not true, ASM is somewhat more verbose than C, but that's because you can do several things in a single line of C that translate to several lines of ASM, since each ASM operation is so elementary. Here's an example of two pieces of code that do the same thing:

// Assuming some_var and other_var are bytes
if(some_var == 42) {
    other_var++;
}

    ld a, [some_var] ; ld = LoaD
    cp a, 42 ; cp = ComPare
    jr nz, .dontIncOtherVar ; nz = Non-Zero
    ld hl, other_var
    inc [hl] ; inc = INCrement
.dontIncOtherVar

You're also exaggerating a lot how verbose ASM is. This didn't take entire pages. (By the way, the first 3 lines of ASM correspond to the first line of C; the rest to the second line fo C)

You can code your first GB game in ASM. It won't be worse or better than if it was made with GBDK. I've done it.
Also, ASM isn't as hard as you make it seem like. It's different from most programming languages, but it's still no problem for some people - some, not all - and C and ASM greatly help understand each other.
Further, trying to make your game in ASM will further incentivize you to learn about how the console works, and ho to operate it; instead of blindly trusting a (faulty) library.

Anyways, C code written for the GB is incomprehensible to someone who doesn't know the hardware. Why do people always declare huge `const` arrays of data that doesn't make any sense? What does `set_bkg_tiles` do? What does writing to NR52_REG do??
These are questions that require knowledge of the hardware. And no matter how hard you try, you can't abstract those away, because the GB is such a constrained system that any abstraction comes at a penalty that you can't just brush off.
You can write a GB game with GBDK, but it'll be limited. In different ways than if you didn't use GBDK, and I'm pretty sure that it'll be much more than using ASM.
Please note that I'm targeting using GBDK specifically, not using C as a whole. It'd be possible to write a C compiler and toolkit for the GB that generates super tight code. But nobody did it, and GBDK's the polar opposite of that.

Finally, most homebrew games on the GB have been coded in C because it's an easy solution. It's not because ASM programming is reserved to the elite of the elite - if so, how did the programmers of the time do to make the games they made? They didn't have C at the time, yet you got great games, even if they don't push the hardware to its absolute limits. It ranges from Pokémon to Prehistorik Man, or even Super Mario Land!
Of course, homebrew developers have less of an incentive to learn ASM now, since there's GBDK. But I disagree that there's any link between GBDK and a game's quality. There's an example of that, Last Crown Warriors, which seems rather promising, but is now written in ASM.
I would like to point out that the homebrew games that have been appreciated are mostly small games (eg Tobu Tobu Girl), and, well, with such a small scope, GBDK's constraints don't matter. But consider something with a bigger scope, like Pokémon. You can't do that with GBDK. Of course, even minigame-like games can be fun (I enjoy those, myself), but restricting yourself to GBDK is putting arbitrary limits on yourself. Reading a tutorial about ASM lets you know what are the console's actual limits - but maybe the tradeoff isn't affordable to the developer, so they'll go back to GBDK, but not trying is a waste.

Zalo wrote:

Robbi_Blechdose wrote:

You'd be better off learning Assembly immediately.
There are a few reasons:
GBDK is bad.
More people will be able to help you with ASM.
ASM is waaaaaay faster.

I started with GBDK, and I would not recommend it. It took a while to get me over to ASM, but it is a lot better.

Oh, and ZGB is also based on GBDK, so don't use that either.

Says you...
GBDK is not bad, it is actually an awesome library. As I have said many times the problem is the version of the compiler that was availbale back them
ZGB uses the latest version of SDCC so it doesn't have that problem and I am usually here to help

Use ASM if you have plenty of time to learn and want to really squeeze the hardware limits. Use GBDK or ZGB if you want to make a game quickly

GBDK's lib is awful.
The first problem is that it's been compiled with SDCC, which makes it hugely bloated (seriously, functions used as often and as time-important as VRAM funcs should have been optimized by an ASM programmer, no?!).
The second is that the lib is confusing anyways, unless you learn about the hardware - which takes time -; here's an example: you don't have to care about VRAM access restrictions because you just have to use `set_bkg_tiles`, but you still have to know how the APU is operated because you are only provided direct interfaces to the APU regs (via NR**_REG), and also for some reason modifying the variable `LCDC_REG` changes the behavior of `set_bkg_tiles`, so uhhhh,

ASM is indeed required to squeeze something fairly technical out of the console, but it's not exclusive to that. ASM unlocks full control over the hardware, but that doesn't mean you have to use it to its full potential. Again, see any commercial game released during the console's lifespan.
You can make games quickly in ASM. If you're quite comfortable with ASM, then you can quickly program with it, same with C. You'll even debug faster! Since there are no C-level debugging tools for the GB, you can debug ASM code only. If that's the code you wrote, you know what it's supposed to do, and deduce where it went wrong. If it's generated code, as with GBDK, you can't. Therefore, your debugging has to be trial-and-error (and there's no standard output to `printf`-debug to!), which is slower.

And finally, another huge problem with GBDK: it's not updated. Period. The compîler is awful, and there's nothing you can do about it. Unless you have the skill to replace the toolchain, but then you certainly also have the skill to program in ASM. (I guess that's one of the reasons why GBDK isn't updated?)
I have seen someone who hit a compiler bug that kept corrupting memory. It wasn't his fault, so he was at a loss. And he didn't do anything that seemed wrong - SDCC had just inserted an `add sp, $27` instruction for no apparent reason. You can't trust that compiler.


tl;dr: try learning ASM for the Game Boy. Even if you end up going back to GBDK. Because it'll provide you insight as to what the console is actually doing, which is a must on such a small system.
Why not start here?

ISSOtm wrote:

You can code your first GB game in ASM. It won't be worse or better than if it was made with GBDK. I've done it.

Sure. You can learn English by reading Hamlet. You can learn to play piano by practicing Rachmaninov. You can even learn to play videogames with the Japanese version of Super Mario Bros. 2. But it's not very rewarding and you're likely to be soon discouraged if you try to.

The TO wrote this:

Game_Boy_Fan wrote:

But I am just a beginner and I am not a professional programmer (C# a little bit). I only want to make my ideas into a game.

When I started with Game Boy development, I was in a situation very similar to the TO's. I had nearly no coding experience, started with GBDK, coded a simple game in C (Retroid) and then moved on to learn assembly. Based on that, I agree that assembly is far superior and there are few reasons I could think of to return to GBDK again. But for somebody with very little experience (like the TO) I'd still clearly advise to start with C and try to create something like Tetris, Breakout or Sokoban. For a beginner that's hard enough and for a project of that scope, you don't have to push the hardware to its limits. Therefore, GBDK is absolutely sufficient and there is a fair chance to end up with a finished game.

From your post I understand that you coded your first game for the Game Boy in assembly. But I rather doubt that means you started with no coding experience at all. If it does, you are either very talented or very patient and shouldn't expect that everybody else is.

tl;dr: The main upside of GBDK is that it's accessible for people who have no idea how a computer works and want to see results quickly. Assembly isn't.

Last edited by Jonas (2018-08-31 07:13:10)

Well I don't think there are many points on which we disagree.

ISSOtm wrote:

I am simply advocating against using GBDK for anything besides small games. (To put it differently, I agree with you on this, but I disagree with "all good HB games were written with GBDK")

I certainly don't disagree with that. Instead, I stated:

Jonas wrote:

There are good reasons for some of the best homebrew games for the Game Boy being coded in C...

To be specific, I had Tobu Tobu Girl, Super Princess 2092 Exodus and Crazy Zone in mind. But I'd be the last to say that there are no good assembly homebrew games (particularly not since the most recent game I released myself is coded 100% in assembly).

The one point where we do disagree is whether or not GBDK's better accessibility for beginners with zero coding experience compensates for its (many) weaknesses. My advice to a beginner would be to accept GBDK's issues for the start while you - as I understand - would suggest to learn coding somewhere else and later return to the Game Boy to start with assembly from the outset. I believe that will chase some people away who want nothing more than to make a small game and see how far they get with it. But it's not much of a difference and probably depends very much on the individual goals and personal taste of the person in question.

Last edited by Jonas (2018-09-01 04:51:44)

I can't tell much about previous versions of SDCC but the last one I used (v3.6.0) didn't encourage me to even consider it as an option. Long story short - I wanted to compile some C code instead of porting it to ASM. After looking at output source I immediately started writing in ASM from scratch. This is probably because I know assembly well enough and prefer clean code. Here's some small example, not just my words:

const unsigned char *input_data;
size_t input_index;

unsigned char read_byte() 
{
    return input_data[input_index++];
}

And here's SDCC v3.6.0 output:

_read_byte::
;some_source.c:43: return input_data[input_index++];
;156 / 172
    ld    hl,#_input_index + 1    ; 12
    dec    hl                ; 8
    ld    c,(hl)            ; 8
    inc    hl            ; 8
    ld    b,(hl)            ; 8
    dec    hl            ; 8
    inc    (hl)            ; 12
    jr    NZ,00103$        ; 12/8
    inc    hl            ; 8
    inc    (hl)            ; 12
00103$:
    ld    a,c            ; 4
    ld    hl,#_input_data        ; 12
    add    a, (hl)            ; 8
    ld    c,a            ; 4
    ld    a,b            ; 4
    inc    hl            ; 8
    adc    a, (hl)            ; 8
    ld    b,a            ; 4
    ld    a,(bc)            ; 8
    ld    e,a            ; 4
    ret                ; 16

Here's my quick rewrite based on above:

;100 / 116
    ld    hl,input_index+1    ; 12
    ld    a,(hl-)            ; 8
    ld    d,a            ; 4
    ld    e,(hl)            ; 8
    inc    (hl)            ; 12
    jr    nz,_1            ; 12/8
    inc    hl            ; 8
    inc    (hl)            ; 12
_1
    ld    hl,input_data        ; 12
    add    hl,de            ; 8
    ld    a,(hl)            ; 8
    ret                ; 16

And something more optimized I'd probably use:

;100 / 104
    ld    hl,input_index        ; 12
    ld    a,(hl)            ; 8
    ld    e,a            ; 4
    inc    a            ; 4
    ld    (hl+),a            ; 8
    ld    d,(hl)            ; 8
    jr    nz,_1            ; 12/8
    inc    (hl)            ; 8
_1
    ld    hl,input_data        ; 12
    add    hl,de            ; 8
    ld    a,(hl)            ; 8
    ret                ; 16

SDCC version uses 156 cycles min / 172 max, my routines respectively 100 / 116 and 100 / 104 cycles and someone probably could do better. I haven't tested them but they should be ok.

Conclusion? SDCC works but it still has a long way to go. And just because someone put a lot effort in something it doesn't make it "suckproof". It all comes down to your skill and expectations. Just my .02 cents.

And I didn't mean to imply that. My point was simply to balance your praise of SDCC.