Ogravius Dev Blog

Learn. Document. Forget. Repeat. ¯\_(ツ)_/¯

Last updated: 2026/04/10

[#0 - Hello world]

Hello.

What is the purpose behind this blog?

The main purpose is to document specific topics as I learn, implement and ‘forget’. I have spent so much time rewriting projects that I have lost count of how many times I threw myself on the ground asking why I solved a particular problem in one way and not the other: this blog is to correct that mistake.

Why bother?

Documentation is generally the boring part of any development. However, too many times I would find myself coming back to topics and subjects that I had learnt, telling myself, ‘I will remember this time’, only to be proven wrong after a few months when I had focused on completely unrelated parts of the projects.

What am I actually doing?

After work, I enjoy spending time coding my own custom game engine for the game I want to develop. Recently, I have switched and ‘optimised’ my brain towards Data-Oriented Programming to deal with raw memory. In other words, the code is like an F1 car because it runs as fast as it can, but since there are no real brakes… one miscalculation and you hit the wall at full speed. Except it is not immediate; you will crash into a wall unexpectedly minutes or hours later.

Of course, for this reason, when you deal with this sort of code, you will generally have programmed run-time assert checks, run ASan (Address Sanitizer) for hard-to-find bugs, and used RelWithDebInfo to debug the code with compiler optimisations. You might also run the profiler, checking for CPU cache misses and avoiding optimising non-priority ‘cold’ paths not worth investing in—except my mind definitely would not sleep soundly at night, and I would definitely waste time doing it :). As a cherry on top, you will generally also have your compiler generate assembly files to check that the compiler has not decided to inline big functions into ‘hot’ paths, what is known as Instruction Cache Bloat. Though I have not personally experienced this sort of inlining yet, looking at the assembly is a good way to see if your code is branchless and gives you the ability to optimise a specific function that is used in your ‘hot’ paths by decreasing assembly instructions where realistically possible.

What next?

In the coming days, I will start writing posts about specific topics with the intention of helping my future self remember the “what” and the “why”.