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.