About tearing when writing to the display. We have looked at several methods for updating the display. locking, page flipping, etc, There are also several graphics drivers, different on each platform DOS/Win/Lin, etc.

You can see what driver is in use using SCREENCONTROL(fb.GET_DRIVER_NAME,s). If you want to try and force a driver, set the environment variable FBGFX=driver, where driver is DirectX or GDI, for example.

To eliminate tearing, we want to synchronize writing to the display memory, so we won't see top part a frame and the bottom part of the last. Typically some kind of wait for vertical blanking interrupt. SCREENSYNC is supposed to provide

dodicat wrote:Here is my simple idea.1) fix a frame rate via a regulator, and keep it at that value throughout.or2) Enable various frame rates, but keep the screen motion constant.

I think a fixed frame rate gives more predictable results. In this next demo, I try to expand on your idea to show what can happen. The results are intended to be a bit exaggerated so the differences show up easily.

I had a closer look at your pendulum example and see you are using approximation formula for the pendulum position (angle). i.e. position(t) = formula(t), Also, visually, very noticeable that there are two pendulums with same length, and different periods.

I wrote a version of the pendulum code that:1) uses units: meters, seconds, radians2) shows 6 pendulums3) the top 3 using the approximation formula, at x1, x2, x4 physics frame rates. 4) the bottom 3 using newton laws, numerical integration, at x1, x2, x4 physics frame rates. 5) Can toggle between fixed and variable frame rate.6) press SPACE to add 0.5 second delay and see how methods respond.7) +/- to change starting position of the pendulums8) [ ] to change the pendulum length

First post in a looong time. I've been tampering with a game loop that treats framerate a bit as a damped spring or a constraint. As much cpu time as possible is freed with sleep. By setting the "stiffness" c_sleep to a near 1.0 value, it reaches an equilibrium faster, but you risk large fluctuations. By setting c_sleep to a near 0.0 value, the equation converges slower but is more stable. Press space to give the cpu a lot of heavy work, and notice how it does not affect frame rate:

h4tt3n wrote:I've been tampering with a game loop that treats framerate a bit as a damped spring or a constraint.

Neat! Thank you for sharing. This idea, plus dodicat's idea of regulator, sparked an idea for me. In process automation, to control a continuous process, a feedback loop is used with a PID controller. In this case for example: measure an output variable from the process, like frame rate, or frame time, use it in a proportional/integral/derivative function, to set a input variable to the process, like, sleep time, or simulation time. Too complicated? Probably. I think it's interesting though.

Thanks for the conversions of the tutorial code samples. Short and easy to digest for comparison.

coderJeff wrote:In process automation, to control a continuous process, a feedback loop is used with a PID controller.Too complicated? Probably. I think it's interesting though.

Since I've been working professionally with such systems, I think that, a back propagating AN,could be the anwswer, to the "too complicated" question. Because currently, the engineerentering/adjusting the PID's parameters, has to play the part (of the AN).This is the reason, that such adjustments (based on experience alone) do take quite sometime, until the optimal settings have been achieved (since, outside conditions may vary).

It's implemented as seen here: https://www.koonsolo.com/news/dewitters-gameloop/

Which is an implementation that I found clearer than that of Glenn Fiedler, seen in: https://gafferongames.com/post/fix_your_timestep/

The class is implemented using the Template Design Pattern: https://www.tutorialspoint.com/design_pattern/template_pattern.htm

It's not fully abstract, since the implementation requires a little housekeeping.

The general idea is to decouple the rendering from the updating in the loop, running them at different framerates. In the class, the ticksPerSecond parameter of the constructor determines the framerate of the _update_ loop; that is, the game will run at that framerate, provided it can actually cope with it. If not, the game will simply run very choppily.

The rendering, however, will be performed as fast as it can, and the excess time between updates (if there are any) will be used to interpolate frames for smoother movement. This is especially useful if you're using an integration method like Verlet, since it explicitly uses the previous position to derive velocities. Thus, you can directly use them for the interpolation bounds.

The update() method accepts a deltaTime parameter, which is the one that will be used by the physics simulation. See the articles above for an in-depth explanation of why this value needs to be fixed, and the consecuences of passing a variable time slice to the integrator.

By default, the update() and render() methods are set to do nothing, so to use the game loop, you need to override them in the subclasses with your custom behavior.'/type GameLoop extends Object public: declare virtual destructor()

sub GameLoop.run() '' Runs a single iteration of the loop m_currentTick = getTickCount()

do while( m_currentTick > m_nextTick ) update( m_deltaTime )

m_nextTick += m_skipTicks loop

render( ( m_currentTick + m_skipTicks - m_nextTick ) / m_skipTicks )

sleep( 1, 1 ) end sub

/' And these two are the only methods you need to define in the derived classes, to actually add any functionality to the loop. Normally, you don't need to expose them.'/sub GameLoop.update( byval deltaTime as double )end sub

sub GameLoop.render( byval lerp as double = 0.0 )end sub

/' These two interfaces will define the game and render states that the game loop will use to perform its magic. Here, they are just stubs.

You can design them in two ways, depending on what your application needs: you can make the game loop class be responsible for them (passing the game loop new instances of these) and deleting them when the loop class is destroyed, or you can keep them fully decoupled of the game loop and dispose of them elsewhere. The latter is the method used here.'/type IRenderState extends Object declare constructor() declare virtual destructor()end type

/' This is the custom implementation of the game loop. The class stores two weak pointers to the game and render states, which are injected through the constructor. You can also inject them through mutators (getters/setters), if you prefer.'/type MyGameLoop extends GameLoop public: declare constructor( _ byval as IGameState ptr, _ byval as IRenderState ptr, _ byval as integer )

constructor MyGameLoop( _ byval nGameState as IGameState ptr, _ byval nRenderState as IRenderState ptr, _ byval nTicksPerSecond as integer, _ byval nDeltaTime as double ) /' Don't forget that you need to call the constructor of the base class to allow it to initialize it's internal state. This constructor also allows you to specify the time slice you want for the update() method. '/ base( nTicksPerSecond, nDeltaTime )

/' Here we instantiate the game and render states. Since they are stubs actually, I just instantiate the base classes, but in real code, you'll instantiate your own custom implementations of them (most likely through an Abstract Factory or similar).'/var gameState = new IGameState()var renderState = new IRenderState()

dafhi wrote:your coding skills rock! So accessible, relevant, production-ready, formal and informal at the same time, instructive, general ..

Well, um, thanks...

This way of coding is called programming by difference, and it allows you to lay out a framework to do all the boilerplate, and then only implement the things that change from one application to another. Games in particular are especially suitable for this kind of pattern, as they have a very homogeneous structure that you can exploit.