Change to Variable Time Step?

There's alot of detailed route for OpenBVE around the world. Many player reported that sometimes there is a lag spike(which I assume it's loading some detailed object), after the lag spike, the train toppled/missed the station. This also happens to me sometimes. Multiplayer isn't officially released for OpenBVE, So should OpenBVE change to variable time step instead of fixed time step?(I am not an expert on these stuff, please let me know if it's not possible)

Personally, I only experienced such a lag spike (and missing stations plus toppling) in the 2020-04-17 daily build, never before. Do you know what OpenBVE version(s) it affects?

Phonteus Nevolius wrote:Personally, I only experienced such a lag spike (and missing stations plus toppling) in the 2020-04-17 daily build, never before. Do you know what OpenBVE version(s) it affects?

All versions(It won't happen if you have Load in advance checked)
Or if you have a high end pc/not too detailed object, this won't happen too.

So the problem you mentioned is that, the rendering thread gets freezed for loading heavy-weight models while the "calculation" thread in the background is still running, and that causes the unpleasant sudden spike. Am I understanding it correctly?
I don't know if openBVE is running the rendering and the calculation on seperate threads so that the spike is caused, or it is because openBVE uses deltaTime to calculate physics.

Anyway I think tieing the physics calculation to the rendering is not a good idea. I would rather encounter a spike than having the program running in inconsistent speed. If openBVE does not compensate the amount of time skipped during the lag and introduce a spike, the speed of the simulation will become inconsistent. That means the trains run slower when it is more laggy and faster when less laggy (You would occasionly encounter minor lags intermittently on lower-end devices). That is just terrible for a trainsim game.

I think a solution is to seperate the loading thread from the rendering thread, so that loading models does not freeze the screen. That should prevent the freeze from the first time, but would also cause disappearing models if they are not loaded in time.

Unfortunately, the physics are intertwined with the render thread. (and everything else for that matter)

I'm slowly working towards untangling everythig, but this is a really major job, and something that's likely to continue for a long time to come.

Incidentally-
There's nothing whatsoever in the build from the 17th that could (or at least should) affect speed or anything.

leezer3 wrote:Unfortunately, the physics are intertwined with the render thread. (and everything else for that matter)

As I understood, Mr.LXQt said that the train "jumped" after the major lag. So you are using deltaTime for physics calculation?
Lagging due to model loading is quite common in games.
One solution would be to use frame-based physics calculation, like Densha de GO Pocket did. The simulation speed actually drops if the device cannot run it at 30fps. In that way there would be no "jump" because of lags. (This game does have that problem, the render freezes shortly before arriving at each station for loading the platform models on my PPSSPP, but it does not try to compensate the time lost thus no "jump") That would certainly not be a nice solution for openBVE.
So I can think of two different solutions:
One is to substract the time used to load the models from the deltaTime, to prevent "jump" after the game recovered from a lag.
Another is to run the loading asynchronously from the rendering.

BTW Mr.leezer3 really sorry for being annoying but could you please take a look at https://github.com/leezer3/OpenBVE/issues/459#issuecomment-616981129

It's a little complex.

Everything runs on delta time (which is derived from frame time), but only upto a point.
Some stuff is calculated off the actual in-game time, which is derived from the delta time.
Finally, there's other bits which run on the delta, but from last run of said function.

As a rough idea, some things start to fail badly when the frame time crosses ~0.5s
Lag spikes are generally on block boundaries (25m), and it's really difficult to stop them; Models and textures have to be pre-loaded at some point, and until things are separated a bit more, it'll still be a problem.