[Bf-gamedev] Proposal: finer clock management

[Mitchell Stokes]

The easier method would be to have a multiplier for the current timestep. A
greater than one multiplier would cause an acceleration, and less than one
would slow things down. Suspending would have to be handled separately.

--Mitchell Stokes
On Nov 22, 2013 12:46 AM, "Arnaud Degroote" <arnaud.degroote at laas.fr> wrote:

> Hi, I want to propose some mechanisms to allow better clock management
> at the Game Engine Level.
>
> At the moment, there is globally two tick models, one 'real-time' with
> possibly frame drop, and another one which basically 'render all frame'.
>
> What I would like to do is to be able to 'accelerate' game engine, (i.e.
> make the world move faster than 'real-time'), or 'slow-down' the world
> (bullet effect-like) or even 'pause' the world.
>
> To 'pause' the world, I can just use suspend(). For 'slow-down', you can
> do it in some complex method, using suspend() at different intervals for
> different scenes to get more or less the desired behaviour, but it seems
> quite complex and costly. To accelerate the world, as far as I know,
> there is no easy way to do it.
>
> What I propose in these patches is to allow a 'user-settable' clock,
> i.e. the possibility for the developer to finely control how the time
> elapse in its game.
>
> The next issue is how to call it. Calling it from a 'normal' logic block
> is a bit dangerous as, if for any reason, you don't make the time
> progress enough, there is good change that your logic brick won't be
> called anymore.
>
> So, one safer possibility is to use the 'main python controller' (see
> KX_GetPythonMain) but it may a bit overkill in lot of situation. Maybe
> we can add another special property (such as __main__) (I think at a
> __clock__ property), and call it automatically, if it exists in
> BL_KetsjiNextFrame.
>
> I would like to have your opinions on my goal (maybe I miss some easier
> way to achieve it), current attached patches, and proposal to continue.
>
> Thanks in advance. Best regards,
>
> --
> Arnaud Degroote
> Postdoc
> RIA LAAS - CNRS
>
> _______________________________________________
> Bf-gamedev mailing list
> Bf-gamedev at blender.org
> http://lists.blender.org/mailman/listinfo/bf-gamedev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-gamedev/attachments/20131122/55fcf416/attachment.htm