Devtober Day 4

I mostly looked at more performance monitors and the profiler again today and did some thinking about my options.

Good news about the batching in the 4.4 dev build: it reduces my draw calls! Drastically!

(In 4.3, the draw call count is about the same as the object count)

The bad news, however, is that this doesn’t seem to do much for my frame rate. Something else is taking up a bunch of time. Navigation is a possible culprit, as the navigation server is a pretty stable 4-5ms for frames, which is concerning because there are nowhere near the intended amount of units in there so far. I think the navmeshes I baked for my maps may be unnecessarily complicated.

I considered if overdraw is a problem, which means attempting to move away from square textures to meshes with vertices/edges clipped as closely as possible to the non-transparent pixels. The problem is that I would have to change my existing map editor a lot. There’s no default way to script around converting from Sprite to 2D mesh (the functionality that comes in the editor is not exposed to scripting), and my custom editor already packs textures into an atlas for the location, which would not play along with their mesh conversion. I studied the source code for this editor feature, by the way (it’s in editor/plugins/sprite_2d_editor_plugin.cpp, and the actual saving is in Sprite2DEditor::_convert_to_mesh_2d_node()), and I don’t see the benefit in spending further time on this until I’ve eliminated other possibilities.

So if I focus more on the script functions that are causing lag spikes: when a behavior tree is executed, when a game event heap callback goes off, and the worst one… when the player switches the map being displayed (currently takes about “3 frames” to do on my hardware, which looks fast to me when the entire screen is changing, but I think I can do better than that, especially because any kind of lag isn’t OK when the player is trying to respond to multiple tense combat situations happening in multiple maps of the continent!) Playing “whack-a-mole” with functions that are performing badly as part of these spikes is something I can come back to when feeling stuck elsewhere in the project (or the performance issues themselves start getting annoying).

Though I did make some additional minor optimization changes (some of which I had to revert immediately because I realized they had gameplay logic implications and probably introduced bugs), today was more of a thinking day than a coding day. It’s OK to have that some of the time! Especially when trying to make sure I’m solving the right problem, and need to take time to understand what’s actually occurring in my running game, rather than just jumping right into editing something that might be a dead end.

I think tomorrow I will either start on the revamp of my user interface (which is holding up adding additional features), or, if I’m feeling like doing art instead of code, make and animate the assets for a new unit. It may be neat to show some of that.