Thread by @NewoGame

The main reason i dont open source my homebrew is because the code is super messy and experimental. Its wasnt written to ported like doom or quake. Lets look at newozero; #thread

In nz the track, the player and the camera are basically co dependant structures. Joined at the hip. Though drawing the track is separate strangely enough.

The track is using a spatial grid, frustum, distance list and a big array to figure out what to draw and collide with the player. It also tells the camera where to look.

Basically everything is stored in structs ala C. Whenever i can store a value instead of calculating it i will pin it to the struct without mercy

Every module has a init(), animate(), draw(), gethits() and a exit() function. There are roughly 40 c files including wind, road, building, sign, grid and stars.

Everything runs on a timer. All the time. Definately not framerate independent so it has to be 60fps or not at all. Timers are everywhere waiting to fire all the time.

The only reason most if it even works is by knowing exactly which systems interact with each other and ensuring that none of them end up stepping on the others.

There is no threading. Alot if it is time splicing and ensuring that the per frame cost of everything is low. If a tree falls in the forest and there is no one there to see it does it make a sound? There are no falling trees.

There can be no intesections on the track because of how its drawn. I could refactor it in the future but it will not be pretty. Too many things to change. Too many optimizations to undo.

All the signs know which building they are posted on. So since there are 4x more signs than buildings they all check if the building they on is visible instead of using the frustum. Saves so sqrts.

The menu is a recursive function that draws itself similar to how you print out a directry structure. Over all my years of coding its the only time i have found such a simple solution to UI. All the menu options are pointers to in game global variables. #gamedev

I rebase my code often once i find a cheaper way to complete a task. Because i am the only one working on it i can add/remove optimizations based on what i want to achieve instead of whats more compatible.

Git doesnt add anything to my workflow. I dont miss any of the code i delete. It either works or it doesnt. Sometimes i am tinkering with multiple modules to get one thing to work. If it doesnt work then rebase.

Here is an example of a system in the game where the track is drawn based on the position of the player and the frustum but there is a bug in this video. who can guess what the bug is?

Even the math functions i use are crude. I took a look at the standard frustum culling code and was like; nope i am just gonna do everything with AABB. Octree? Nope, spatial grid. Linked list? Nope fixed arrays.

If you have any questions about how any of it works i am always willing to help. It may seem complicated when its all put together but its really just a collection of simple parts.

Oh the spatial grid had a bit of magic so avoid that just do an octree.

I do put comments into a few sections but its mostly for things NOT to do as opposed to the thing being done. If there is a section which look like it can be easily optimized but shouldnt i will put a comment there to stop myself from doing the obvious. #gamedev

Some times i imagine i would have an easier time writing homebrew games on the ps4/5/switch/ #unity /3ds/#UnrealEngine5 but i fear i might fall into a shader rabbit hole and never come back out. #gamedev

I use multiple paradigms. depending on the situation. Sometimes they converge+overlap. Modern code tends to try to stuff everything into OOP. I like to wild out ex; procedural, functional, passing by val, by ref, time splicing, partitioning, whatever gets the job done

Predicting which paradigms I use for which problem depends on several things; the time it will take, speed, complexity, code size, maintability, error rate, magic etc. So you cannot blanket the code with ECS or something like that it will just break in mystical ways.

Some systems (the track) have multiple variables scattered over the code that can be tweeked for a desired result. This means that there are multiple places where you could uset the system or cause a domino effect. Its like climate change the video game.

look at this; why am I doing this?
static bool seek_back=false;
seek_back = !seek_back;
if(!seek_back) for(int i=0; i<TRACK_MAX; i++) game_track_seek(i);
if(seek_back) for(int i=TRACK_MAX-1; i>0; i--) game_track_seek(i);