[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Time in games and multimedia
Hi All,
I haven't seen much discussion about time management in the messages,
may be is it because
it doen't fit any sub-working-groups tasks. Well let's start.
Of course, every thing I wrote here can suggest you some remarks. They
are welcome.
Nescessity
Animations must be timed in the strong way.
That is, independently of the frame rate.
This allow very fast computer to propose a still playable game
This also permit precise synchronising of sounds and video
Almost all games require a timeout function, an alarm.
Ex: trigger function EndLevel in 5*60*1000 millsecond.
Ex2: trigger {sound"What are you waiting for ? Christmas ?"; } in 1
minute.
a keystroke or mousemove event would remove this alarm.
Ex3: A grenade explode in five seconds.
Implement
I made a very small librairy in C that have the self explaining
functions:
- AddCountDownCall(delay_in_millisec, function_to_call)
- RemoveCountDown(ID_returned_by the_previous_call)
- CheckCountDown()
The last one is call at each frame; and trigger the function if delay
has elapsed.
Two kinds of use:
The first case of use is the standart "A grenade explode in 5 seconds"
where the grenade explose if you wait 5 second. ;-)
The second case is when the function that is called behave differently
with respect to the time at which it is called.
A object moving in straight line has to be drawn at a
a diffrent position, even if the drawing function called is the same.
In
such case, the delay is 0, which mean "trigger this function at the
next
call of CheckCountDown()";
It can also be used instead of a swicth variable.
Ex: In a Doom-like game, if (user_want_ammo_window == 1)
{draw_window()}
could be replaced by a constant alarm with delay=0
In a Doom-like game, the "if" statement has to be checked each
time -- this is a speed-penalty
With an alarm, the draw_window() function can't be in-lined --
also speed-penalty
This can also easily allow plug-ins, because the format of function
called by an alarm is fixed.
Future additions
- Implement classes of countdown alarms (Program-specific new ones)
Ex: Class CD_REMOVE for removing all moving objects from display
Class CD_DRAW to draw object.
This prevent overlapping objects from being badly displayed.
Class CD_AUDIO if audio is computed/mixed/handled at
specific time,
or by an external program or simply to allow
game-specific-optimisation.
- Treat (delay=0) countdown in a faster way (no time checking)
- General animation-multimedia API (CD-ROM, DVD-ROM)
This is more a complete re-think than an simple addition.
Animation is a time ordered list of steps (alarms), but the
difference with alarms is that
each step is made of several function calls.
Ex: anim={(delay=0, step=user1), (delay=1, step=sys3), .....}
with step(user1) = {
function_one(a, b, &c);
function_two(c,&d);
.....
}
and with step(sys3) = { goto(step1); }
user type of step are enterely
developper-defined-written-and-called functions.
sys type of step are predefined features for navigating
throuht the anim, lanch another anim,
load resources (pict, sound,...) ----> SCRIPT LANGUAGE
Handle for user input in coordination with the GSDK GUI.
It is in a thought-maturation phase for now.
Useful to adjust parameters of an animation (or visual effect)
without having to recompile each time.
Ex: And what if add a palette change during my nuclear explostion
?
Useful to add a little plus in non speed-critical part of a game
(Setup for instance)
Ex: A game setup window where you want the GUI's widgets to slide
to their position (or to fade up, or whatever), with sound
- Loops, ping-pong anim, reverse play (to be precisely defined)
Well source code in C for the alarms are on my hard disk for now.
Tell me if you want them.
Maybe GSDK need a General Section.
.