Code is broken, no idea why (game too big?)

A topic by Cratmang created Oct 29, 2020 Views: 145 Replies: 2

Viewing posts 1 to 2

I am close to writing off my game as "complete." However, a new bug has reared its head in my previously perfectly working code, and I have no idea how to squash it.

In general, the game is working perfectly fine... until you get to the Game Over screen, at which point it just freezes/crashes (you're supposed to be able to press a button to go back to the start of the game). If I remove the screen, then it just loops back to the Title screen as normal.

It's not like Game Over was causing any issues before - As far as I can tell, it just decided "Eh, I don't feel like working anymore." I suspect that it may be because I have made my game too big for the engine to handle.

Okay, I don't have anything else to say that is either productive or helpful, so here's an image of the code for Game Over.

And because I am desperate, here is an 8o file for the game.

Internet JanitorHostSubmitted3 years ago(+1)

First thing I noticed when I assembled your game is that it's 3814 bytes. That means that it won't quite fit in the low 4kb of RAM. (remember: the first 512 bytes are reserved, and CHIP-8 programs always begin assembling at 0x200.) If you pop a compile-time assertion like the following:

:assert "overflowed code RAM" { HERE < 4096 }

Somwhere in your "game over" routine, you'll see that the assertion fails, which confirms the theory.

Instructions like "jump" (which is emitted as part of an "if...begin" or a "loop...again") take a 12-bit address, so they can only point somewhere in the low 4kb of memory. We need to make your program shorter, or at least ensure that the code fits in a smaller space. Fortunately, I see some easy opportunities to make this happen!

The simplest option might be to move some or all of your graphics data to the end of the program. This may require you to use "i := long NNNN" instead of "i := NNN" in some cases, since that data will now be located somewhere that needs a 16-bit address to access; Octo's assembler will complain when this is necessary.

Another option to explore is reworking that "text" macro. As written, it emits 3 CHIP-8 instructions (6 bytes) for every character printed. That adds up quickly! Even just special-casing spaces like this should save you a couple dozen bytes:

:stringmode text "ABCDEFGHIJKLMNOPQRSTUVWXYZ.,!?/" {
 :calc addr { font + VALUE * 4 }
 i := addr
 sprite vx vy 4
 vx += 4
}
:stringmode text " " { vx += 4 }

Does that make sense?

CratmangSubmitted3 years ago(+2)

I think so. Gonna try moving the graphics data. Thank you!

itch.io

Octojam 7

Code is broken, no idea why (game too big?)