#data oriented programming

[arbitrary-fascinations]

Why is there always so much weird drama in software development circles? I've been trying to learn more about low level programming. I already know C, but I am interested in all these newer programming languages, so I've learned some Zig and some Rust. But there's this weird animosity between fans of each language, or maybe more accurately between Rustaceans and the broader C/Zig/Odin/etc group.

To be clear, I think that for the most part the thought leaders on both sides are perfectly reasonable, and that they have differences in philosophy that are within reason. But the broader communities lose the nuance and turn things into "if you don't use Rust, you clearly just don't care about memory safety or security in general" and on the other side "only total noobs write vulnerable code with buffer overruns and use after frees, get good and learn how to use arenas and zero is initialization" or in short, "skill issue." On the real fringes, it seems like people are even associating each camp with general political affiliation, which is wild to me.

I just want to find a community of devs who are interested in learning as much as possible about how to write code that doesn't compromise on security or performance, without being weird and elitist about it.

I have played around with languages that are at the peak of conceptual purity and engage in several layers of abstraction, like Scheme or Smalltalk. I have spent countless hours having fun hacking things together in JavaScript and Python. I've just about learned what a monad is. But I know that "RAM/CPU isn't free" is not just an aphorism like "freedom isn't free," but a very relevant fact.

I feel like far from making performance conscious programming about ego driven "no one knows how to code these days, I alone am capable of data oriented programming and cache awareness" we should be thinking of it as a skill we should encourage everyone to learn. It differentiates you from the bottom of the barrel LLMs, and it lets us take back the power from companies that want to sell us new ridiculously overpowered hardware every year to run bloated web apps as desktop apps that have been vibe coded. Let's stop e-waste and write cool software that runs on a Raspberry Pi or a 20 year old Thinkpad. Or hell, go wild and code on an Amiga or something. No data centers required, maybe just a mesh network.

[twofordinnergame]

Dec 30 2019 Update

I am making progress with the new engine paltform/dll architecture.  Migrating my previous code to this new style will take a while.

Here’s what I got so far.

1. I have successfully managed a clean split between layer code (SDL2) in a barebone launcher and the game inside its own dynamic library.

2. I have a very basic custom preprocessor going.  It supports generic programming and has some basic facility for introspection.

3. The compile times are kept to a minimum through a single translation unit design for each component.

4. The memory is allocated just once by the platform, leaving the engine dll the care to manage it.

Some observations, early on:

I can see how the low compile times, if they are sustained when I migrate the bulk of the engine, render pointless the idea of scripting.

I can also imagine what a custom preprocessor can yield in terms of programming power to generate gameplay code from data.

The custom memory management makes me strangely more wasteful in my usage.  For some reason, it makes memory feel cheap not to have to ask for and delete it all the time.  So I am still to figure out best practices for that one.  It’ll come when I integrate back some of my systems, though.

Also:

I  made the transition from vim to emacs and I have learnt quite a lot in the process that may be useful to vim expats. So I might post about that at some stage.

I hope you had a merry Christmas and are enjoying a good holiday season.

[dragonspinegames-blog]

DragonSpine Game Engine - Dev #1

Hey all,

This is the first development log of the DragonSpine Game Engine. Eventually it will be used to run some of the games that will be coming from the group.

The last few weeks have been quite a bit of research and testing with smaller parts of the engine, including rendering and physics. There were quite a few iterations of the engine, including designs of Object Oriented Programming and Data Oriented Programming. From a developer point of view, the Data Oriented Programming is the way to go to make things generic and to keep away from the OOP’s inheritance structure that makes everything become a class. 

Some big takeaways that DOP will have advantages over OOP is the ability to do scripting on anything, not just an Object that defines it. DOP also allows all the data to be considered data all the time, and all objects are data, allowing many objects to be created without their corresponding Object class that is needed. 

Data Oriented Programming uses things we call Systems to do calculations on what are called Components - when using the style called Entity-Component. The Entity can be made up of one or more Components, and then the Entity is fed through a pipeline of Systems. The Systems then take the Components and do any updating on them. This usually happens on a System by System basis, so all Components of the same type are updated in succession. 

This development blog will help me understand some of the finer tuned components of DOP, which I am still fairly new to myself, as well as give some insight into what is going on currently with the game engine and game development. 

Data Oriented Programming for game engine’s is not something new, nor is it an easy task. I guess we’ll figure a lot of this stuff out together, as today is the day that I move from the “testing” phase to the “implementation” phase. 

We’ll see how it goes.

- Mitch