Hello,
I’ve been working on trying to get smooth movement working for 2D. For performance reasons, I’ve been trying to make it so that I can call the function accelerate(self, endtarget) once, and have it slowly speed up/slow down depending on the endtarget, instead of updating the function every frame through Update().
Previously I was shown vmath.lerp. I’m using it to take the object’s current speed and tween it to the endtarget parameter. Inside vmath.lerp is (t, endtarget, startvalue). T is used as the ratio in which the vmath.lerp function uses to decide how much of that endtarget it’s going to tween to, calculated each time it’s called. So, I can take that and slowly increment it over a calculated amount of time to get my desired smooth acceleration.
How would I go about having slow incrementation and having it all in one function which would be called once?
Also if any of you have better ideas I’d be glad to hear them.
If you don’t want to run code every update your only option would be to use go.animate() and let the engine animate/tween the value for you. You could animate the position and use an easing function to simulate acceleration, but I’m guessing that’s not what you’re after. You could use go.animate and animate a go.property (velocity) and apply that every update, but for better control I’d go for the update function and add acceleration * dt to velocity and the add velocity * dt to position.
1 Like
And this wont have much drag on computers running it every frame?
No, not at all, unless you have maybe a thousand or more instances of this script in your game.
Don’t try too hard to optimize your game unless it’s in the later stages. Keeping performance in mind is good, but don’t let it slow down development. There’s nothing wrong with using update().
4 Likes
Doing a series of straight calculations is no problem so go ahead. What you don’t want to do is:
- Iterate over large Lua tables, run long for-loops etc in update(). Of course you might need to do that in some cases, just be a bit careful.
- Do stuff in update() on a large amount of game objects. You can have hundreds of them but that will eat up a portion of your 16 millisecond budget.
- Send several dozens of messages each frame. Messages are relatively expensive and is intended to be used for high level logic.
Note that you can go pretty nuts on a desktop machine and see little impact on performance. So you should test on your target platform (for instance, iPhone 4s or what have you) and measure to get an accurate picture of performance.
And like @ross.grams said, don’t overthink optimization too early. For example: you can often reduce data processing time substantially by rethinking how your data should be organized, but you will not know all your data until later in development. You can make a note if you have something that you might want to come back to later to measure and optimize.
4 Likes
It’s a common misconception that doing stuff every frame or iterating over tables is too slow. In fact, it can be slow, but you have to have lots of computations and elements, which is rarely the case. Iterating over a table with thousand elements each frame is totally fine.
Besides Defold uses LuaJIT, which significantly speeds things up.
1 Like
It really depends on why you are iterating over a thousand elements every frame. Are you running AI agents for every element? Summing up some value? Moving along a trajectory? It really really depends on the specific case and you need to run on target device and profile to know.
3 Likes
I wrote a culler that iterated over a few hundred table elements each frame and did some calculations. It consumed about 1-2 milliseconds (on an old iPad) if I remember correctly. It was worth it because it relieved the game from a lot of rendering.
Yes, you can iterate over thousands of element but on an older phone you won’t have much time left for anything else - if even that. LuaJIT does not work on iOS.
4 Likes