Feature request: logicUpdate()


Hello i’m aware of postUpdate() and preUpdate() in the game loop.

From my point of view i think like:

  • PreUpdate : These systems are the first to be updated in the game loop, they are generally used to retrieve user input, or manage network events for example.

  • LogicUpdate : These systems are the second to be updated in the game loop, they are generally used for game logic such as movement or collisions for example.

  • PostUpdate : These systems are the last to be updated in the game loop, they are generally used for rendering or interpolation for example.

I dont know where i have to update my logic systems when i inherit from bs::Application

So i implemented something like this:

class bsf_world final : public shiva::world, public ::bs::Application
        bsf_world(const ::bs::START_UP_DESC &desc) : ::bs::Application(desc)

        void preUpdate() final

        void postUpdate() final

If i’m following the game loop https://gafferongames.com/post/fix_your_timestep/

Which look like your game loop.

For example:

 while ( !quit )
       // There is preUpdate
        double newTime = time();
        double frameTime = newTime - currentTime;
        if ( frameTime > 0.25 )
            frameTime = 0.25;
        currentTime = newTime;

        accumulator += frameTime;

        while ( accumulator >= dt )
            previousState = currentState;
            integrate( currentState, t, dt ); // This is a logic update (60 fps)
            t += dt;
            accumulator -= dt;

        const double alpha = accumulator / dt;

        State state = currentState * alpha + 
            previousState * ( 1.0 - alpha );

        render( state ); // This is a postUpdate


this is a good place for logic_update before scene_update no ?

For resume i also want in my application to process fixed_update on my logic systems

Can you tell me where i can put my logic systems ? or if you plan to implement a function like logicUpdate ? Thank you very much !


Either in preUpdate after the base class call, or in postUpdate before base class call. That will yield the same behaviour as Component::update(). If you rely on any Component then choose preUpdate if you want your code to execute before Component::update(), or postUpdate if after.

I wouldn’t be opposed to PR with a fixedUpdate call that can be overridden.