dustbunny

The mindset that "everyone else is doing it" or "if I don't do it someone else will" is common amongst psychopaths and it reveals a deep cynacism and lack of consciousness. Often, the person is wrong as well.

Im from the same area, never saw a rat until I moved to California.

This is just straight up false. You can compile subsets of the engine even in Godot 3. Godot 4 has made this a first class citizen.

C++ coding is just fine. It's not painful. It can be a bit of boilerplate to expose c++ member fields and functions to the rest of the engine but you get some great power out of that. Just use compile your own module right into the engine. Don't use gdnative.

As someone who's codes a lot of c++ in Godot I really am not sure what your talking about here.

SDL isn't even in the same dimension of usability compared to the Godot editor.

Calm down. This aggressive response to having your ideas challenged is exactly the type of thinking you resent in your political opponents.

> Trucker protest is _all_ pro trump anti vaxxer / ivermectin

This is black and white "us vs them" thinking. This is fundamentally false and your inability to parse truth out of your political opponents positions will make your positions meet more resistance, ultimately you personally less influential and less useful to your team. Perhaps even net negative.

> Wouldn't touch the Alberta separatism

I am from Alberta. Alberta separatism is far less relevant or popular than the media makes it out to be. Im not sure how to make sense of the difference between CBC's reporting and my lived experience on the ground in Alberta, but everyone around me here is pro Canada and against separating. Even the rural conservatives. I have literally never met someone who actually wants to separate from Canada.

Id like to suggest that you rethink your opinion on the trucker caravan protest.

It is a reasonable position to frame them as opposing authoritarian government policies and for the governments response to be overreach.

The popularity of the trucker protest made and makes sense. Big anti government movements like that attract all sorts of bad actors and the media and government worked to highlight the worst aspects of that protest.

Mentally reducing the trucker protest to "thus Canada is bad" makes you seem like the type of black and white American fool that has created the political environment in the USA.

SK catching a stray here undermines the unity we are seeking.

Uranium and potash from SK are huge bargaining chips.

AB separatism is meaningless and it's emphasis and influence is propped up by Canada's adversaries.

What use cases is Tiger Beetles architecture not a good fit for?

When tiger beetle becomes pluggable to different use cases, how should I think about "do I want tiger beetle?"

How was this done?

Proven technique is an Appeal to Authority. You have offered no real first principal evidence for your claims. Here's some evidence in favor of flecs:

I find value in its reflection and serialization system, as well as it's pipeline API.

Games require far more than a bunch of arrays. The simulation code itself is dwarfed by the UI, VFX, animation and scene layout code. The APIs in Flecs have a lot of value for these "not the core game" use cases.

Conversely, the amount of boilerplate you have to write to stand something up in Flecs is massive. And the use of macros in Flecs APIs tends to break editor auto complete. And the learning curve is very big. And the output code just looks very different from Orthodox C.

Getting nerd trapped fucking around with ECS is a real risk. The rabbit hole goes deep. But the library itself is valuable, powerful and well done.

This is my honest thoughts on ECS systems derived from first hand experience.

This is what ECS frameworks like Flecs can help with. They provide the tools and abstractions so you can write heavily modular code in this model. If you don't need the generic modularity, flecs will not feel like your gaining anything for the boilerplate you gotta write and the stuff you gotta learn, but if your making something huge that needs work for years, learning flecs is probably worth it.

This is a reductive ad hominem, not a first principals examination.

> My experience with ECS is that you shouldn't use an "ECS system"

Why? Flecs, for example, is pretty sick imo.

The real key pillar to this world view is putting the data first in your design of the algorithm.

So if your working on a physics engine and your optimizing collision detection, you think about the data in -> data out of the problem you are solving as the primary driver of how the code should be written.

You start with defining the data, and build from there.

Different types of applications all have different shapes of data so would have differently shaped optimal code. Eg) a physics engine would use some kind of spatial hash thing which can be optimized differently based on if stuff can be added/removed while it's running. A 3d renderer operates on big buffers of matrices and vertex data. A game is usually composed of some long lived things and a lot of short lived things.

The key message in Mike Acton's talk was:

"If you have different data, you have a different problem."

While ECS systems are not a panacea that solves all problems in a perfect data oriented way, they are generally more malleable than Object Oriented hierarchies. This means it's generally more feasible to write "near optimal" code in an ECS framework than in a mature Object Oriented code base.

But the key message isn't "use X framework", it's "start by defining the data".

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.