Third party systems and deltatime.

BlitzMax Forums/BlitzMax Beginners Area/Third party systems and deltatime.

tonyg(Posted 2007) [#1]
If you use deltatime and a third system (e.g. Particle System) how would each particle be adjusted for the current framerate?


JazzieB(Posted 2007) [#2]
Would probably depend on how the author of the system went about things. For example, are there seperate Update and Draw Methods/Functions? Is there an option to supply a delta or tween value to the system? Failing that, it may have to be done by brute force and the code modifed to suit your needs (provided you can see the code).

If you have a particular system in mind, then try contacting the author, as they'll be able to provide the answers you seek. If their system doesn't have any timing methods built-in then you could always request it, as it would be in their best interests to provide this functionality.


tonyg(Posted 2007) [#3]
Thanks for the response JazzieB.
I can't remember seeing a particle system which allowed for timing to be input. As there are numerous timing methods I'm not even sure how it'd be done without dictating which method to use or having access to the source code.


sswift(Posted 2007) [#4]
All my systems take a time step to update them if needed. If you want a 2D particle system for BlitzMax, my sprite system won't automatically spawn them for you from emitters, but it will animate them for you, and making your own emitter type isn't too difficult. Plus it's useful for animating a thousand other things as well.

I'm actually surprised to hear that you haven't seen a particle system that supports variable timing. That's kinda crazy.


tonyg(Posted 2007) [#5]
Thanks for the response.
I've got your Sprite System and will get around to using it at some point. However, I simply want to write my own Particle System. In that case it's easy to pass my framedelay.

I'm actually surprised to hear that you haven't seen a particle system that supports variable timing. That's kinda crazy.


Maybe I've missed something. What methods do they use?


Grey Alien(Posted 2007) [#6]
I've integrated sswifts physics and sprite system with my framework in the past and my framework uses a delta time variable for it's own particle systems. So what you need to do should be possible, good luck!


sswift(Posted 2007) [#7]
tonyg:
I'm not sure what it is you are asking.

In my sprite system you call Animate.Update() with the number of milliseconds the last frame took to render.

Any particle system should have the same sort of update function. That tells it how far to step forward for the next frame.

If they don't require you to pass a value like that, then they probably assume that you update your game logic at a fixed rate, say, 60 times a second, regardless of what the framerate is. So all the speeds and things you input would be X number of pixels/units per 1/60th of a second. Many of the Blitz3D demos used this kind of timing. I think it's a pain in the ass, but it does help make physics more stable and allows you to record demos. But it also makes it difficult to do things like hide objects at just the right moment without having them potentially fade out if you're doing it by changing alpha for example. Deltatime is much easier. Of course you could also combine your fixed update rate with a fixed framerate, but then your game will slowdown if the framerate dips below whatever you chose.

But I'm really getting off subject here I think, cause I don't really know what you're asking. You sound like you know how to implement delta time. I'm not sure why you would be confused about calling two update functions instead of one with the same delta time variable each frame.


tonyg(Posted 2007) [#8]
@SSwift, I saw your code used a timeelapsed parm but what made you use this rather than a speedfactor parm defaulting to 1.0?
<edit> I think the problem is I'm trying to leave too open a question. If I write a Particle System (for example) and give it to somebody else what would be the best method so they can plugin their own 'timer' code?


sswift(Posted 2007) [#9]
Tony:
Because it's easier that way if you are drawing frames as they are ready. One frame might take 0.005 seconds to render, the next 0.002 seconds. I could have a function which sets this value, but under such a system you'd have to have that function call every frame.

This way works well with either method. If you have a fixed frequency update, then you can just stick a constant in there when you call the update function every frame. And if you do updates like me, then again you just need the one function call.

As for the best method, as far as I know, the method I'm using is the best method, as far as balancing simplicity with flexibility goes. Write the system so it can handle variable time updates, and it will be able to handle fixed time updates as well.

And the way you make it handle variable time updates is to pass it the number of milliseconds elapsed, and use that to add to your timers, and divide that by 1000.0 to get Time_Delta_Sec# which is the number of fracitonal seconds that have elapsed, and multiply that with your movement distances.

(Passing the milliseconds will probably be a little more accurate than passing the Time_Delta_Sec# to the function and trying to get the milliseconds back from that value, but I don't know if it would really make a difference. I require the milliseconds the frame took rather than the seconds because most users will know how to get that easier.)


Grey Alien(Posted 2007) [#10]
So you are many a particle system hey? I think it would be easiest for other developers if you just had an update function that took a delta time value. Then your update function can move/fade etc all the particles by speed*deltatima. Of course he developer will have set speed to an appropriate value for their framerate when they first created the particles. This will be simple for people to understand.