The actual claim is that you can keep the game state for a rather minimal 8x4 game board in two uint32_t, one uint64_t, and one uint_8t.
That's not the entirety of program state - stack aside, there are some loop counters that the author isn't including in the total, along with some implicit variables e.g., for keypress data.
It's a nice optimization exercise, but the result is not particularly mind-blowing to me. You could probably make it significantly more compact at the expense of readability. For one, the shape of the snake on the game board is not random: there's plenty of combinations, such as an alternating checkerboard pattern, that are physically impossible. So the shape is likely compressible.
Coule use zero if you sleep() just the right amount of time so that when the process wakes up, the current time contains the next frame's game state. That would reduce framerate a bit though.
That's not the entirety of program state - stack aside, there are some loop counters that the author isn't including in the total, along with some implicit variables e.g., for keypress data.
It's a nice optimization exercise, but the result is not particularly mind-blowing to me. You could probably make it significantly more compact at the expense of readability. For one, the shape of the snake on the game board is not random: there's plenty of combinations, such as an alternating checkerboard pattern, that are physically impossible. So the shape is likely compressible.
reply