Laser Invaders is a Commodore 64 game written in c with the cc65 6510 cross compiler.
This is not good c code. First of all I am not a c programmer by trade. I learned ANSI c back in 1990 when I was college, and never really used it for much beyond that. Object oriented programming was all the rage at the time, and c was just a stepping stone for me to work with c++ (which I barely used professionally), and then (gasp!) object oriented Pascal. Anyways this code is terrible, but the terribleness is also partly due to the 8-bit platform I am coding on, not to mention the limitations of the c compiler for this platform. cc65 is not a truly ANSI C compiler, but it gets close. One cannot critique cc65 too much because it is a marvel that one can use it to write reasonably well optimized code for an 8-bit platform that is 40 years old. And it absolutely kills Commodore BASIC 2.0 when it comes to speed. But of course it is nothing compared to the tricks and the crazy techniques honed over the years by modern C64 devs (just google "Protovision Commodore 64" if you don't believe me).
Doing anything with a data type that is not a byte (unsigned char) takes a lot of extra machine code. This is to be avoided as much as possible. And forget about floating point math. Just, no. Using the stack and passing parameters to functions adds lots of overhead and is to be avoided. You can do it, but you need to be able to do all your game logic inside 1/60th of a second. So using function paramters outside the game loop is OK. Macros help get around this a bit, but at the expense of bigger code. And this really pains me ... but there are lots of global variables for this reason. Arrays? Forget about it. Removing code that accesses array indexes is a surprising optimization. Pointer variables helps mistgate that a bit. Manually unrolling loops is key (again, at the expense pf bigger code). And lets not forget the liberal use of the PEEK and POKE macros provided by cc65 which is really a necisary evil, unless we resort to inline assembly which I am avoiding. Although I created my own static POKE macro using inline assembly. That was done to reduce code size and was not really done for speed optimization.
To-do: figure out how to load sprite data at runtime from files to get rid of the stupid const arrays. That way I can support more cool enemies. And I would like to add some music because the C64 has awesome music synthesis capabilities. I probably need to move the VIC-II memory location to another bank. This will be painfull considering all of the hard coded memory addresses and offsets. So that may take some time. Cheers!