I tried everything I thought to speed up, but... maybe C is not very suitable for fast games.
Well, regarding the speed difference, there are many things that can impact the performance.
From my own tests, I'd say that optimized C (with our compiler) is about 5 to 10 time slower in average than assembler, but when you start to go in things that are pure processing of stuff involving loops and copies, you can easily beat the C compiler by a factor of 50 (because it does not do things like loop unrolling, and uses the zero page very conservatively).
Now, if you want to stick to C, you have to remember a few things:
- Function calls are costly: there's parameter pushing, stack management, etc... typically your one liner functions like
void deleteObject(unsigned char objectNumber) or
int getpos(unsigned x, unsigned y) would be much faster if they were implemented as macros doing the same thing: The code would be inlined in the function call.
- Avoid having to test for the state of objects to know if they are alive, frozen, dead, etc, it works much better to have objects in lists: The list of objects that are running, the list of objects that can be reused, etc... you get just a single counter, and no need to test for
objects[ i].active
- Switch cases are faster than bunch of ifs, but if you only need to test for one specific condition (like in
void objectProcessing()) I'm pretty sure that replacing your switch by just "if (objects[ i].active)" would be faster.
-
void executeUpdate() is a perfect example of where using lists of objects per type would be much faster than testing for specific object type: Update all your stars in one single batch, then all your meteors, etc...
Generally speaking, this is also true of 6502 assembler: Having lists of stuff to process linearly without doing any check will always be faster than iterating over generic list of items and run specific dispatcher code
