I was referring to inline functions vs. macros only. Test it with inline functions then I will be interested in the results.Originally posted by Sebastiani
I have not looked over your code. But I can tell you that IO operations are always several orders of magnitude slower than calculations. But I guess you already discovered that. Rendering in general is slow on pre-gigahertz machines, so limit the time spent drawing backgrounds. Another significant improvement can be achieved with separate threads of execution. If you would like a simple library to begin with, just PM or email me. But beware. Threads can cause a lot of headaches and often require severe restructuring of the program. Nonetheless, giving each sprite it's own thread makes the game flow more naturally, and this is one of the main advantages of using them.
Macros are indeed ugly, but they ARE faster. Try this simple test:
Code:double mult( double a, double b){ return a * b; } #define MULT(a, b) ((a)*(b)) int main() { time_t start, stop; double iter, x = 1, y = 3; start = clock(); for(iter = 0; iter < 100000000; iter++) x = mult(x, y); stop = clock(); printf("(Function) Result: %d Seconds Elapsed\n\n", (stop-start)/1000); //...48 - 52 seconds on my machine... x = 1, y = 3; start = clock(); for(iter = 0; iter < 100000000; iter++) x = MULT(x, y); stop = clock(); printf("(MACRO) Result: %d Seconds Elapsed\n\n", (stop-start)/1000); //...35 - 38 seconds on my machine... getch(); return 0; }
On my system, the macro was roughly 20%-30% faster.
BTW:
Don't waste your time with FillRect(), you can get by without it.
Oh, and far as speed goes, DirectX and OpenGL have much faster bit-block transfers than BitBlt().
Anyway, good luck on the game!