Attention | Topic was automatically imported from the old Question2Answer platform. | |
Asked By | steely | |
Old Version | Published before Godot 3 was released. |
I’m working on a project that includes hundreds of tiny moving sprites, on top of a background containing 1250 (25x50) visible background tiles. This does not seem like an unusual graphical load for a small 2D game.
All the moving sprites call set_process(true), and the code that updates their position runs in the _process() function and uses set_pos(). I previously used a simple linear function for position interpolation, but I thought a cubic Bezier curve would look much better. I was correct that it looks a lot better, but it came with a massive performance hit: with 700 moving sprites, the frame rate fell from a tolerable ~50+ fps to an unacceptable ~15 fps.
Is this purely the result of slow arithmetic in GDScript/Python (which GDScript is modeled upon)? This is a fairly complex operation that takes ~30 arithmetic steps, which I would expect to be called up to 50,000 times per second. Caching, LUTs, fast approximation, etc. would probably speed it up dramatically, but I’d like to know if there’s an easier solution.
Would it be worthwhile to handle the Bezier calculation with a C++ function? What is the overhead of making such a call? Is the overhead amortized by making many thousands of calls a second?
Am I doing something wrong by calling set_pos() every frame for every moving sprite? I like the direct control it gives me, but is there a way to offload the position calculations to the Godot engine in a way that would be faster?
1,500,000 operations per second sounds like a lot for any scripting language to be honest. There’s probably room for optimization in the code you’re using, before looking at moving it to C++.
Akien | 2016-06-23 14:37
It might be the rendering costing you a lot of process time, not just the GDScript calculations. You could roughly test it by running it with all your sprites hidden or with a low viewport resolution.
rgrams | 2016-06-23 19:40
@rgrams I ran my prototype at 55 fps with 700 motes and the linear interpolation. Then I replaced the linear version with the Bezier version (no other changes), and the prototype ran at 15 fps with 700 motes.
steely | 2016-06-23 19:54
@Aklen There is certainly a lot of room for optimization everywhere, but I want to know what other options there are so I don’t waste time doing pointless optimization. Speedups could come from switching to a quadratic Bezier, using a big lookup table (5880 elements? ouch), or using a faster but more-complicated-to-write incremental Bezier algorithm.
steely | 2016-06-23 20:35