On Debugging
by ChatPion
After fighting with my code for over four hours, lo and behold, I finally managed to have functional collisions!
EDIT: actually, it wasn’t working at all, but now, by pouring even more blood, sweat and tears, it does.
Debugging C on the Game Boy
Usually debugging is pretty straightforward: abuse printf or its equivalent,
set breakpoints and watch variables. However, as far as I know, there is no
out-of-the-box C debugger for gbdk-2020. I tried using printf and at first, it
was quite handy, until I encountered a strange bug: adding a printf did
temporarily fix a bug, and I had absolutely no clues why!
Thankfully, @JeanMarieMineau and
@g33kex suggested to use
Sameboy and its debugger by setting breakpoints
using ld b,b. After some trial and error, I found out that to insert inline
assembly code I just had to use __asm__("some assembly code")
(@yberreby found the syntax _asm and _endasm
while digging in gbdk-2020’s source code, but it did not work in my tests). After
doing so, I had to enable software breakpoints by typing softbreak in
Sameboy’s debugger. Then, it’s just a game of figuring out which register
contains which data, taking out the good ol’ pen & paper, replicating both the C
code and the assembly code, inevitably miscalculate (yep, 0x20is not right
after 0x19!) and slapping my forehead while loudly exclaiming “oh, that’s
why it did not work!” as I’m looking at a typo that could have been caught
earlier had I bothered to write some tests…
Writing the game in C instead of assembly surely is handy when it comes to
development speed, however it may render debugging more painful as we have less
control over the output assembly code. What’s more, that way we entirely depend
on gbdk-2020 not having any bugs and I’m afraid to say I did encounter strange
behaviours like the one with printf. Hopefully, that choice − switching from
assembly to C − will pay off and not horribly backfire…
@yberreby’s notes: if we encounter bugs in gbdk-2020, we’ll just have to fix them and submit a P.R :)
Random things I encountered
- It turns out 324 (18×18) is bigger than 256; that cost me way too much time.
- Additions take precedence over bitwise shifts. I learned that the hard way.
It’s crazy how small errors made me waste that much time.
tags: C - gbdk-2020 - assembly - debug