It's 2:00 am and I've had a good time working with SDL again. It's so nice to build some simple little display systems. I decided to try reducing functions calls in my render thread (or rather ANY of the critical processing threads) to minimize exporting registers to stack, having a hopefully maximal performance at all. The problem with is that I somehow have to bring the initially unknown numbers of sprites to screen. I decided to use a linked list to fill this later for later occuring hardware-based rendering, but that also means that I'll have to call atleast malloc for each added symbol. That's of course not much and I won't have any possibility to avoid except when using a preallocated stack of list items, only expanding if necessary. While this is a really good idea for later, I'm also wondering about the performance of those threads that have to access and wait on event list mutex' to be unlocked, effectively calling an SDL function, you know. That means that I'll once again have to use another stack for dumping events temporarily and posting them later. I'm a bit afraid that this is too heavy-headed for the thread of concern, the physics thread. This thread does actually not require much stuff at once as I believe, so it is probably no problem to use functions calls in there. This doesn't have to do with ill-seeded optimization fanatism but rather the knowledge that certain processes require so many local variables storable in register than functions calls may be critical. Good thing to know that the "higher" areas of execution do not require too high performance at all. Graphics programming still persists as the most realtime-demanding system I know of. And it's only good to be able to pump some more light effects.

No comments: