Nebula

Hey all! Been a while, huh?

About a month ago, I wrote about the 'theoretical' side of how my engine is going to work. I spent a little bit expounding on tuples and yadda yadda yadda...

Let's talk about some concrete implementation stuff.

As a programmer, one of the hardest parts of writing code is tracking dynamic values. When memory allocation is involved in any way, you're either passing around handles to allocated values that your operating system has generously given you, or you're using a garbage-collected language that does all the handling behind the scenes.

This is kind of non-optimal: it forces you to either do all the management manually or forces you to think like the garbage collection algorithm (something that Java programmers are encouraged to do.) When I restarted work on Nebula back in June of last year, one of my goals was to eliminate memory management all together in favor of statically-sized.. everything.

Here's the deal. When personal computers were in their infancy, there was little to no room for automatic memory management. BASIC didn't have any memory management of any kind (at least, any that was exposed to the programmer). If you wanted to write a performant game, you were writing in assembly, which essentially meant you had the entire host machine's memory space to yourself.

This is beneficial for a couple reasons, but the main one is that there's nothing sitting between you and what is, essentially, a large blank slate that you can populate with bytes. Want an object table? Map out a memory range for it and write a few subroutines to manipulate it. Want a scratch buffer for text entry? Map it out in memory! The idea was that you'd map out areas of memory to be used for some portion of your data, and your code would respect that.

This was nice in the era of small machines, but now with multitasking operating systems that can spawn dozens of processes, virtual memory and memory management techniques reign supreme.

I don't like them though, so I favor the approach mentioned prior.

In my current documented setup, everything in the game is a 512-byte value, split into two 256-byte hunks, which are then split into 8 32-byte values. What this means is that you can store tuples like so...

(Player, FooBar, Position) -> (10, 20).

...Where "(Player, FooBar, Position)" is on one 256-byte half, and "(10, 20)" is on the other. The reason for the sizes is that at minimum, a 'unit' of block-based storage (think harddrives and other storage drives) is 512 bytes. Some drives have 4 kilobyte sectors, but we can tweak things at compile time.

This kind of a structure forms a multi-key, multi-value database at very little cost. Storing things like objects with attributes is as simple as manipulating key/value paths like you would in traditional OOP languages. And since all of the keys don't need to be dynamically allocated, we can shove everything in a large static array and have the OS take care of the allocation for us! Hoorah for less overhead and fewer problems!

Saving your game state is also as simple as mapping a few dozen blocks from your hard drive into memory, copying the game state over, and bam! You're done!

It's kind of a cheap way to avoid memory allocation, as I don't have to handle dynamically sized tuples, and I get an easy serializable format for free!

What the above also means is constant memory size. If I compile the engine on my machine, it should use the same amount of memory on mine as it does your's, no questions (even regardless of the OS!)

I'll write more on the details of this soon (I'll also have some actual code to show!)

Cheers,
imode