O Ilusionista said:
Nice work! Something which crossed my mind is: Why DC can handle your game but struggle to run the most updated OpenBOR? Maybe because your game is optmized for it?
Well, that's a good question, but I'm afraid I am no longer sufficiently familiar with OpenBOR's code and features to adequately answer it.
I can confirm, though, that I did spend a significant amount of time optimising the Dreamcast-specific parts of my code, but really that is only a tiny fraction of what makes the game run fast. The most important optimisations are in the platform-independent parts: minimising the number of collision checks, pre-calculating and pre-parsing as much as possible, avoiding int-float and float-int conversions (in fact this game uses fixed-point maths almost exclusively), and being generally frugal with RAM. I didn't do that specifically for the Dreamcast, it's all just force of habit I suppose. I actually developed the game for PC initially, but when I compiled it for the DC it ran almost perfectly on the first try.
By the way, some people may think I'm a loony for using fixed-point arithmetics when most floating point operations are just as fast. One reason I already mentioned: converting between float and int is unavoidable, and much slower than is often assumed. The other is that my game engine supports huge, and I do mean HUGE levels - so much so, in fact, that it could potentially run into precision issues if I'd used plain old floating points. I've never actually built such levels, and perhaps I never will, but at least I know that I could do so without breaking the engine. I wouldn't recommend using fixed-point for OpenBOR, though.