Well, this is still coming along quite nicely. I've spent some time optimizing the code and found that in a simple example where i'm just bouncing 1000 to 2000 sprites around on the screen, the behavior system is only twice as slow as coding it all by hand. And this example is sort of a 'worse case scenario' since the actual functions being called are simple and fast (pretty much only DrawImage), and so the behavior system's overhead is much more noticeable since almost no time is spent in the function calls themselves. Considering the behavior system is looking up all the variables used and functions called from a hashtable, whereas the handcoded version is simply accessing a field in the object, I must say I'm impressed that it's getting 30ms per frame whereas the handcoded version was getting 15. As the function calls become more complex and intensive, the gap should close even more as the overhead of the behavior system will be masked.
Also, I'm going to do some more optimization like writing a custom TList that requires no casting. Anything I can do to save a millisecond here or there.
I've still got to build a default timer behavior (basically just timing code existing ina behavior that can be swapped out if necessary - although it will feature things such as a global elapsed time, paused time variable, and a few other handy things), rewrite the error system a bit to make it even easier to track down stray variable calls or function calls to functions that don't exist, and a few other 'sub-systems'.
This is turning out to be more of a true framework than I originally imagined, but due to the nature of the flexibility of the design, anything can be changed quite simply. It's all modular.
Anyhow, I'll quit rambling about this since I don't really have anything that I can show as a true public demo yet (got to finish up the API first). Just thought I'd bump this for awareness.
Also, I'm going to do some more optimization like writing a custom TList that requires no casting. Anything I can do to save a millisecond here or there.
I've still got to build a default timer behavior (basically just timing code existing ina behavior that can be swapped out if necessary - although it will feature things such as a global elapsed time, paused time variable, and a few other handy things), rewrite the error system a bit to make it even easier to track down stray variable calls or function calls to functions that don't exist, and a few other 'sub-systems'.
This is turning out to be more of a true framework than I originally imagined, but due to the nature of the flexibility of the design, anything can be changed quite simply. It's all modular.
Anyhow, I'll quit rambling about this since I don't really have anything that I can show as a true public demo yet (got to finish up the API first). Just thought I'd bump this for awareness.