Thank you for your time. I respect you deeply and have valued your work.
For box2d, in the past I added a function to delete the entire contact cache and then I experimented with either calling that every single frame on both client and server, or only during a rollback.
In one game, I did the former and in most others, I did that latter.
In those box2d games, the entire world was predicted/resimulated, including remote players. A smart smoothing technique was used on remote players to dampen network artifacts. It worked well, even sniper rifles worked well. (The player movement had a certain flavor)
I am currently building something custom on top of Jolt, but will experiment with box3d.
The smart detection of what needs to be resimulated is something I'm just about to start on.
My mind is turning on how partial resimulation could be done on top of box3d's 'keyframe' recording system....
Hey Glenn, what do you mean by 'rollback determinism'? Is there some particular thing missing from Box3D now that makes it difficult to synchronize with solely the inputs?
My reading of Box3D's docs is that it has 'cross platform determinism', and 'recording/replay'? Isn't that sufficient?
Synchronize inputs, determine if inputs were 'mispredicted', if so, rollback the physics world, apply the changed inputs and resimulate?
Just for context: I implemented state-sync netcode into box2d in 2018 and shipped multiple real games using it - and I work on netcode professionally.
I'm planning on adding full netcode support for box3d and releasing it as part of a larger framework.
It's funny, I've also been trying to use AI to implement (simpler) shadow mapping code and it has failed. I eventually formed a very solid understanding of the problem domain myself and achieved my goals with hand written code.
I might try to implement this paper, great find! I love this 2000-2010 stuff
Gemini & ChatGPT have not done well at writing or analyzing OpenGL like rendering code for me, as well. And for many algorithms, it's not good at explaining them as well. And for some of the classical algorithms, like cascading shadow mapping, even articles written by people and example source code that I found is wrong or incomplete.
Learning "the old ways" is certainly valuable, because the AIs and the resources available are bad at these old ways.
It's a common misconception that this is only used in fighting games. This technique was developed first in Duke Nukem, and then exploited heavily by Carmack in Quake, and subsequently refined and built upon in other AAA FPS games, specifically for the local player movement and shooting.
I've been watching a ton of Tsoding lately. I really like nob.h his build system and I've been using it in my projects. Why we ever used a different language to build C/C++ seems so insane. Using the same language for the build system is just far simpler
You likely won't need to do manual memory management nor think about undefined behavior. If your writing basic c++ to handle the simulation in a game, it's going to be pretty orthodox and these problems likely won't manifest.
The purpose of recommending c++ here is:
If GDScript is too slow, reach directly for C++.
I'm specifically recommending GDScript over C# for ease of use and c++ over C# for performance.
> you will stagnate if you don't learn to use the new tools effectively
I've been going the other way, learning the old tools, the old algorithms. Specifically teaching myself graphics and mastering the C language. Tons of new grads know how to use Unity, how many know how to throw triangles directly onto the GPU at the theoretical limit of performance? Not many!
"not having a JIT" is not a problem, it's you speculating that a JIT will improve performance, the real problem is "GDScript has poor performance", which in this context (me saying C# in godot sucks) is you speculating that C#'s performance is better than GDScripts. Do you have any data to back that claim up? Like real world data from a real product? Or are you just speculating with vibes?
If performance is a concern, skip C# and go straight to c++. Now your ripping at max speed with the smallest binary! That's my whole point. GDScript + c++ is my point. Ditch C# it's not worth the squeeze.
You only dabble in the c++ for the sliver of the project that needs it. 90% of game development is animating stuff and user interface development. GDScript is great for that.
Writing C# in godot is a bad choice. Use GDScript and directly write c++ as a module. Skip "HD extension" completely. Godots build system is easy enough to use. Just add new classes to the engine using c++ if you don't want to use GDScript. The GDScript workflow is honestly great. Using C# is like the worst of all worlds.
Thank you for your time. I respect you deeply and have valued your work.
For box2d, in the past I added a function to delete the entire contact cache and then I experimented with either calling that every single frame on both client and server, or only during a rollback.
In one game, I did the former and in most others, I did that latter.
In those box2d games, the entire world was predicted/resimulated, including remote players. A smart smoothing technique was used on remote players to dampen network artifacts. It worked well, even sniper rifles worked well. (The player movement had a certain flavor)
I am currently building something custom on top of Jolt, but will experiment with box3d.
The smart detection of what needs to be resimulated is something I'm just about to start on.
My mind is turning on how partial resimulation could be done on top of box3d's 'keyframe' recording system....