Got a bit of work done on the tile editor, making it so holding shift constrains the brush to the slope of whatever the surface you’re drawing is, making it a lot easier to make accurate slopes in the editor. After that, I decided to do a bit of performance profiling: While Flashdevelop has a memory profiler, there’s no built-in solution for tracking processing time, so I used a couple of built-in flash functions to track elapsed time and found out some kind of interesting stuff:
- Even with 1000+ particles, the processing time for behaviors and such is still only a few ms, one of the smaller expenditures on the frame.
- Drawing all of them is more demanding, and in some cases, such as large particles and details, may be problematic.
- Caching new animation frames is a huge expenditure. I was noticing huge spikes in frame time whenever a new character animation was loaded, and found that this was from the frame being scaled and cached. Now, in the final game the character frames probably won’t need to be scaled, but that doesn’t mean this isn’t an issue. I’m going to make it so that by default all entity animation frames are pre-cached, so that as soon as the entity prototype is readied all of its frames should be available. This may also be a helpful approach when it comes to static details, though not so much particles since they need to be dynamically creatable.
All-in-all, I want to be aiming for a total execution time of <16ms/loop for 60 frames per second. I just tried testing it and I’m getting really weird nonsense results, so either I fucked something up or this is for some reason an unreliable method. Still, hopefully to one degree or another this is showing me where it hurts, computationally.