Help me embed demos in my game :)
category: offtopic [glöplog]
speeder, to answer your earlier question, yes you typically recompute the whole thing (whatever the "thing" is that you're dispaying) from scratch on every frame.
the only "optimization" i would consider is storing/precomputing some data that never changes across all frames and is used by many of them. but first do it without all that, and only optimize if it's too slow. good chance your simple effect will take 1% CPU time. doing a lot of effort to bring that down to 0.5% is absolutely useless in virtually any situation.
trying to reuse results from the previous frame typically *severely* complicates the code - because you don't have a constant frame rate, there are all kinds of odd edge cases you may need to take into account. only do this if you're coding realtime raytracing on a vic-20. or something.
in general, demos animate just like games do. in a game, you typically compute the new scene based on user input (moved character, changed viewpoint) and time (moving enemies, etcetera). in a demo, we don't do user input, so you compute everything based on time only.
this means that you don't need to use "previous state" (i.e. where was the player in last frame?) to computer "current state" (so where is the player now?), but you can simply compute it from some starting position and some trajectory (e.g. a spline or whatever) each time. in some cases, making such a computation a bunch of times is much simpler than keeping track of all kinds of state in each frame. it feels inefficient, but don't forget that you're only doing it each frame, so 60 times per second. a 60th second is a *LOT* of CPU cycles, even on slow computers.
hope this helps. please tell me if i'm answering the wrong question, too :-D
the only "optimization" i would consider is storing/precomputing some data that never changes across all frames and is used by many of them. but first do it without all that, and only optimize if it's too slow. good chance your simple effect will take 1% CPU time. doing a lot of effort to bring that down to 0.5% is absolutely useless in virtually any situation.
trying to reuse results from the previous frame typically *severely* complicates the code - because you don't have a constant frame rate, there are all kinds of odd edge cases you may need to take into account. only do this if you're coding realtime raytracing on a vic-20. or something.
in general, demos animate just like games do. in a game, you typically compute the new scene based on user input (moved character, changed viewpoint) and time (moving enemies, etcetera). in a demo, we don't do user input, so you compute everything based on time only.
this means that you don't need to use "previous state" (i.e. where was the player in last frame?) to computer "current state" (so where is the player now?), but you can simply compute it from some starting position and some trajectory (e.g. a spline or whatever) each time. in some cases, making such a computation a bunch of times is much simpler than keeping track of all kinds of state in each frame. it feels inefficient, but don't forget that you're only doing it each frame, so 60 times per second. a 60th second is a *LOT* of CPU cycles, even on slow computers.
hope this helps. please tell me if i'm answering the wrong question, too :-D
