dustbunny

Casey Muratori and Jon Blow have pushed this concept frequently.

They largely don't deeply elaborate, which is sad because I am a professional game developer who is interested in precisely presented knowledge so I can apply it to my work.

My interpretation is that games want to allocate large pools of resources, like GPU buffers, cpu memory, etc, and reuse that memory over and over. Ie: Reinitialize it.

In my experience, RAII is my preferred pattern for certain things (std::lock_guard), and you can almost certainly express the majority of these "uber game dev patterns" using RAII/smart pointers/etc, but the c++ implementation of these "uber game dev patterns" tends to be more complicated (and imo esthetically ugly) compared to really well written C.

These new languages (zig, odin, jai) appear to be attempts to improve C to allow an alternative to C++ that doesn't have the ugly baggage that C++ has.

Awesome, thanks for engaging with me and talking to Erin about it.

I hacked together world cloning in box 2d and am confident I could do it in box 3d as well. Especially with the record/replay/validate system to help guide the implementation.

I'll find a way to send you and Erin my project when I get it working (or when I fail)

I see. This helps a lot thank you.

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.

https://box2d.org/documentation3d/md_simulation.html#autotoc...

Perfect. Now I can continue to be confused! Beginner mindset!

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.

Why not use elementary OS which looks far better?

It's called Haiku now I think

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

Lots of excellent games are written in Python, Lua, JavaScript and GDScript. These abstract criticisms are just that, abstract.

I'm offering real practical advice from experience of having worked on real projects.

I'll make it real clear:

GDScript & c++ > C#

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.

Why Hong Kong? I guess you have a bunch of contributors near there?

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.

Yeah that's why GDScript is great.

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.

This has to be sarcastic right?

So do you keep it chilled 24/7 or do you turn it on manually or with a timer?

My main point is: if GDScript isn't good enough, go straight to c++ directly in the Engine.

I won't even get into how big of projects I've written in GDScript successfully.

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.

How do you create/store the ice?

I find it distasteful when women write articles about mens inner emotional lives. Why couldn't the NYT find a man to write this article?

"wouldn't pass fang interviews"

Bellard wouldn't apply and be interviewed like some Stanford grad. He would be head hunted and told he can do whatever he wants and receive a massive amount of compensation.

I'm not sure why you woulf assert he wouldn't pass the interview that seems totally outrageous.

I have a 17" XPS and it's great as a computer for that floor of the house. Ie: for sitting at the kitchen table or the couch. I have a 13" for portability which is great because it's so small and light.

MacBook pros these days are really heavy. Having a MBP and an Air is actually a fair inventory but the MBP is just so expensive.

I do like the desktop form factor of keyboard and monitor but the 17"er is nice to use while I'm up making coffee in the morning or while sitting on the couch at night

What's your angle on the Chamath link? Is Nvidia greasing Sack's favour through Chamath?

Congratulations to Chamath

I also strongly disliked luas syntax at first but now I feel like the meta tables and what not and pcall and all that stuff is kinda worth it. I like everything about Lua except some of the awkward syntax but I find it so much better then JS, but I haven't been a web dev in over a decade

So many of these voxel engines suck, but it appears that this person totally nailed it. Bravo

Seems totally pointless to throw his own community under the bus with the initial paragraph. The first paragraph serves no purpose other than illuminate that ginger bill didn't want to write this, and is only writing it because we are too stupid to read his documentation.