Lucid Visions - Blog

2026-02-15

2026-02-15T13:40:00+00:00

This post is more like an entry in my journal that I've made public, a post about finding my way in the world of game development.</p>

2026-02-09 2

2026-02-09T12:47:22+00:00

Here is the curated commit log from this last week's development.</p>

2026-02-03
</span>feat: removed entity action timer; moves are now turn-blocking anims.
</span>
</span>2026-02-03
</span>feat: render entity index in graphical turn queue debug visualization
</span>
</span>2026-02-03
</span>feat: allow mult. entities in turn queue to move on same frame
</span>
</span>2026-02-03
</span>feat: introduce reaction to entity death after attack animations play
</span>
</span>2026-02-06
</span>feat: add component to support entity pos interp. during movement
</span>
</span>This also updates the camera to move with the player as position is
</span>interpolated, having the effect of a smooth-scrolling camera instead of
</span>a camera that moves in units of whole tiles.
</span></code></pre>



2026-02-09
2026-02-09T08:40:16+00:00
This morning I was thinking about the
Cassandra Complex</a> and
general mentality. Over the last few years, recent popular podcasts (which I'll
just not name) have repopularized the term. Often the speakers use the term as
cathartic relief, to express some kind of frustration they have over a thought
that they feel mocked, attacked, or persecuted for instead of rewarded for. For
a long time, I thought, "yeah, that sucks...," but I realized even this is an
acceptance of self-pity. Just reframe the situation, and you have a huge win on
your hands. You want to be right and early. That is where you make outsized
returns. So if you know things should be done differently, do so, even if it
imposes a cost--not an immediate reward--in the short term, because when the
long term pans out and the world catches up, you'll be many steps ahead and
ready to launch that book, deploy that technology, release that game, mentor
those people, etc. Even this is a grow-the-pie winning opportunity.</p>


2026-02-02
2026-02-02T15:12:52+00:00
I missed the update two week's ago, and last week's update is late, so this post
is a double feature! Recently I am spending a lot more time editing Twitch VODS
to create a YouTube dev log of sorts. This amounts to me listening to me build
my own game instead of spending time building the game, and these blog posts are
also me talking about working instead of "working," so I will probably start to
make these updates more concise.</p>
I will still post small videos of gameplay directly in some of these updates
which will serve as quick visual checkpoints in the journey, though. I will
also still write the occassional long post when I have a topic I want to discuss
in more detail.</p>


2026-01-19
2026-01-19T09:14:17+00:00
This last week I focused on implementing basic animations.</p>


2026-01-09
2026-01-09T14:48:17+00:00
This week I imlpemented an entity-component-system, a basic player attack,
entity deletion, and text and textbox rendering.</p>


2026-01-03
2026-01-03T13:12:43+00:00
This week I implemented A* and added support for multiple enemies to the game.</p>


2025-12-29
2025-12-29T15:14:06+00:00
Here is the commit log from last week's work.</p>
2025-12-23
</span>feat: introduce default allocator replacement for context
</span>
</span>2025-12-26
</span>feat: introduce "standard library" (sl) with ring buffer and test
</span>
</span>2025-12-26
</span>feat: add heap data structure and min-heap procedures to sl
</span>
</span>2025-12-27
</span>feat: separate min_heap out of heap impl; add max_heap; add tests
</span></code></pre>
The main focus this week was pathfinding, but I was also up to some other
peripheral things as well.</p>
Firstly, we have the introduction of a default allocator replacement for the Jai
context</code>. Jai passes around a special variable implicitly to each scope called
the context. I think I discussed this earlier, but in short, the context has
various useful properties on it such as the currently preferred logging function
and the preferred default and temporary allocators. In my case, I want to avoid
allocating using the default allocator. I also want to avoid allocating using
the temp allocator as much as possible, but I'm less concerned about this
because I clear its storage at the beginning of each frame. To catch usage of
the default allocator, I implemented my own allocator which just
assert(false, "[...]");</code>s on any operation requested of it. I caught a few
issues with this, mostly String.join</code> calls, that I fixed using</p>
String.join(...,, allocator=temp);
</span></code></pre>
Note the ,,</code> which is an operator in Jai which allows you to modify context</code>
properties at callsites for arbitrary functions. I would like to use my own
temporary allocators provided through the most basic of arenas, but for Jai
"standard library" things like this, it's easier to use Jai's temporary
allocator. I could always implement the allocator interface for my arena and
thus use my own backing memory pool, though. Probably a project for a later
time.</p>
Toward pathfinding, I have a simple grid map with uniform cost to move between
squares. I recalled the standard A* algorithm for pathfinding in such
situations. It's been over 10 years since I've dealt with A*, though, so I
needed a refresher. I came across
Red Blob Games</a>. This blog and the author's few
others linked from it are a wealth of information on algorithms for games,
particularly top-down, 2D ones such as mine. I highly recommend checking the
site out if you're interested in such.</p>
I thought I was going to use a queue, and a ring buffer would work well here,
so I implemented one. I followed a great tip from
Juho Snellman</a>
on using only positive indicies (no forced wrap-around via %</code>) and masking the
indicies only when you need to look into the backing storage. Clever and neat.</p>
Now, it turns out I actually wanted a priority queue, so for that I decided to
use a min heap. To my knowledge, Jai does not provide a min heap, so I
implemented one of those as well. To brush up on that, I referenced the classic
Introduction to Data Structures and Alrogithms</em> book. I had learned from this
in college as well. After re-reading a very small portion of this recently, I
admit I cannot recommend it. It does many things well, but I find it overreaches
with its advice in places and also (probably accidentally) misrepresents some
concepts by overfitting descriptions on very narrow use cases in specific
languages, for example by calling the heap a region of garbage-collected
storage. Anyway, it did the job.</p>
I ultimately implemented a heap (heap.jai) and then implemented the min-heap and
max-heap interfaces in respective files that both import heap.jai. I
reintroduced my "sl" concept from when I was playing with data structure
generation via the C preprocessor two or three weeks ago. I have a special file
in the sl module called test.jai which provides a main</code> function and imports
all of the files in sl and tests their features. I have a build.jai file in sl
that builds a binary from test.jai. Building and running the tests is a manual
process, but I don't anticipate changing sl so frequently that I'll hurt for
any automation, except that one time when I will probably change it, introduce
a bug, and forget to run the tests haha.</p>
I then got to implementing A*. The work is on a branch currently and will be
the subject of this week's update.</p>
I also started streaming livecoding (and some gaming) on Twitch, as noted in a
previous post</a>. The idea here is to maybe build even the
smallest of audiences or at least presence in parallel with building the game
instead of serializing the process. Presumably an audience takes just as long
if not longer to build than the game itself, but what do I know--I'm totally
new to this aspect!</p>


2025-12-23
2025-12-23T20:18:15+00:00
I decided to give streaming a go. You can check out the content
here</a>. I will try streaming both
development and games here and there. The motivation is building an audience
more organically in the event I do end up trying to market a game.</p>


2025-12-22
2025-12-22T12:42:08+00:00
Here is the gist of the commit log for last week's dev log, this post coming in
a bit late.</p>
2025-12-15
</span>feat: have aseprite exporter export to build/, not data/
</span>
</span>2025-12-15
</span>chore: bump SDL3 to 3.2.28, SDL_image to 3.2.4
</span>
</span>2025-12-15
</span>chore: move aseprite exporter into subfolder; add tools/jai-sdl3 submod
</span>
</span>2025-12-15
</span>feat: introduce main.jai; use SDL3 bindings to open window, cap fps
</span>
</span>2025-12-19
</span>feat: finish rewriting in Jai; add generated SDL3_image bindings
</span>
</span>2025-12-19
</span>feat: parse spawn layer from map asset; randomly spawn player/enemy
</span>
</span>2025-12-19
</span>feat: implement Map.assign_entity_locations, consolidate asset paths
</span></code></pre>
The big thing from this last week was revisiting Jai's bindings generator and
committing to Jai, not Odin. You can see on the 15th that I was again tempted by
Jai, brought in (my own fork of) the jai-sdl3</code> bindings generator wrapper for
SDL3, and proceeded to rewrite the game code so far in Jai.</p>
After resting two weekends ago, I realized that I didn't give the bindings
generator a fair shake. I mentioned it had some issues, or maybe that I was just
holding it wrong. I was just holding it wrong. I wrote a simple C library,
compiled it to dynamic and static libraries, and learned how to build bindings
for these. The knowledge gained here scaled up very quickly to allow me to
understand the bindings generator applied to SDL. I tweaked the implementation
(of just the Linux-targeted portion) of the wrapper to not require a system
installation of SDL. This way I can build bindings for my copies of SDL3 that I
build from source. I also added support for SDL3_image. This was much simpler
than the SDL3 support since SDL_image.h is a comparitively small file. The
generator accepts a visitor that can inspect each declaration as it is processed
and decide what to do--generate bindings with no customization, customize the
generation, or skip the declaration. Since SDL_image.h requires SDL.h, the
bindings generator will try to (re)produce bindings for SDL3. To avoid this,
we just have the visitor ignore declarations that don't start with IMG_</code>.
Additionally, we add a header (or footer) to the output to</p>
#import "sdl3";
</span></code></pre>
where sdl3</code> is the name of the module that provides the SDL3 bindings.</p>
The most time-consuming part of the port was rethinking the memory allocators.
In the end, I kept my own arena implementation and still pass those around, but
I also had to figure out what I was going to do with Jai's implicit context</code>
passed to each procedure, namely the context's allocators. There is a good
thread in the Jai beta discord about this. It reminds us that the main purpose
of the allocators in the context is to help control which memory is used by
modules that you didn't implement yourself. So it makes sense for me to keep
passing my own arenas around. I can also call any Jai procedure that uses
temporary storage at will since I clear Jai's temporary storage at the
beginning of each frame in my game. In fact, writing this just made me realize
I need to clear my temp arena at the beginning of each frame too, forgot to
do that...</p>
I haven't studied the implementation of Jai's temporary allocator, but from a
cursor glance I think it allocates its backing storage on-demand and grows the
storage as it needs to. This means that unlike my arenas, the memory is not
allocated entirely up front, and doing so was the entire purpose of introducing
arenas. That can be solved, though, and I believe Jai itself provides some
allocator implementations (Pool</code>?) that allow for up-front, fixed allocation.</p>
Another good idea from the Discord thread was creating a replacement for the
primary allocator assigned in the context that simply calls assert(false)</code> for
any operation requested of it. This way we can detect when we are allocating
from somewhere that we don't intend to, assuming code we call respects the
allocators set in the context. I have yet to implement this idea but will do so.</p>
About why Jai instead of Odin or some other language, I am just attracted to the
syntax and power yet simplicity, at least for the features I care most about.
The language feels familiar, not like something I've been writing in for a long
time (I really haven't been) but like something that works mostly how I expect
it to.
Like earlier Python, and like good-enough C, it fits in my head. As you can see
from the commit history, I did the entire Jai port in 2, maybe 3 commits. I
could have done it in many, adding this functionality and testing it and
committing, that functionality and testing it and committing, etc., but I just
plowed through it. Amazingly, after getting the program to compile, with the
exception of one case where I passed by value instead of by pointer, everything
just worked.</p>
With the port to Jai done, I'm getting back to adding features and experimenting
again. To close the week out, I added random entity spawning to the game. I
chose to place spawn points on my test map by creating another tilemap layer in
my Aseprite test map that marks tiles available for spawning. The spawn point
placement in my live game was off, and then I realized that each layer in
Aseprite is exported with a total size determined by a bounding box placed
around the layer's top-left-most tile and bottom-right-most tile. I briefly
investigated ways to force the layer to have the same dimensions as all other
layers but didn't turn anything up, at least not from the capabilities available
through the Lua API. So I resorted to having 3 tiles IDs in the spawn layer.
The first is the no-tile ID, which is just 0. This is the default in Aseprite,
so I'm more accommodating it than designing it. The second is the ID that
indicates a tile is available for spawning. The third are placeholder tiles I
use to make sure the spawn layer matches other layers' dimensions. The
placeholder tile is black (drawn at 50% opacity) in the image below. The yellow
tiles are spawn tiles, the red tiles are collision tiles (on a separate
collision layer), and the light green is moveable space. Beneath the red tiles
are darker green tiles which represent walls or bushes as visible in previous
demo videos.</p>
</p>
I use Jai's temporary allocator to build an array of spawn tile locations
when I parse the map data, and then I iterate through the entities to randomly
assign them a spawn location. I will probably re-hard-code spawn locations
soon to create reproducible environments for testing other features, but then
I will reenable random spawn in some fashion. The idea plays into the game
concept I have in mind.</p>


2025-12-14
2025-12-14T12:35:15+00:00
Here is the commit log from this last week of work.</p>
2025-12-08
</span>feat: add array and slice-generation macro and test for it
</span></code></pre>
What happened?! The time has come to switch off of "C++". Even my beloved
dialect of C++-that-is-actually-mostly-C leaves me with lots of work to do to
create a language I'm happy to use, before I can get back to the problem at
hand of developing a game.</p>
As I refreshed my memory on search algorithms and studied pathfinding algorithms
I was not familiar with, I realized I'd benefit from some more sophisticated
data structures. As you can see from the commit above, I started to implement
such data structures. I had three options. The first was to just use containers
from C++'s standard library. I really didn't want to go this route for reasons I
won't elaborate on here; suffice to say that I don't plan on depending more</em> on
C++ features in general. The second was implmenting my own code generator, like
spec'ing out code with variables that a (hand-written?) templating tool would
replace with values like type information, running this as a pre-build step, and
then including the generated code in compilation. Again, more work, essentially
somewhat re-implementing C++'s template features and also portions of what the
third option was: preprocessor macros.</p>
I opted for the third approach since, in theory, it is
write-once-test-a-bunch-use-without-too-much-care-afterward. The natural place
for this work was in the small standard library I was growing. I did prove out
that I could generate a satisfying array type and a corresponding slice type.
But honestly the thought of repeating that for a queue, a priority queue, a
dynamic array, a hash map, etc. dissuaded me from continuing. Not only would I
need to take a lot of care to avoid bugs and write a bunch of tests, I'd also
need to get into the weeds about which implementation of which data structure
was most optimal (or at least good enough), etc. And I just can't be bothered
right now.</p>
Coincidentally, I came across a podcast interviewing Jon Blow
(this one</a>? I don't quite remember
unfortuantely), asking about why
he was creating Jai and what hope he thought he had of creating a relevant C++
competitor or even replacement. I have been spending a lot of time thinking
about whether to go all-in on Jai, weighing the tradeoffs of an actually-sane
language but one developed and maintained by only a very small number of people
(albeit with a big flagship project</a>
proving that the language is ready for production projects) and an
industry-standard language backed by tools with massive user bases and a much
larger number of contributors. Jon's answer was very convincing. In short, he
said that we as a species have not used the same programming language forever.
Even Big Industry switches languages over time. So if we accept that we are not
going to use some particular language forever, then we don't have worry about
asking ourselves whether we can compete with things like C++. Instead, we have
to ask ourselves, when we do have a new language that we gravitate toward, which
one will it be? Jai is Jon's language in this regard.</p>
The last time I used Jai seriously was one year ago, last winter. Back then I
wrote essentially what I have now in "C++" and SDL (load tilemaps and sprites,
paint a level and a character, move the character around in a 2D world) but in
Jai and its built-in windowing abstraction called "Simp." So I spent a couple
days brushing up on the language and learning about what had changed since when
I last used it. After refreshing, I gave a Big Think over whether or not to use
Simp again for my project. I decided against it and chose to stay with SDL. So
I started exploring Jai's bindings generator tool that is often used to generate
Jai bindings to useful C and C++ utilities people want in their Jai projects.
At the time of this writing, there is an
open-source</a> repo that uses the
bindings generator to create SDL3 bindings for Windows, macOS, and Linux. I
forked it and modified it a little to support my own workflow. Instead of the
current open-source behavior which wants a system-installed SDL3 library at
least for the Linux use case, I compile SDL3 from scratch for my project and so
want to point the bindings generator at that library at generation time. I got
it working in the end but suspect I was holding the tool wrong because there
was some non-obvious behavior such as transforming things like
../../build/libSDL3.so</code> to __/__/build/libSDL3.so</code> which broke library
loading at runtime untils I made some manual tweaks to the generator and also
stuffed a library in my source code instead of just in the build/</code> folder. So
despite it working, I wondered if there was an easier way overall.</p>
Again coincidentally I came across some videos on YouTube about using Odin for
game development. I've known of Odin for years but have never gotten into it.
Odin does provide SDL3 bindings out of the box. Although not shown in the commit
log at the beginning of this post, I've started down the Odin path, first to see
if I enjoy the language enough to keep using it and second to see if it's any
easier (by my taste) to achieve what I'm trying to do with Odin than it has been
with Jai.</p>
Currently I am opening a window via SDL3, painting the window the same gray
background color I was using in my previous C-like implementation, and reacting
to window-close events. The magic to work with my compiled SDL libraries is
simply:</p>


build SDL3 and emit libraries in ./build</code></p>
</li>

build my Odin project as follows</p>
 odin build src/ \
</span>   -extra-linker-flags:"-L./build" \
</span>   -out:"./build/game" \
</span>   -show-timings
</span></code></pre>
</li>
</ol>
Now, I am working on porting all my other code from "C++" to Odin. It's
annoying, but it's best to pay this language-and-tooling cost up front in the
project and have a consistent set of tools I enjoy using for the life of the
project, which will likely be years.</p>
So far, I think Jai is simpler than Odin, both in syntax and in its concepts.
There are very many similarities in the language behavior and syntax. I cannot
tell who inspired whom, presumably Jon-->Bill? Regardless, Odin hasn't been
hard to pick up. The thing I spend the most time on is figuring out which types
I should replace C-style buffers and arrays with in Odin. I'm only a couple days
in, so maybe this is obvious and simple, but I'm just not there yet, have been
playing more with SDL3 and doing a lot of reading about Odin to get a sense for
its capabilities and staying power.</p>
I did find one thing amusing, that there will be an upcoming change, part of
which is explicitly passing an allocator into some functions
(ref</a>). I am already
doing this everywhere in C, so no big deal. Jai passes a context to every Jai
call that provides things such as an allocator so that callers can easily swap
out the allocator used by third-party code, unless the library author explicitly
chooses to ignore the requested allocator. I think Odin has something similar.</p>
Next week I hope to have at least my previous game implementation but this time
in Odin, if I don't decide to switch off of it.</p>


2025-12-07
2025-12-07T12:53:37+00:00
Now that I'm doing my own thing, I've got more time on my hands to explore
interesting posts, videos, books, etc. I've also resolved to put more of my
thoughts here in this blog instead of on a variety of disparate networks.</p>
A few days ago I came across a fellow by the name of Sylvan Franklin. I
identify a lot with what his recent journey appears to be, but that story is
for another time.</p>
This post is prompted by
The Addiction that hides in plain slight</a>.
In this post, I'll casually mix the target I am writing to.</p>
One point Sylvan brings up is that many of us may have an addiction to
information. I certainly do. I noticed this a few months ago, when I realized
I would hesitate to start house chores or cooking until I found something
interesting to listen to on my Bluetooth headphones.</p>
One day, on a podcast I don't remember, I heard someone ask the rhetorical
question, "how much information is enough?" The context implied the full
question was, "how much information is enough to equip you to do what you think
you need to do?"</p>
I opened that question up more and realized the next implication, that I didn't
actually have an agenda with any of that information. I didn't want to do
anything with what I was "learning." In fact I told myself I was learning, but
in reality I just wanted to be entertained. Learning is evidenced by a change in
behavior, but I wasn't changing much. The gotcha was that every now and then I
would</em> consume something that resonated deeply with me--made me feel
understood--or did change the way I thought and lived. What I became addicted to
was the next revelation. But there is no promise of when or where this will
come, much like there is no promise of when you may see something actually
transformative while doomscrolling, be it a social media feed or a collection of
proverbs.</p>
In the end, I was just saturating my brain, hardly giving anything enough time
and thought to personalize it.</p>
You can tell when you've personalized something when you can communicate it to
others without referencing anyone or anything else, that is, by appealing to
personal experience and not authority, without saying, "the Senior Architect
said...," or, "The Meditations say..." Now, let us not plaigarize, and if you
want to cite the source, that's fine, but you haven't personalized something if
you appeal</em> to the source. One of the things I appreciate in Sylvan's recent
videos I've seen is his self-awareness about his journey being personal.</p>

"what I have to do is, do the hard work of coding everyday, or working on the
math everyday, or reading philosophers everyday and thinking about them"</p>
</blockquote>
You already know the path forward! But perhaps you are not convinced yet. I'll
elaborate below, but in the end, only you can convince yourself.</p>

"What got you out of information consumption? I'm looking for the One Trick
(tm)."</p>
</blockquote>
If you only look externally, you will be searching unsatisfied forever. As you
say, it's like climbing a mountain. Looking externally has its benefits, but
ultimately you will see others' techniques that worked for them. The catch is
that the mountain you climb is your mountain. You can see their mountains from
your mountain, or sometimes at least imagine their mountains. Your terrain might
look like their terrain at times, but ultimately it is not their terrain.</p>
The trick is to know who you are and where you are going. Knowing this in itself
is a journey, and unless you concern yourself with cosmology, is perhaps the</em>
journey.</p>
Who you are means understanding yourself--your nature, your past, your desires,
etc. Consuming information externally is useful for bootstrapping your
search. For example, Zen--as you've also discovered--and the "noting" meditation
technique worked well for me, and understanding this and that about behavioral
psychology was also useful. The trigger to look inward was looking outward for
answers to questions about myself until I realized I am the only one who knows
me. That, and after having asked {God|the Universe|whatever}, "what is my
purpose," for so long, only to realize I am actually being asked</em> that question
and the asker is just waiting for my response. Coming to know who you are is
often a long journey, perhaps never-ending, depending on your definition of
finished. However, answers to who I am have brought me peace from mind, the
mind being all I was trying to appease by some new toy theory to juggle,
programming language to learn, or other distraction to concentrate on.</p>
Where you are going, as a question, is, "what is your current goal?" If you have
this agitation that your goals are distractions or are perhaps meaningless, also
ask yourself, "why," regarding what your current goal is. Iterate on that until
you've found something meaningful and satisfying to you and then go with it.
Where you are going will naturally change over time, sometimes multiple times a
year, sometimes once every 5 or 10 years, unless you are the rare
type who pursues a lifelong mission that outlives you. But even then, you will
likely have milestones along the way.</p>
When we know who we are and where we are going, we can return to the deluge of
information, but this time with a natural filter. We're here with a direction
and a purpose. We take what is useful, we're thankful for all else but are not
distracted by it or {time|compute}-enslaved to it. It's worth noting, it's
useful to allow ourselves time to play and wander periodically (the search
part of search-exploit, if you will). It's not about always filtering but rather
about having the filter and the awareness to apply it as necessary.</p>
The fact that you are already looking means that it is only a matter of time,
so travel with a peaceful mind, fellow sailor!</p>
Given what I understand about you so far, if you have not already read
The Beginning of Infinity</em> (David Deutsch), please do so if you're looking
for any bootstrapping.</p>
Aside:</p>

"You program long enough and the patterns emerge, and you start to see things."</p>
</blockquote>
I hadn't heard of the Gang of 4</a>
book until years into my software engineering career. When I read it, everything
in the book I actually cared about was already familiar. I had developed it
myself via the Feynman Algorithm</a>. And
I don't say this boastfully--I'm no genius. I just had problems and thought hard
about how to solve them well until I solved them. One amusing thing I noticed,
was that because I had derived the designs myself in-context, it stood out to me
immediately when a peer appealed to the Gang of 4 in a, "well, I don't know,
but these guys say..." way. Which is not The Way (tm).</p>
Godspeed.</p>


2025-12-06
2025-12-06T09:28:16+00:00
Here's the curated commit log for last week.</p>
2025-12-03
</span>fix: allow player to change facing direction even if they can't move
</span>
</span>2025-12-03
</span>refactor: wrap platform-side details (renderer, screen dims) in struct
</span>
</span>2025-12-03
</span>feat: use renderer logical presentation to support arbitrary upscaling
</span>
</span>This also removes explicit transformation from world tiles to world
</span>pixels as world pixels were only ever used as an intermediate frame when
</span>transforming to screen pixels.
</span>
</span>2025-12-04
</span>docs: add concept groundwork for first game; separate next game content
</span>
</span>2025-12-04
</span>feat: add first enemy, random movement; add entity-entity collision
</span>
</span>2025-12-05
</span>fix: round lowest visible tile idx toward 0 to fix gap in map_render
</span></code></pre>
I split my time three ways this week, one by necessity and another mostly by
chance. As this post is about solo game dev, I will share details peripheral
to development from time to time as they are part of the journey. In this case,
the by-necessity thing was applying for health insurance as it is mandatory to
have if living in Japan. I'll split that into another short post, though.</p>
The second thing was game design. While I will go into detail about the
mechanics and perhaps level design, I will probably never go into much detail
about the story itself, as I'd like to leave that up to players to experience
and interpret. I guess I can elaborate a bit on my trajectory until recently,
though. I plan on this being my first game I'll publish and sell. I'd love for
it to be "successful," but I don't bank on that at all, pun intended. What I
want to do is get experience going end-to-end, from an empty file in a text
editor to a game in the market. That will be quite a journey, but that will be
the first iteration. From there I'll learn whatever I can and repeat. Toward
that, I don't want to develop slop, will try to come up with something creative
and worthwhile for me and others.</p>
At first I had an idea to clone an existing, small game I enjoyed and add some
extensions. This gave me well-scoped goals and removed a big task, which was
novel game design. This was all toward getting some iteration out in public
quickly. Lots of the big indie game hits took 5+ years to develop. I'd like to
get something out in 1 or 2 years, again, without the aspiration that my title
would mean anything to anyone but me. To date, I've been developing my own game
for something to the tune of 7 weeks or so, and already, my own game design
ideas are popping up in my mind. I did rack my brain for the first two weeks for
some interesting, novel idea I could build a game around, but nothing really
surfaced. I recalled a talk I watched from Jon Blow, I think it was his
keynote</a> at GDC 2014, where he was
discussing where to find inspiration for interesting games. I've also learned
from my beloved Kojima Hideo-san and also
Sakurai Masahiro-san</a>. The thing I
always walked away with, though, is that I'm not going to sit and try</em> to come
up with an idea that makes for an interesting story or game. And indeed, this
has proven true in my life. Perhaps ironically, it is by not trying</em> that I
have had my most promising ideas for games. This time around has been no
different. As I develop and think about which feature to try and implement next,
ideas seem to naturally bubble up into my mind. "Ah, what if instead of the
game working in this way, it works in that way?" And "that" way turns out to
have some parallel with a transformative experience I had in life, and suddenly
a game feature becomes a metaphor for a realization I had or a way of thinking
that changed my life. And then a game feature and a story element naturally
weave themselves together. I'm being vague here still so as to not spoil
anything about the story I'm thinking of writing, but I think I've described
the gist.</p>
Paraphrasing the Tao Te Ching, by not doing, it is done.</p>
I also read and listened to talks about creating game design documents. Creating
one before doing any other work probably works well for the niche of people that
are borderline clairvoyants, but they don't work like that for me. In fact, they
smell like the stereotypical project manager who tries to outline a product on
paper and get it right the first time. Of course, the game design document is a
living document in either case, so it does evolve over time,
typically to be come less prescriptive and more descriptive. For me, the way it
works is that I develop something, seem to naturally get interesting ideas over
time related to my life experiences, and then I just jot the ideas down in a
Markdown file checked in at the root of my game's repo. It's less a design
document and more a journal of the concepts at play in the game and ideas I've
had that I want to explore further. Once I have such ideas, these are seeds from
which I can</em> sit and intentionally think more deeply about and further develop.
Going from 0 to 1 idea-wise, I have no process for. I often just need to let my
mind wander (/wonder). Once I have 1, I can play with that intentionally and
grow it in this and that way.</p>
One guiding principle of my game design is that I want to respect the player's
time. What I mean by this is try to share an interesting mechanic, idea, or
thought with the player in 3-5 hours. The game would need to be priced
accordingly, but otherwise, I don't like the thought of me creating something
that, if a hit, consumes 80+ hours of tens of thousands if not millions of
people's time just distracting them from something else in life.</p>
Finally, the third thing was typical feature development. The most interesting
topics this week are rendering logical presentation and adding the first test
enemy.</p>
Regarding logical presentation, after creating a 16x16 px sprite and then
rendering it in my game, I thought the sprite was a bit too small on my monitor.
I had two choices. The first was redraw the sprite, and eventually every asset,
at a larger resolution. The second was to upscale the sprite. The first would
cause the art to take more time, and the second seemed more practical, so I
tried to do the second. When I did that, I got some strange effects. There
seemed to be some sort of visual tearing between tiles. What was in fact
happening was that SDL was applying blending upon upscaling. This is controlled
per-texture using
SDL_SetTextureScaleMode</code></a>.
SDL3 conveniently provides SDL_SCALEMODE_PIXELART</code> as a scale mode, perfect
for my use cases.</p>
Here is what rendering looked like before applying.</p>
</p>
Here is what it looked like after.</p>
</p>
You can see the "tearing" issue is fixed. The pixelart version is much sharper,
although there is a nice CRT-like aesthetic to the previous scale mode, which I
think was just nearest-neighbor. I'm going to keep the pixelart scale mode for
a variety of reasons. I won't get into that more this time, though.</p>
You may also have noticed that the image of the game seems zoomed in compared
to images or videos in previous posts.
At first, I was scaling the rendering by adding an explicit scale factor (2x)
and then propagating that scale factor to all code that dealt with
transforming to or working in screen pixel space. One question that naturally
comes up is, how do I render to a screen space that has an aspect ratio
different than my world map? If I create a scale factor based on the latest
window dimensions, I will need a horizontal and vertical scale factor. Or, I
could create a uniform scale factor, but what do I do when my scaling doesn't
fill the entire screen in some dimension? I'd generally accommodate this
manually. One would typically fill the gap with
letterboxes</a>. (Grokipedia
isn't so great at the time of this writing in that it doesn't show images, and
an image would explain this concept immediately. Anyway, here's to hoping the
article is better in the future.)</p>
I found that SDL has a function to handle this for me, called
SDL_SetRenderLogicalPresentation</code></a>.
So I employed that function. The gist is that you have some actual screen
dimensions that the rendered image is displayed in, but you can configure a
logical render space that you will target your code/math to. SDL will handle
scaling your logical render space to the physical render space at presentation
time. So, you don't have to worry about handling letterboxing or uniform
scaling anymore. To boot, you also don't have to propagate manual scaling
factors throughout your code. Instead, I just propagate the logical render
dimensions. When I want to scale up, I configure the logical render dimensions
to be smaller than the physical render dimensions.</p>
The second notable feature was adding my first test enemy. I hacked the enemy
directly into the game state object for now, but I realized I'll have to do
some thinking on how to efficiently manage multiple enemies (generalized to
entities) for some level or game state. Problems include: reusing an entity
asset across multiple entities instead of each entity owning its own
(potentially duplicate) asset, creating a statically-sized collection for
entities and marking some as existent/non-existent or having the collection
by dynamically-sized (so non-existence is handled via delete</code> or remove</code>
or something like that on the collection), and how to store information about
how many entities and their kinds to spawn and where for each level.</p>
Then I also need to implement pathfinding for enemies.</p>
Currently I have a simple ghost-like sprite spawned at a hard-coded location
that maybe moves in some random direction when the player moves. As the game
is tile-based, collision detection is simply</p>

check for collision on the map</li>
check for collision with other entity</li>
</ol>

  
  Video not supported.
</video>


2025-11-28
2025-11-28T15:30:46+00:00
Here is the curated commit log and post for this week's game development.</p>
2025-11-24
</span>chore: move standard-library-like code to src/sl ("standard library")
</span>
</span>2025-11-24
</span>feat: path_concat now maybe adds separators; add test and README
</span>
</span>2025-11-24
</span>feat: add string view path_concat overload; extend test
</span>
</span>2025-11-25
</span>feat: add arena allocator to standard library
</span>
</span>2025-11-25
</span>feat: map loading and path_concat now use an arena
</span>
</span>2025-11-25
</span>feat: add arena_realloc and test in preparation for using stb_image
</span>
</span>2025-11-25
</span>feat: introduce stb_image as library; use our own allocators; load PNGs
</span>
</span>2025-11-26
</span>feat: replace STBI with SDL_image; load map tilesets as texture atlases
</span>
</span>2025-11-26
</span>feat: render actual game map instead of placeholder game map
</span>
</span>2025-11-27
</span>feat: move game logic out of main; introduce persist, temp, map arenas
</span>
</span>2025-11-28
</span>feat: generalize aseprite_to_map tool to aseprite_asset_exporter
</span>
</span>2025-11-28
</span>refactor: extract map into general tileset asset
</span>
</span>2025-11-28
</span>feat: load player sprite, add player-facing direction
</span></code></pre>
Last week's commit log query started from the beginning of time in my repo, so
I've added a new filter to the git log query, --since</code>. Again, mostly just
pasting this here for my reference.</p>
git log --pretty=format:"%ad%n%B" --date=short --since "2025-11-24" --reverse
</span></code></pre>
As the first commit suggests, I've extracted some features from my game into a
separate library I'm calling sl</code>, just meaning "standard library." It's
essentially a variety of game-independent utilities that I would typically find
in a languages' standard library but flavored to my taste.</p>
path_concat</code>, which I posted about in last week's post, will now add path
separators when required. This change is ultimately what led me to introduce
arena allocators which I did shortly after. Without arena allocators, the caller
has to set up enough buffer space for the string concatenation, and the
requirements to set up the buffer correctly grew as the function became more
featureful. Some months ago, in my last group of posts about the game I am
making, I discussed arenas, so I won't be going into them here.</p>
At the beginning of the week, I was rendering a placeholder map and character.
I already had Aseprite map loading working in my game last week, but I was not
rendering the map. This week I tossed out the placeholder map and am now
rendering "real" maps. This made testing a lot more fun. It also reminded me
that I need to get a lot better at pixel art :) Anyway, the idea was just to
get something rendered to test the end-to-end art-to-play path.</p>
I previously implemented collision by just checking the tile ID of the tile
the player wanted to move onto. Now, as I probably posted about months ago
as well, I export at least 2 layers from a single map in Aseprite. The first
is the layer containing the graphics for the map, essentially the painted
tiles. The second is the collision layer. I use a single tile, typically red,
in the collision layer to indicate which spaces have collision. Collision in
this case means things like walls. For interactable things in the map, this
will likely be a third layer (or maybe an extension of the collision layer)
which indicates the spawn locations of various entities. I'll then create
the entities at runtime and they will particpate in the dynamic game update
loop, not just be static in the map. This is how you can have opening doors,
switches, things like that.</p>
Actually, about arenas, one new thing I did with mine is implement the realloc</code>
behavior described in
malloc(3)</code></a>. This was
because I was preparing to use STB image to load tileset PNGs from Aseprite, and
I didn't want to implement a PNG parser myself. STB image kindly provides
STBI_REALLOC_SIZED</code></a>
which is like realloc</code> but passes the size of the existing allocation for use
in allocators that don't track individual allocation size. This is often the
case for arena allocators, and mine is no different. As you can see in the
commit log, I forgot and then later remembered that SDL provides SDL Image to
do the same thing. Since I'm already using SDL, I STB image and use SDL Image
instead.</p>
I also moved all of the game logic out of main.cc</code> into its own game.{h|cc}</code>
file. This is to help separate the OS-specific platform portion of the
implementation from the OS-agnostic game logic. I will have to add OS awareness
to things like my standard library, but that will come later. As part of moving
the game logic out of main.cc</code>, I also created a few arenas on the platform
side, bundled them up into a simple Memory</code> struct, and hand them off to
game_update</code> which is the entrypoint for my game logic for a single frame.</p>
Lastly, I also replaced rendering of the placeholder character with rendering
of one I drew in Aseprite. I drew 4 sprites for the player: up, down, left,
and right. I could have just exported a sprite sheet (as PNG) and loaded that
into an SDL_Texture</code>, but since I already have an Aseprite-to-binary workflow
with the aforementioned conversion tool, I create the player as a tilemap,
export that, and then re-use my binary-parsing logic to get at the tileset for
the player. Thankfully this doesn't waste any memory ultimately. I allocate
the tilemap in the temp arena and just copy out what I need into the persistent
arena. The temp arena gets cleared at the end of the current frame on the
platform side.</p>
There is a bit of a catch, though. Here is a cobbled-together group of struct
definitions from across various game files.</p>
struct </span>Tileset {
</span>  SDL_Texture</span>*</span> atlas;
</span>  size_t atlas_width_tiles;
</span>  size_t atlas_height_tiles;
</span>  uint16_t tile_width_px;
</span>  uint16_t tile_height_px;
</span>};
</span>
</span>struct </span>Entity {
</span>  EntityType type;
</span>  Vector2f pos;
</span>  Tileset ts;
</span>};
</span>
</span>struct </span>Player {
</span>  Entity e;
</span>  FacingDirection facing;
</span>  Cooldown move_cooldown;
</span>};
</span>
</span>struct </span>GameState {
</span>  uint64_t perf_frequency;
</span>  </span>const char*</span> base_path;
</span>
</span>  Player player;
</span>  Camera camera;
</span>
</span>  Map map;
</span>};
</span></code></pre>
Starting from the bottom of the definitions, GameState</code> is what lives in my
persistent arena. Persistent means the memory survives across frames.</p>
A Player</code> is an Entity</code> by composition, and an Entity</code> contains a Tileset</code>
which in turn contains an SDL_Texture</code>. I have not replaced SDL's allocators
with my own allocators, and I'm not sure if I will. This means that I let SDL
use whatever its backing allocators are (not necessarily malloc</code>), but I don't
control the memory pool itself. So, things are a little bit fragmented across
memory--I control many allocations in my game logic, but SDL just does whatever
it wants.</p>
The reason I have not replaced SDL's allocators is because SDL uses free</code> quite
a lot. I think I might have posted about this before... Anyway, I don't want to
write an optimized allocator at this time in my life. When I implemented "free"
for STB image, it was just ((void)0)</code>, meaning that I didn't actually do
anything, because my arena can't free individual allocations.</p>
We'll see if this hurts me down the road.</p>
Anyway, last point for today, about the Tileset</code>. The name of the texture is
atlas</code>. An atlas is just a single texture that may contain multiple tiles.
You get at the tile you want by specifying a subset of the atlas as a
source rectangle</a>
when rendering. Player::FacingDirection</code> in my case doubles as an index into
the atlas, so when I render a player, I render one of the aforementioned
directional sprites by indexing into the atlas.</p>
In my last implementation, I was loading a unique texture for every sprite.
That may be less efficient at render time if the allocations for the sprites
live far away from each other in memory. That, and it's just more things to
keep track of. Map</code> also uses Tileset</code>, so atlases benefit us there, too,
where there are many more sprites than there typically are for entities like
players.</p>
Here's a demo. Pardon the programmer art.</p>

  
  Video not supported.
</video>


2025-11-27
2025-11-27T09:28:13+00:00
The year is 750 AD. It's central Japan, the
Nara Period</a>, the tail end of
winter. The cold is biting.</p>
It's early in the morning. The sun has just started to peak over the mountains
and through the trees. You're outside, wrapped in multiple layers, shivering.
But you don't think about the cold. There are tens of other people around you
doing the same. Everyone is facing a single person standing before everyone
else. Let's call him the foreman. The foreman is giving out the instructions
for the day. People will split into teams and go here and there. Everyone's
general task is to cut down trees and prepare planks from them for carpenters
to further refine.</p>
You pick up your tools, hands hardened from all the work you've done up until
now. You move with your team to your designated area. You self-organize into
smaller units, some working in tandem to cut trees, others cutting fallen trees
into logs, stripping bark and branches off of them. You get stuck in the group
that has to chop the trees down. You and your partners gather around various
trees with axes, each chopping away. You had an idea to create a long sawblade
that two people could hold, one on each end, and you could fell trees faster
with less work individually. It'll have to wait, though, as you can't create
that on the spot. You wished you were in the team stripping logs or hauling them
back to camp. Chopping down trees is hard work, and your team is the bottleneck.
The others are resting while waiting for another tree to log and haul.</p>
As you work, your body heats up, and you start to sweat. You remove a layer.
It's uncomfortable, and you can smell the odor of your teammates as well. But
these trees aren't going to fell themselves, and you can't let everyone else
down. You try not to think about tomorrow, but you know you'll be back to do
the same thing all over again. At least you'll get to rotate to a different
responsibility.</p>
6 months pass. You haven't always been felling trees for this time, but you've
been doing similar manual labor otherwise. You think about the nobles who have
come through town while you work. Ah, to be like them and not have to work so
hard. Whatever, どうでも良い.</p>
It's the middle of summer now, and its sweltering hot. You sit on cool stone in
the middle of the day, unlike your days prior toiling away when it was colder.
You're shaded from the midday sun by a large wooden overhang that is just one
part of a large castle-temple complex. Last year this overhang wasn't here, and
everyone felt its lack literally. You remember getting caught in the summer rain
brought by the typhoons. It wasn't even refreshing. The air was so humid, and
the rain was somehow warm. You were hot and miserable, and everyone smelled.</p>
But this year is different. You sit under a tangible structure protecting you
from the elements. Many others do the same. You weren't the carpenter, you
weren't the architect, you aren't a noble, but everyone knows that you pitched
in and is thankful for that. It starts to rain. You and your buddies look out
into the damp heat and then look at each other, smile, and give a sigh of
relief.</p>
Summer transitions into fall. It's cooler now, and you're back to work, moving
large stones from a quarry to a mason's workshop. The mason does his thing, and
then you move shaped stones elsewhere around the castle-temple complex. It's
monotonous drudgery. You wish you could be out helping your parents plant or
pick rice like you did when you were 8 years old, daydreaming about goofing off
with your friends later on or listening to some bizarre stories and wondering
about the world. Whatever, どうでも良い. These stones aren't going to move
themselves.</p>
The next winter comes, and the cold is once again biting. The town doesn't need
as much wood this time around, so you've moved on to other tasks, doing grunt
work on farms, for smiths, for masons. This year the cold is more pronounced,
though, since you have something to compare it to. You and your buddies look
out into the snow falling around you, recalling simultaneously freezing and
sweating this time last year. You're a little too hot, so you lift yourself
out of the onsen</a>, and steam billows from
your body like you're some sort of deity. You feel like one, at least, knowing
that the blood and sweat you put into all that work with wood and stone has
provided for everyone around you, and everyone else knows it too. You built
something that has measurably improved your own life and the lives of people
around you, and you presumably get to enjoy it for the rest of your days.</p>
The year is 2025 AD. It's Tokyo, the
Reiwa Period</a>, the tail end of winter.
The cold is biting.</p>
It's early in the morning. The sun has just started to peak over the mountains
and through the trees. You're outside, wrapped in multiple layers, shivering.
You think about the cold. There are tens of other people around you doing the
same. Everyone is facing a single person standing before everyone else. Let's
call it the crossing signal. The signal is giving out the instructions for when
to walk. At work, people are split into teams. Everyone's general task is to
move information from one service the company pays for to another service the
company pays for.</p>
You unlock your computer, heart hardened from all the work you've done up until
now. You check-in with your team on your designated Slack channel. You
self-organize into smaller units, some working in tandem to address this
problem, others essentially creating new problems. You get stuck in the group
that has to fix problems. You and your partners gather around various documents,
each cross-checking, debugging. You had an idea to create an automated test
barrage, so you could catch issues earlier, faster, with less work individually.
It'll have to wait, though, as you can't create that on the spot. Thankfully
they run the heater late into the night, so you can stay late and develop it on
your own time. You wished you were in the team creating new problems for
everyone else. At least they get to create puzzles for themselves and then code
up solutions. Fixing problems is hard work, and your team is the bottleneck.
Management is waiting for another fix to send to the customer.</p>
As you work, your body heats up, and you start to sweat. You remove a layer.
It's uncomfortable, and you can smell the odor of your teammates as well. But
these tasks aren't going to finish themselves, and you can't let everyone else
down. You try not to think about tomorrow, but you know you'll be back to do
the same thing all over again. At least next quarter you'll get to rotate to
a different responsibility.</p>
6 months pass. You haven't always been fixing problems for this time, but you've
been doing similar labor otherwise. You think about the managers who have
come through the org while you work. Ah, to be like them and not have to work so
hard. Whatever, しようがない.</p>
It's the middle of summer now, and its sweltering hot. You sit in a
climate-controlled office in the middle of the day, just like your days prior
toiling away when it was colder. You're shaded from the midday sun by a large,
sterile ceiling that's just one part of your company's massive office. Last year
this ceiling was there, and you didn't even think about it. You were caught
in the summer rain brought by the typhoons on your way in. It wasn't even
refreshing. The air was so humid, and the rain was somehow warm. You were hot
and miserable, and everyone smelled.</p>
This year is no different. You sit under a tangible structure protecting you
from the elements. Many others do the same. You weren't the carpenter, you
weren't the architect, you aren't a manager, and you didn't pitch in. No one
even takes a moment to be thankful for the structure. It starts to rain. You
and your buddies don't even look out into the damp heat, are fixated on meeting
deadlines for people they don't care about, building something they'll never
use, for people that will never know them, if the product isn't scrapped on the
whim of someone entirely disconnected from the work.</p>
Summer transitions into fall. It's cooler now, and you're on a different
project. The teams around you do their thing, and then you integrate it. It's
monotonous drudgery. You wish you could be out helping your parents garden like
you did when you were 8 years old, daydreaming about goofing off with your
friends later on or playing some fantasy RPG and wondering about that world.
Whatever, どうでも良い. These tasks aren't going to complete themselves.</p>
The next winter comes, and the cold is once again biting. Your org didn't need
as many people this time around, so you've moved on to other tasks, doing grunt
work for the next project. This year the cold is no more pronounced. You look
out the window into the snow falling, recalling nothing. You're a little too hot
so you take your jacket off. Steam billows from your coffee like some sort of
demon. It feels like one, at least, knowing that you depend on it to keep you
going, pouring sweat and life into all that thankless work you have to do.
Everyone knows it, so you tell yourself its okay, but they don't care, because
that's just life, isn't it? You built something that has measurably improved
nothing, and you don't even get to enjoy it, because you never really needed it
anyway. And you never will for the rest of your days.</p>


2025-11-24
2025-11-24T09:48:00+00:00
I had joined a startup a few months back, but I recently left. Back to my own
thing at this time in my life.</p>
When I first left industry to do my own thing, so many people asked me what was
next for me and were surprised by "doing my own thing" that I had to refine my
answer to make the inevitable same-conversation-many-times efficient. The common
question to me was, "what would it take for me to work for someone else again?"</p>
My answer was, simply needing money aside, three criteria.</p>

The company is a small group of experts.</li>
The group has a single, measurable mission.</li>
The mission and tasks resonate with me.</li>
</ol>
I've since added a fourth criteria: everyone is humble.</p>
Also, I've created a new rule for myself for any interview I participate in from
here on out. That rule is, if I want to join a company, I need to first come up
with my own plan and explanation of how I would accomplish their mission,
end-to-end, meaning from hiring people and starting with an empty text file in
front of me as a software engineer, to shipping and maintenance. It's most
important to run this by company leaders to get a sense for their familiarity
and experience in the domain and also to get an early read on points I might
disagree with or things I might be wrong about and expectations I need to
adjust.</p>
With that out of the way, here is my next development update. I was previously
writing development logs mostly daily, but now I think I will do so weekly,
unless there is some singular topic I want to on about at length. It's Monday
already, but I'll be posting about last week. Also, it's a three-day weekend
here in Japan, but when you work for yourself and have no income yet, there is
no such thing.</p>
I'll experiment with posting a slim log and then touching on this and that. The
command I'm using to print the log is</p>
git log --pretty=format:"%ad%n%B" --date=short --reverse
</span></code></pre>
2025-11-15
</span>docs: initial commit
</span>
</span>2025-11-15
</span>feat: open a window, attempt FPS target
</span>
</span>2025-11-17
</span>feat: render a simple map the size of the window; add build docs
</span>
</span>2025-11-17
</span>feat: introduce create/destroy entity function; create player
</span>
</span>2025-11-17
</span>feat: implement basic movement and collision
</span>
</span>2025-11-18
</span>tweak: double running speed in tiles per second
</span>
</span>2025-11-18
</span>feat: introduce GameMap struct
</span>
</span>2025-11-19
</span>feat: add camera that follows player; also add clip rect on main window
</span>
</span>This fixes a rendering slowdown caused by extending the map size in an
</span>earlier commit and rendering the entire map--even portions out of the
</span>frustum--on each frame.
</span>
</span>2025-11-19
</span>docs: index documentation and add docs on coordinate systems in use
</span>
</span>2025-11-20
</span>chore: switch tile size to 16 pixels to anticipate maps; extend docs
</span>
</span>2025-11-21
</span>feat: add small paths and strings library
</span>
</span>2025-11-21
</span>feat: add aseprite to binary map conversion wrapper tool
</span>
</span>2025-11-21
</span>feat: add a map parser; this commit does not include assets/, data/
</span>
</span>2025-11-21
</span>feat: add string view and parent path utilities
</span></code></pre>
I restarted the codebase. I did this mostly to refamiliarize myself with what
will become the entire implementation. I'm still using SDL3 and, by consequence,
CMake. I considered switching to Jai or Odin but stuck with my favorite dialect
of "C++," which is C with operator and function overloading. Aside,
this podcast</a> had some hilarious
parts, where the host was hoping for hot debate around what C could do better
and where it shines, didn't get it, and was getting jokingly visibly frustrated
when the guests mostly kept agreeing with each other about how bad C was and why
they nonetheless stick to most of its core principles.</p>
Currently the game is entirely tile-based with tile-based positions and
movement. Entities are just a struct of a position and sprite, in that order.
Collision is a simple can-move-to-world-tile check at this time.</p>
I had never implemented a camera before, so that was interesting. Being real
with you, it took me an embarassingly long amount of time to conceptualize the
transformation in my head. My understanding is that there are two common types
of camera setups in top-down 2D games, and they differ in how the camera
position is tracked. One setup tracks the camera position in screen pixels as
the top-left corner of the screen (if your render system places (0, 0) at the
top-left of the screen. The other setup tracks the camera position in screen
pixels as the center of the screen. In my case, I track it at the center of
the screen. This is so that if I want to "watch" any particular tile or entity,
all I need to do is set the camera to that entity's position. Currently I do
so for the player, so the camera tracks the player as the player moves.</p>
Regarding the transformation, consider the following scenario:</p>
+-------+(0,0) px
</span>|
</span>v                        Screen
</span>XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
</span>X  |                                                        X
</span>X------------------ screen width ---------------------------X
</span>X  |                                                        X      Game Map
</span>X  |                     +----------------------------------X----------------+
</span>X  |                     |                                  X                |
</span>X  |                     |                                  X                |
</span>X  |                     |                 o                X                |
</span>X  |                     |                 ^                X                |
</span>X  |                     |                 |                X                |
</span>X  | screen              |                 +---+tile to     X                |
</span>X  | height              |    o                 render on   X                |
</span>X  |                     |    ^                 screen      X                |
</span>X  |                     |    |                             X                |
</span>X  |                     |    +---+camera pos               X                |
</span>X  |                     |                                  X                |
</span>X  |                     |                                  X                |
</span>X  |                     |                                  X                |
</span>X  |                     |                                  X                |
</span>X  |                     |                                  X                |
</span>XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX                |
</span>                         |                                                   |
</span>                         |                                                   |
</span>                         |                                                   |
</span>                         |                                                   |
</span>                         +---------------------------------------------------+
</span></code></pre>
Assume we want to render the point labeled "tile to render on screen." To do
this, we need to find that tile's position in screen space. The tile has a
position in game-map tile space (Px, Py). The camera has a special property
of having a position known in two frames. It has a game-map position (Cx, Cy),
and we also know it has a fixed position in screen space in the center, which is
(screen width / 2, screen height / 2). The formula to transform the tile to
render from game-map space it screen space (Psx, Psy) is thus</p>
(Psx, Psy) = ((Px, Py) - (Cx, Cy)) * (tile width px, tile height px) +
</span>             (screen width / 2, screen height / 2)
</span></code></pre>
(Px, Py) - (Cx, Cy)</code> gets the tile position in game map space relative to our
camera position. If the camera were at (0, 0) in game map space, the position
relative to the camera would simply be (Px, Py)</code>. Multiplying by (tile width px, tile height px)</code> transforms the game-map tile coordinates into game-map
pixel coordinates (the coordinate now points to the upper-left corner of a
particular tile). Finally, to transform game-map pixel coordinates into screen
pixel coordinates, we need to add the camera offset. Again, if the camera were
at (0, 0)</code>, we would be done.</p>
This transform can produce coordinates outside of the visible screen space. As
one of my commit messages above suggests, if we don't avoid rendering outside
of the screen space, we will pay the cost of rendering. I found with SDL3 that
even if I set the render clip rectangle to the screen space, I still run over
my frame times. So, I also have some logic to determine the subset of the game
map to consider for drawing to the screen on a given frame, and then I apply
the transform shown above to convert visible tiles to screen space.</p>
On to game map design, I will stick with pixel art and Aseprite. I made a small
patch to my Aseprite tilemap binary exporter to adjust the exported file names,
and then I introduced a Python utility on my game-code side to transform
.aseprite</code> files to binary map files. The script ultimately transforms as
follows:</p>
test-map.aseprite -> .
</span>                     ├── test-map/
</span>                     │   ├── tileset1.png
</span>                     │   └── tileset2.png
</span>                     └── test-map.bin
</span></code></pre>
test-map.bin</code> is what my game code parses to load in map data, and resources
corresponding to "test-map" are stored in a folder of the same name peer to the
binary file. Paths in test-map.bin</code> are relative to the location of
test-map.bin</code>. Avoiding absolute paths in this case is for portability,
especially since the resource location on disk in the source tree is different
than the location resources are placed after a build. I put my resources in a
data</code> folder, map resources in data/maps</code> in particular. To accomodate
relocation in CMake, I have</p>
add_custom_command</span>(</span>TARGET </span>the_target </span>POST_BUILD
</span>  </span>COMMAND </span>${</span>CMAKE_COMMAND</span>} -E copy_directory_if_different
</span>    </span>"${</span>CMAKE_SOURCE_DIR</span>}/data"
</span>    </span>"$<</span>TARGET_FILE_DIR</span>:</span>the_target</span>>/data"
</span>)
</span>add_custom_command</span>(</span>TARGET </span>the_target </span>POST_BUILD
</span>  </span>COMMAND </span>${</span>CMAKE_COMMAND</span>} -E copy_directory_if_different
</span>    </span>"${</span>CMAKE_SOURCE_DIR</span>}/data/maps/"
</span>    </span>"$<</span>TARGET_FILE_DIR</span>:</span>the_target</span>>/data/maps"
</span>)
</span></code></pre>
This requires CMake 3.26. The annoying thing is that
copy_directory_if_different</code> does not do a recursive comparison, so I need to
check the top-level data</code> directory and data/maps</code> directory explicitly. Also,
content removal from the source directory does not count as a difference,
meaning that previously-removed resources can linger around in the build output.
I could remove and re-copy all resources on every build, but until I hit some
gotcha, using an old resource by accident, I won't bother.</p>
SDL3 provides a convenient
SDL_GetBasePath</code></a> which allows
me to get the path the executable is run from. This allows me to then discover
my executable-relative resource directory and correctly resolve the relative
paths in the map binary files.</p>
Something like std::filesystem</code> would be handy here, but I'm avoid std::</code> as
much as I can, so I have reimplemented just what I need. Toward this, I
introduced a simple string view utility. It's trivially defined as</p>
struct </span>StringView {
</span>  </span>char*</span> str;
</span>  size_t len;
</span>};
</span></code></pre>
where the characters are ASCII-only and the len</code> portion of the backing string
is not guaranteed to contain a null terminator. We'll see how useful this turns
out to be. I mostly introduced it because I have not introduced my scratch
allocator yet. If I had the latter, I'd allocate without thinking much about it,
knowing the memory I allocated will be reclaimed shortly after.</p>
Toward what I need from std::filesystem</code>, I introduced path_concat</code> and
path_parent</code> functions. path_parent</code> finds the parent in a provided path.</p>
StringView </span>path_parent</span>(</span>const char* </span>p</span>, size_t </span>len</span>);
</span></code></pre>
This also took me an embarassingly long amount of time to write elegantly. I
won't share the code in the event you want to challenge yourself. (By the way,
AI output was rather bloated and inefficient at the time of this writing.) My
implementation only handles Unix path separators at this time, so this will be
one implementation I need to port when going to Windows. Here are the test
cases I pass, if you want to take a go at it yourself.</p>
struct </span>TestCase { </span>const char*</span> input; </span>const char*</span> expected; };
</span>TestCase cases[] </span>= </span>{
</span>  { </span>"/a/b/c//"</span>, </span>"/a/b"</span>, },
</span>  { </span>"/a/b//c"</span>, </span>"/a/b" </span>},
</span>  { </span>"/a//b/c"</span>, </span>"/a//b" </span>},
</span>  { </span>"/a/b/c/"</span>, </span>"/a/b" </span>},
</span>  { </span>"/a/b/c"</span>, </span>"/a/b" </span>},
</span>  { </span>"a/b/c"</span>, </span>"a/b" </span>},
</span>  { </span>"a//"</span>, </span>"." </span>},
</span>  { </span>"//"</span>, </span>"/" </span>},
</span>  { </span>"/ab"</span>, </span>"/" </span>},
</span>  { </span>"/a"</span>, </span>"/" </span>},
</span>  { </span>"./a"</span>, </span>"." </span>},
</span>  { </span>"//a"</span>, </span>"/" </span>},
</span>  { </span>"//"</span>, </span>"/" </span>},
</span>  { </span>"a"</span>, </span>"." </span>},
</span>  { </span>"/"</span>, </span>"/" </span>},
</span>};
</span></code></pre>
Speaking of going to Windows, one reason I'm using SDL3 is to allow myself to
develop on Linux and macOS and "just" test on Windows. We'll see how that goes.
I really like the idea of being able to bring my macBook wherever with me and
still develop and play my game, don't really have a decent portable option with
Windows at this time.</p>
Regarding map loading and whatnot, I may ultimately bake the map data into the
final binary. I may either use the recent
#embed</code></a>
or, more than likely, just implement a tool myself to achieve the same.</p>


2025-10-15
2025-10-15T08:52:35+00:00
I heard a quote yesterday--I think it was from Chris Bumstead--along the lines
of</p>

What used to drive me now exhausts me.</p>
</blockquote>
I think it very succinctly captures my feelings about software development at
this stage of my life.</p>
I used to study programming for programming's sake. All you had to say was,
"did you know?" and you had my attention for an entire weekend, studying more
sophisitcated ways to do the same old thing, diving into arcana, reciting the
new mantras. Because I liked
puzzles</a>. Because
I wanted to be in the group that knew. "Did you know" is not a question anyone
asks to actually learn anything. It's a lead-in to a flex. Virtue signaling.
A waste of time. Studying the esoterica of physics has an end and ultimately
leads to simple solutions for everyone. I find that studying the esoterica of
most modern software leaves one prone to normalize and even perpetuate it.</p>
Now the arcana exhausts me. It's mostly mental gyration, or even worse, just
puzzles we have created for ourselves that get in the way of making meaningful
progress for the species.</p>
Use as few tricks as possible.

Write as little code as possible.

Add as few abstractions as possible.</p>
Software engineering is a means to an end.</p>
We've normalized "best practice" as a header file, an implementation file,
object-oriented whatever, 5 different kinds of constructors, meta-programmed
interfaces that help account for non-ref, ref, const ref, universal (lol) ref,
etc. Newcomers to the field look at the awful tools and think, mastery of this
is what it means to be great. The tools are so complicated that tool use itself
was reified into meaningful work when no one was looking. This is why competent
leadership in a company is so important--you need leaders who can discriminate
between someone who knows everything about hammers and someone who knows which
to reach for to build something.</p>
If you want to transform your ego into code, that's fine, but keep both off of
the critical path of something we're all supposed to use in the end. Physics
doesn't care about your ego, so I'd like to keep ego out of software engineering
for the species as well.</p>
Did you</em> know you can do pretty much everything with structs, function
overloading, and operator overloading?</p>


2025-208
2025-07-27T12:20:08+00:00
A Japanese person posted the following question in English on a language
exchange application I use: "What makes someone feel romantic love for another
person?" I've wanted to be able to discuss things like "love" in Japanese, so
this seemed like a good opportunity for me to learn in context. My Japanese is
still insufficient, but I'm sharing my reply here, in part because it does
capture the essence I've come to understand of love, and in part to act as a
benchmark of how far I've come with Japanese and how much further I still have
to go.</p>

この投稿をありがとう！
私の意見を日本語でよく説明できるかどうかわからないけど、頑張る笑</p>
「ラブ」は人によって意味が違うね。
例えば、昔にギリシャ人はラブを三種類に別れた。
この投稿に関している「ラブ」の種類は二つがあると思う（ギリシャの分類とよく合わない）。</p>
先ずはロマンチックなこと、つまり恋。
恋は相手の見た目、言動、地位、肉体的な相性などに関しているものだ。
恋の原因は先天的（例えば遺伝）と後天的（例えば文化、環境、社会）な要因だと思う。
このラブは二人がいて、私と私の相手だね。
カップルは関係のために取引している。
私は何かをあげる、例えば親切な言葉や時間や思いやりな贈り物や恋愛だ。
相手も適当なことをくれる。
もちろん、いい関係にはこの取引が仕事のようなことじゃなくて、カップルは互いにこうしたいから自然なことだね。
でも結局二人、私と私の相手、がいる。</p>
一方、愛ということもあるね。
これは一体感を探すことだ。
愛の原因は、なんとか相手の中に自分自身を見ることだ。
恋の二人より、愛は一人だけがいて、「私たち」だ。
相手にちゃんと自分自身を見るために、自分自身をよくわかって愛することが必要だと思う。
もちろん相手は自分の興味や目標があるけど、相手の中に自分自身を見るから自然に心の底から応援できるようになる、もう自分のことを愛しているのおかげで。
これは愛の逆説でしょう、相手を愛するようになるために、先ずは自分のことを愛しなくちゃいけない。
自分のことを愛するために、先ずは自分のことをわからなくちゃいけない。
自分をわかるというのは、自分の目標や価値観や前のトラウマを解けることなどだ。</p>
恋の始まりは外に見ることによる。
愛の始まりは中に見ることによる。
恋の方がわかりやすい、映画や曲やソーシャルメディアでイメージが多いから。
愛をわかるの方が難しい、あまり誰にも自分の心の底を見えないから。
（例えば両親の方が他の人より自分の子供の心をわかりやすいと思う。）
もちろん、人は年に取るにつれて変える、でも愛の原因のおかげで、カップルが一緒に変えることもできると思う。</p>
私にとって、いい関係をできるために、恋と愛とどっちも必要だと思う。
英語ではこのラブの種類について説明しかたもちろんあるけど、あまり特別の言葉じゃない（日本語とかギリシャ語より）。
私の返信のために新し言葉と表現をならなくちゃいけなかったから、もし日本語の言葉のニュアンスを誤解したなら、すみませんね！
ここまで読んでくれてありがとうございます！
またおもしろう投稿もありがとう！</p>
</blockquote>
Posted after realizing I left out another thing I wanted to share:</p>

ところで、いい関係の基準について意見をシェアしたいと思っている。
関係は履歴証で並んでいる項目のようなことに基けば基づくほど、不安定になるの可能性が高いと思う。
給料、仕事、趣味、実績、どんな学校など、これに興味があるのは問題ない。
でもこんなものは相手の性格じゃなくて、相手の性格の結果でしょう。
私にとって、適当な基準は相手と一緒にいる時心地いいや相手を深く信じられる、ユーモアが好きや相手の親切さか思いやりが好きなど。
こんなことの方が説明するのは難しいけど、恋より人生のどの時期においてもより安定していると思う。
それにしても、恋も大事なものでしょう。</p>
</blockquote>


2025-191
2025-07-10T10:40:06+00:00
Since I last wrote, I extended the bump allocator from
last time</a> to also provide storage persistent across
frames. This is necessary to contain at least two things: the general game state
struct and tilemap indices. Both of these need to persist across frames.
Previously, I was instantiating the game state on the platform side and passing
a pointer to it into my game-update function. The platform is otherwise
game-state-agnostic, though, so this didn't make much sense. For the tilemap
indices, I was just malloc</code>'ing space for them. My recent goal was to remove
all instances of malloc</code> from the game logic-side code.</p>
Now, the allocator type definition looks like this:</p>
struct </span>Allocator {
</span>  </span>void*</span> base_temp </span>=</span> nullptr;
</span>  size_t size_temp </span>= </span>0</span>;
</span>  size_t used_temp </span>= </span>0</span>;
</span>  </span>// Implementation detail: `base_persist` shall point to the beginning of the
</span>  </span>// allocated memory.
</span>  </span>void*</span> base_persist </span>=</span> nullptr;
</span>  size_t size_persist </span>= </span>0</span>;
</span>  size_t used_persist </span>= </span>0</span>;
</span>};
</span></code></pre>
The implementation detail is because I allocate a single region of memory for
both types of storage. The temporary storage starts size_persist</code> bytes after
base_persist</code>. I also modified the API to separate allocations to temporary
storage and persistent storage and to only provide the reset ability on
temporary storage. Besides resetting, there is still no general ability to
free allocated memory, meaning that allocations in persistent storage are
expected to live for the lifetime of the program runtime.</p>
The platform side sets up the allocator and its memory and passes it to my
game update function. Perhaps a bit dirty, but although I am dealing with
an allocator</em>, it really is my game's memory pool with functions to manage
the memory. Recall from the previous post that I do use the temporary storage
a bit on the platform side to build a couple strings. This is no problem since
no one should rely on exact positions of anything in temporary storage.</p>
On the other hand, I require that the platform never allocate from persistent
storage the game will use. This way, my game can always assume its game state
object lives at the beginning of persistent storage. At the beginning of each
pass through my game update function, I get at the game state via:</p>
GameState</span>*</span> gs </span>= </span>(GameState</span>*</span>)allocator->base_persist;
</span></code></pre>
My game state object has an initialized</code> flag that tells me whether I need
to actually set it up or not. Because I use mmap</code> to allocate the backing
storage, the storage is guaranteed to be zeroed after allocation. As a sanity
check, I make sure that if the game state is unintialized that
allocator->used_persist</code> is also 0</code>. I then stash pointers to this and
that in persistent storage in my game state instance, and from there I can
navigate the game memory across frames.</p>
When initializing a tilemap, I previously dynamically allocated space for as
many tilesets and layers as I needed based on what I discovered in my
binary-encoded tilemap. Now, I set up storage for some fixed number of these
things in persistent storage and point a tilemap instance at these persistent
resources during tilemap initialization. This way I can avoid dynamic allocation
entirely in the game logic, at the expense of allocating more memory up front
than I may ultimately need. I can tune the allocations as the game matures.</p>
Right now my game update function interface looks like this:</p>
/**
</span> * Update the game state based on input.
</span> *
</span> * @param a The allocator containing the memory for the game. The game requires
</span> *          that the provider does not modify permanent storage in any way.
</span> * @param input The input to use to update the game state, assumed to be input
</span> *              toward the next frame to render.
</span> * @param renderer The rendering destination for all graphics updates.
</span> */
</span>void </span>game_update</span>(Allocator</span>* </span>a</span>, Buttons</span>* </span>input</span>, SDL_Renderer</span>* </span>renderer</span>);
</span></code></pre>
At first I thought it would be nice to keep SDL things out of the game logic
code, but SDL itself is supposed to be my operating system abstraction, so I'm
fine bringing it into the game logic code. I do call SDL routines that
(de)allocate, for example creating or destroying textures. To avoid this, I
would need to build a graphics abstraction on the game logic side, probably
via various memory buffers allocated on the platform side and passed to the
game update function, have the game code write into those buffers, and then
have the platform side move content from those buffers into SDL resources. But
that is just abstraction on top of the thing I'm using for abstraction, which
is not the way to go.</p>


2025-189
2025-07-08T16:47:44+00:00
As an unintentional follow-up to yesterday's post</a>, I
ended up writing a simple bump allocator. The motivation was that I wanted to
build a routine to convert relative paths to absolute paths. For this, I
need a place to store the absolute path. The relative paths are relative to
the folder the game binary sits in, so I can't predict the full string length of
the absolute path, meaning I need to dynamically allocate.</p>
Here is the API for the bump allocator; no surprises if you've seen one before.</p>
struct </span>Allocator {
</span>  </span>void*</span> base </span>=</span> nullptr;
</span>  size_t size </span>= </span>0</span>;
</span>  size_t used </span>= </span>0</span>;
</span>};
</span>
</span>/**
</span> * Set up an allocator. The allocator's memory is guaranteed to be zeroed.
</span> *
</span> * @param a A pointer to an allocator to set up; cannot be `NULL`.
</span> * @param size The number of bytes to allocate. Must be greater than 0.
</span> * @param addr The beginning address to allocate from. Pass `NULL` to defer base
</span> *             address selection to the operating system. Note that any other
</span> *             value greatly reduces portability.
</span> * @return `false` if setting up the allocator failed for any reason; `true`
</span> *         otherwise.
</span> */
</span>bool </span>allocator_init</span>(Allocator</span>* </span>a</span>, size_t </span>size</span>, </span>void* </span>addr</span>);
</span>
</span>/**
</span> * Allocate memory from the allocator.
</span> *
</span> * @param a The allocator to allocate from; cannot be `NULL`.
</span> * @param size The number of bytes to allocate. Must be greater than 0.
</span> * @return If successful, returns a pointer to the beginning of the allocated
</span> *         region. If unsuccessful for whatever reason, returns `NULL`.
</span> */
</span>void* </span>allocator_alloc</span>(Allocator</span>* </span>a</span>, size_t </span>size</span>);
</span>
</span>/**
</span> * Reset an allocator, meaning that its memory pool is considered entirely
</span> * unused and the next attempt to allocate will start at the beginning of the
</span> * backing memory pool. This does not deallocate anything from the operating
</span> * system's perspective, but anything previously allocated in the allocator's
</span> * memory pool should be considered invalid after calling this.
</span> *
</span> * @param a The allocator to reset; cannot be `NULL`.
</span> */
</span>void </span>allocator_reset</span>(Allocator</span>* </span>a</span>);
</span>
</span>/**
</span> * Destroy an allocator.
</span> *
</span> * @param a The allocator to destroy; cannot be `NULL`.
</span> * @return `false` if destroying the allocator failed for any reason.
</span> */
</span>bool </span>allocator_destroy</span>(Allocator</span>* </span>a</span>);
</span></code></pre>
I give the user the option to specify the base address of the memory pool or
let the operating system pick it. In production, I'll let the operating system
pick it, but in development, I'll control the base address so I can predict the
general location of things in memory across program runs.</p>
In the implementation of allocator_init</code>, I use mmap</code> instead of malloc</code>,
like so:</p>
bool </span>allocator_init</span>(Allocator</span>* </span>a</span>, size_t </span>size</span>, </span>void* </span>addr</span>) {
</span>  </span>assert</span>(a);
</span>  </span>assert</span>(size);
</span>  </span>int</span> flags </span>=</span> MAP_PRIVATE </span>|</span> MAP_ANONYMOUS;
</span>  </span>if </span>(addr) {
</span>    flags </span>|=</span> MAP_FIXED_NOREPLACE;
</span>  }
</span>
</span>  a->base </span>= </span>mmap</span>(addr, size, PROT_READ </span>|</span> PROT_WRITE, flags, </span>-</span>1</span>, </span>0</span>);
</span>  </span>if </span>(</span>!</span>a->base) {
</span>    </span>return </span>false</span>;
</span>  }
</span>
</span>  a->size </span>=</span> size;
</span>  a->used </span>= </span>0</span>;
</span>  </span>return </span>true</span>;
</span>}
</span></code></pre>
In short, we permit reading and writing on the allocated space, the memory
region is private to our process (MAP_PRIVATE</code>), we do not use file-backed
memory (MAP_ANONYMOUS</code> and -1</code> for the file descriptor parameter), and
should the caller request a specific base address, we tell the operating
system to use a fixed address and force failure if our requested address has
already been mapped by us elsewhere in our process (MAP_FIXED_NOREPLACE</code>).</p>
I'm using this as a frame allocator, meaning that at the beginning of each frame
(at the beginning of each iteration through the game loop), I call
allocator_reset</code>. I set up the allocator right after initializing SDL near the
top of main</code>, outside of the game loop. This allows me to use the allocator
before entering the game loop for any one-off scratch work I need to do, and
then immediately upon entering the game loop (with the exception of capturing
the frame start timestamp), the allocator is immediately reset.</p>
Before entering the game loop, I use my relative-path-to-absolute-path utility
to build the full path to the game logic library so that I can check its last
modification time via stat</code>. I then periodically re-build the full path in the
game loop when I go to re-check the modification time, so in the future, I will
likely also introduce separate, persistent storage to cache such things.</p>
Instead of having to implement my own way to get the base path of the game
binary across operating systems (using convenience functions in Windows and
checking /proc</code> things in Linux, for example), I can thankfully just leverage
SDL_GetBasePath</a>.</p>
The interface of my routine to build absolute paths looks like this:</p>
char* </span>abs_path</span>(</span>const char* </span>path</span>, Allocator</span>* </span>a</span>);
</span></code></pre>
It takes an allocator to use to obtain storage for the final string. The Jai
language I mentioned in a previous post does something similar for routines that
need to dynamically allocate but passes the current allocator to the function
implicitly in an argument called the context. I don't have that language feature
in C/C++ without approximating via OOP, globals, or function/method partials,
so the allocator is an explicit parameter in my case. I don't like this
signature much, but it accomplishes what I need. I haven't covered this detail
yet, but I have also separated more of the game logic code from the "platform"
and exposed a higher-level game_update</code> function from the game logic library
to the platform. The game_update</code> function will likely eventually receive a
handle to the frame allocator so that it can allocate whatever it needs in a
single frame in a manner I can easily control and introspect. That is how
game logic code will also be able to use things like abs_path</code> without owning
any particular allocator or backing memory pool.</p>
Here are a couple other things I learned along the way. First, it is not only
Linux that has alloca</a>;
Windows
has it</a>
as well. The main difference besides the literal function name is that Linux's
causes undefined behavior on stack overflow whereas Windows's will raise a
structured exception</a>.
I could use this for building strings as I don't anticipate memory required
for paths to be so large that it would cause a problem on the stack. The
second thing I learned is that man pages can even reference books. I noticed
the man page for mmap(2)</code> (Linux man-pages 6.7, 2023-10-31) referenced
what appeared to be a book, and upon looking it up, indeed, it is "POSIX. 4:
Programming for the Real World," by Gallmeister. Interesting, might want to
skim through it.</p>


2025-188
2025-07-07T15:55:33+00:00
In my game, I want to control the pool of memory from which all allocations are
made. This will help with debugging and also general stability, if I can
allocate all memory I will need up front and then parcel that memory out
internally on-demand. I haven't gone into much detail about why I am not using
a game engine, but having more control over allocations or at least the memory
pool being used is one of them.</p>
SDL provides
SDL_SetMemoryFunctions</a>
which a developer can use to specify the functions to call in place of the
typical malloc</code>, calloc</code>, realloc</code>, and free</code>. I have previously
implemented my own simple linear allocator, from which all I ever did was
"malloc</code>" a few times. SDL is its own animal, though, and until I read its
code, I need to treat it as if it could ({de|re})allocate at any time. This is
unfortunate since it complicates the problem for me, but it's one price I pay
for using a powerful abstraction like SDL.</p>
Although I am compiling SDL3 from source for my game, I have not read into the
code yet. To get a rough sense for how many allocations are happening and which
memory-related functions are actually called, I wrote shims for the memory
functions, registered them, and ran my game. One such shim looks like</p>
static int</span> my_malloc_count </span>= </span>0</span>;
</span>void* </span>my_malloc</span>(size_t </span>s</span>) {
</span>  </span>printf</span>(</span>"my_malloc called; c: </span>%d</span>\n</span>"</span>, my_malloc_count</span>++</span>);
</span>  </span>return </span>malloc</span>(s);
</span>}
</span></code></pre>
What I see is that a lot of allocation happens initially, both with calloc</code> and
malloc</code>. This is SDL initializing its subsystems. On shutdown, a lot of
free</code>ing happens, which is cleanup. On the first pass through the game loop,
calloc</code> is called hundreds of times, realloc</code> is called maybe about ten times,
and malloc</code> is called a few times. realloc</code> is also called, although extremely
rarely relative to the other calls. Presumably SDL lazy-initializes some things,
and the first pass through the game loop is having SDL finish its initialization
as I use various subsystems. On all other iterations through the game loop, I
see only the following (keep in mind my game loop is relatively sparse right
now).</p>
my_calloc called: c: 1160
</span>my_free called; c: 251
</span>my_free called; c: 252
</span>my_malloc called; c: 297
</span></code></pre>
Debugging shows that
SDL_RenderPresent</a> is what I
call that in turn calls other functions which are responsible for the
(de)allocations above. For what it's worth, I am using the GL rendering backend.
I switched to the software rendering backend and experience the same behavior.</p>
In a previous life, the linear allocator I mentioned didn't need to support
any efficient free</code>ing because I only ever allocated a fixed number of times to
set up buffers I would later reuse. What I see here is that SDL will routinely
allocate and free. So should I want to point the memory allocators at my custom
memory pool, I need to design the pool and the functions that use it in a way
that will efficiently recycle memory.</p>
By the way, I was initially calling SDL_Log</code> in my allocator shims for
debugging, but this was a bad idea as SDL_Quit</code> also uses the memory
functions after it has turned at least some subsystems off, causing SDL
to request re-initialization of the logging subsystem and then hang indefinitely
in what appears to be a sleep-and-check loop.</p>
my_free called
</span>^C
</span>Program received signal SIGINT, Interrupt.
</span>
</span>(gdb) where
</span>#0 in __GI___clock_nanosleep
</span>#1 in __GI___nanosleep
</span>#2 in SDL_SYS_DelayNS
</span>#3 in SDL_Delay_REAL
</span>#4 in SDL_ShouldInit_REAL
</span>#5 in SDL_InitLog
</span>#6 in SDL_CheckInitLog
</span>#7 in SDL_GetLogPriority_REAL
</span>#8 in SDL_LogMessageV_REAL
</span>#9 in SDL_Log
</span>#10 in my_free
</span>#11 in SDL_free_REAL
</span>#12 in SDL_RemoveHintCallback_REAL
</span>#13 in SDL_QuitLog
</span>#14 in SDL_Quit_REAL
</span>#15 in SDL_Quit
</span>#16 in main
</span>(gdb) quit
</span></code></pre>
I also noticed
SDL_aligned_alloc</a> in the
SDL documentation. It has a corresponding SDL_aligned_free</code> function as well.
The documentation says that SDL_aligned_free</code> must be used to free memory
allocated with SDL_aligned_alloc</code>, so I'm not concerned about having to
accommodate these (de)allocations in my implementation. But their presence does
raise the question of whether they would ever be called in my runtime. If they
are called, my hopes of centralizing and controlling memory allocation are
dashed. SDL3/SDL_Surface.h</code> defines the surface flag SDL_SURFACE_SIMD_ALIGNED</code>
with the documentation</p>

Surface uses pixel memory allocated with SDL_aligned_alloc()</p>
</blockquote>
and grep</code> suggests the aligned (de)allocator is generally only used when
leveraging
SIMD</a>. I also
see the aligned memory functions used in implementations for the PS2, PSP, and
PS Vita, but these are not targets of mine. I checked whether that surface flag
was set on surfaces I am loading, and it is not. So I can probably safely
ignore the aligned (de)alloc interface.</p>
So now the question is, how much work is it going to be to implement my own
memory pool and allocator to support SDL's behavior? Regardless of the
implementation effort, there is also the testing effort, such as unit tests
and then fuzzing with
asan</a> enabled
or something like that.</p>
...</p>
This</a>
explanation of slab allocators in older verions of Linux tells me I'm going
to be spending a lot of time writing an efficient allocator. The slab allocator
is an interesting concept and an appropriate one to use in my case, in my
opinion. One feature is that it caches previous allocations of particular
sizes, anticipating that such allocations may be requested again. This is
exactly the case in my game loop. It also does more advanced things such as
adding "coloring" (padding) between slabs to try and keep different allocated
regions in different cache lines, so that re-allocating one region does not evict
neighboring regions from the cache.</p>
Then there is the backing
buddy allocator</a> which
handles coarser-grained allocations, typically on the order of pages. I don't
need to bother much with this, as for my own pool I'd make a single mmap</code> or
malloc</code> call to the system to get the memory for my pool.</p>
I would like to leverage something like an
arena allocator</a>
for per-frame storage and just clear the storage at the top of each iteration
of the game loop, but that SDL_RenderPresent</code> calls malloc</code> and doesn't
seem to free that allocation until the next call through tells me I shouldn't
free the underlying memory on a frame boundary. The Jai language has a dedicated
temporary storage that is recommended to be used in just this way for
applications with something like a game loop in them. (Aside: Jai is my favorite
language in the C++-contender space. I am just using my favorite dialect of C++,
which is C with funtion and operator overloading, for early game development
work because I want to reduce the amount of things I need to get better at all
at once.) I'd even accept two memory pools, one persistent across the lifetime
of the application for things like SDL subsystems, and the other being that
frame-temporary storage. Alas, I don't think I can find the lifetime boundaries
of allocations made by dependencies so easily and thus don't know when an
arena could be reset.</p>
So I wondered, could I use something like
jemalloc</a> and just hand over a memory
pool to the library and have it allocate from there? The answer is yes, although
this is non-trivial, and it of course brings in another sophisticated
dependency. So at the expense of making my game harder to trace and debug, I
would have more control over the memory (de)allocations. I'm not ready to make
that trade.</p>
Lastly, I am toying with the idea of just letting SDL use the system-provided
allocators and introducing a simple bump or arena allocator for per-frame
storage. The current conclusion of my investigation is to put this off to a
later time. The control/complexity tradeoff is not in my favor yet.</p>


2025-187
2025-07-06T22:14:10+00:00
I implemented basic code hot reloading. Say in your game, you are in the middle
of playtesting some long, complicated level, and you find some undesirable
behavior. You want to modify your game code to fix the behavior, but then you
have to recompile your game and get back to where you found the issue in order
to test your change--that or hack up a minimal reproducible example for this one
case--to verify if your fix worked.</p>
Another approach is to separate the code for the game logic from the platform
code and then dynamically load the game logic into the running platform. This
way, you can change the game logic while keeping the game with all of its game
state alive and test changes much more quickly. I have to thank
Handmade Hero</a> for this idea. I'm
currently developing on Ubuntu, so this post will cover how I achieved hot
reloading on Linux.</p>
First, a simple demonstration. The video below shows a running game instance
where I have moved the player somewhere away from its origin. The tile the
player currently occupies is initially red, but then I change the game logic to
render it as green, recompile the game logic library, and the game instance
detects the library change, reloads the library, and then the tile is rendered
as green, all while keeping the game and its state alive.</p>

    
    Video not supported.
</video>
Until now I kept all the game code in a single file, but I pulled some (rather
arbitrary) code out into a separate file to have something to compile into the
game logic library while I was standing up hot reloading. Once we do this, we
need to add a layer of abstraction between the functions the game logic library
provides and the callsites outside the library. Essentially, we replace direct
calls into some code with calls through function pointers that we point to
implementations of routines we want to call. The implementations exist somewhere
in our game logic library which we will now be dynamically loading into our
platform.</p>
The gist is like this.</p>
#include </span><dlfcn.h>
</span>
</span>// ...
</span>
</span>constexpr int64_t TARGET_FPS </span>= </span>60</span>;
</span>constexpr int64_t GAME_LIB_CHECK_EVERY_N_FRAMES </span>=</span> TARGET_FPS; </span>// Every second.
</span>
</span>typedef int </span>(</span>*</span>FooFn)(Foo</span>*</span>, Bar);
</span>
</span>struct</span> stat lib_stat </span>= </span>{</span>0</span>};
</span>const char*</span> lib_pathname </span>= </span>"./path/to/lib.so"</span>;
</span>int</span> stat_ret </span>= </span>stat</span>(lib_pathname, </span>&</span>lib_stat);
</span>assert</span>(stat_ret </span>== </span>0</span>);
</span>uint64_t lib_stat_frame_counter </span>= </span>0</span>;
</span>void*</span> lib_handle </span>= </span>dlopen</span>(lib_pathname, RTLD_LAZY);
</span>assert</span>(lib_handle);
</span>FooFn foo_fn </span>= </span>(FooFn)</span>dlsym</span>(lib_handle, </span>"foo"</span>);
</span>assert</span>(foo_fn);
</span>
</span>while </span>(run_game_loop) {
</span>  </span>// ...
</span>  </span>// Maybe reload game logic library.
</span>  </span>// ...
</span>
</span>  Foo f{};
</span>  Bar b{};
</span>  </span>foo_fn</span>(</span>&</span>f, b);
</span>}
</span></code></pre>
The typedef</code> establishes an interface between the library to hot reload and
the end user. Unlike what I show here, I'd put it in header files corresponding
to the library to be reloaded. We then deal with
stat(2)</a> and
stat(3)</a> which we will
be using to get at the file modification timestamp on our game logic library.
stat</code> needs to get at inode</a> information
and is thus a syscall, so it is "slow," but we also aren't going to be recompiling
our library every frame, so we don't need to poll for the modification timestamp
on every iteration through the game loop. That's where lib_stat_frame_counter</code>
comes in--we'll only poll every so many frames; in this case, once a second.</p>
We next call dlopen</a> which
loads a library and gives us back a handle to it. We perform lazy symbol loading
with RTLD_LAZY</code> to avoid loading in all symbols our library might contain when
I will only use a few of them on the platform side. To load symbols of interest,
we call dlsym</a>. We cast its
return value to the type of the interface our requested symbol represents.</p>
Not shown in the code above, but in the game loop, every
GAME_LIB_CHECK_EVERY_N_FRAMES</code>, we call stat</code> again and check if the
modification timestamp on our library has changed. If it has, we
dlclose</a> our current
handle on our game logic library and then repeat the dlopen</code> and dlsym</code> work
to get at the new implementation of our exported routines.</p>
Finally, the game loop calls our routines through our function pointers; shown
above is a call through foo_fn</code>.</p>
In a C++ context, the symbol name of the function foo</code> will be
mangled</a>. To prevent this, we wrap
our declaration of foo</code> in our game logic side inside extern "C" { }</code>. If you
wanted to see symbol names in your library on Linux, you can do so with nm</code>.
Here are actual (truncated) examples from the test code I hoisted into my game
logic library, first mangled and then not.</p>
$ nm -D build/Debug/libgame.so 
</span>000000000000120f T _Z17map_pixel_to_tileP7Tilemapm8Vector2f
</span>000000000000130e T _Z24player_render_tile_underP6PlayerP7TilemapP12SDL_Renderer
</span>00000000000011b9 T _Z5round8Vector2f
</span>$ nm -D build/Debug/libgame.so 
</span>000000000000120f T map_pixel_to_tile
</span>000000000000130e T player_render_tile_under
</span>00000000000011b9 T _Z5round8Vector2f
</span></code></pre>
I don't need round</code> on the platform side, so I leave its symbol name mangled.
In this test, I do want map_pixel_to_tile</code> and player_render_tile_under</code>,
though, so I needed to not mangle their names.</p>
Code hot-reloading is for development and debugging only. Release builds will
link the game library in statically.</p>


2025-186
2025-07-05T14:42:57+00:00
I implemented simple collision with the environment. This time, it is probably
clearer for me to show it in action first.</p>

    
    Video not supported.
</video>
There are a few new things going on in this video. The first is that the map
looks different from last time</a>. I updated the
tilemap to add a few things the player can collide with besides the walls along
the edges. I am currently exclusively using Aseprite for tilesets and tilemaps.
Unlike map editors such as Tiled</a>, Aseprite does
not provide a way to annotate tiles in a tilemap with auxiliary information. In
Tiled, you can do so, and one such attribute is drawing invisible bounding boxes
which can be used to indicate collision areas.</p>
The way I annotated collision in Aseprite was to use an additional tilemap
layer. The tileset currently has only 2 tiles, technically 1 tile and the empty
tile which occupies an index in the tileset. I set the collision layer to be
higher in the layer stack than the map itself, set the opacity of the collision
layer to somewhere between 25 and 50 percent, and then I drew over any tile I
wanted to add collision to. I used a pink and black checkered pattern for the
tile indicating a collision area in hopes that it would stand out from other
tiles I may draw on the map.</p>

    
    Video not supported.
</video>
This approach is not convenient because I need to manage at least 2 tilemaps
for every level now. It's bug prone because I might change the underlying map
without updating the collision layer or vice versa, or I may change the index
values of tiles in the collision map but forget to do so in the game code. It
also forces a particular
software design on my game, having to parse a unique collision map for every
tilemap I load. With all of that said, it's simple, and it works, so I'm going
with it for now.</p>
I could design an alternative tilemap representation toward my game, as I do
control</a> the binary format of the exported tilemap. One
alternative is to set one of the high bits in the tile IDs in the map that
logically have collision, essentially merging my collision map into a bitfield
in each corresponding tile in the game map. If I recall correctly, Tiled does
something similar with bit-flag attributes on tiles. At this point in time,
it's not worth me implementing this myself, though.</p>
The ultimate goal is an in-game level editor, but I'm far from that at this
time.</p>
The next thing in the video is the red square that seems to be following the
player. This is a visual annotation of the tile the player is considered to
occupy. I've added it for debugging. Unlike other kinds of software development,
it's not so straightforward or even realistic to write traditional, automated
unit tests for implementations of various things in games. Often times we get more
information more quickly from visual feedback. Testing this way could also
explain how so many bugs slip through QA in games all the time.</p>
Computing the tile the player occupies introduces us to what will become a
handful of coordinate systems in the game. Currently, for ease of development
and debugging, I have only one coordinate system in the game. (0, 0) is at
the upper-left corner of the game window, and it is the origin for both the
camera and the map. Furthermore, everything is measured in pixels, until now.
Determining the tile coordinate from a pixel coordinate, assuming the pixel
and tile coordinates share the same origin, is straightforward. In my case,
positions support sub-pixel accuracy and so are floating-point numbers.</p>
Vector2d </span>round</span>(Vector2f </span>v</span>) {
</span>  </span>return </span>{
</span>    .</span>x </span>= </span>(int32_t)(v.</span>x </span>+ </span>0.5</span>f</span>),
</span>    .</span>y </span>= </span>(int32_t)(v.</span>y </span>+ </span>0.5</span>f</span>),
</span>  };
</span>}
</span>
</span>Vector2f pixel_xy </span>= </span>// ... ;
</span>Vector2d int_pos </span>= </span>round</span>(pixel_xy);
</span>size_t tile_pos_x </span>=</span> int_pos.</span>x </span>/</span> TILE_WIDTH_PX;
</span>size_t tile_pos_y </span>=</span> int_pos.</span>y </span>/</span> TILE_HEIGHT_PX;
</span></code></pre>
I designed the collision map and game map so that they are the same dimensions
and so that the tile width and height are the same across maps. I can therefore
compute the index into the collision map tiles and check whether a tile has
collision area or not. If the player tries to move into a map tile with backing
collision area, I disallow the position update. That's what we see with me
running into walls in the first video.</p>
Now that we color the tile the player is occupying, we can also see that
although the player is currently rendered as an entire tile, the player position
is represented as a single point, the upper-leftmost point of the player tile.
Because of this, the player can somewhat walk into walls to their right and
below them. I'll address this later on by changing the position of the player
relative to the player's rendered tile or perhaps changing the player's
collision point to a collision area.</p>
Lastly, although it is difficult to tell, we stick to walls somewhat. For
example, if I press against a wall on my left side and then attempt to move
diagonally up-left or down-left, I won't move at all. This is because my
proposed position is up-left or down-left of me which enters the collision
area on my left, and my entire position update is disallowed. I'll fix this
eventually, likely by checking whether we can move horizontally separately
from whether we can move vertically.</p>


2025-185
2025-07-04T20:25:29+00:00
I implemented basic player movement in the game. First, I created a simple
tileset for the player and loaded that into the game as a single SDL texture.
Each tile in the tileset is 16x16 pixels, and there are 4 tiles. The tiles are
blue squares with a white arrow showing which direction the player is facing, so
I have one tile per cardinal direction.</p>
I then created a simple Player</code> struct to hold a pointer to the texture and
other supporting information such as the cardinal direction the player is facing
and the player's position.</p>
On each iteration through the game loop, I poll for and handle keyboard events.
In the event handling logic, I save off the new key states into an instance of
my own Buttons</code> struct. I don't modify the player state immediately in the
event-handling code. The simple Buttons</code> struct looks as follows.</p>
struct </span>Button {
</span>  </span>bool</span> pressed </span>= </span>false</span>;
</span>};
</span>
</span>struct </span>Buttons {
</span>  Button up </span>= </span>{};
</span>  Button down </span>= </span>{};
</span>  Button left </span>= </span>{};
</span>  Button right </span>= </span>{};
</span>};
</span></code></pre>
For now, we just keep track of whether the button is down on the current frame.
We don't track whether it was pressed this frame or has been held down for some
number of frames. With this setup, if we wanted to understand the input delta
from the last frame, we could simply create a second instance of Buttons</code> and
store the latest frame's inputs in the second instance at the end of the game
loop so that it is available on the next iteration through the loop.</p>
Buttons previous_buttons </span>= </span>{};
</span>
</span>while </span>(running) {
</span>  Buttons buttons </span>= </span>{};
</span>  </span>while </span>(</span>SDL_PollEvent</span>(</span>&</span>event)) {
</span>    </span>switch </span>(event.</span>type</span>) {
</span>      </span>case</span> SDL_EVENT_KEY_UP:
</span>        </span>// Fall through.
</span>      </span>case</span> SDL_EVENT_KEY_DOWN: {
</span>          </span>if </span>(event.</span>key</span>.</span>key </span>==</span> SDLK_DOWN) {
</span>            buttons.</span>down</span>.</span>pressed </span>=</span> event.</span>key</span>.</span>type </span>==</span> SDL_EVENT_KEY_DOWN;
</span>          } </span>else if </span>(</span>/* ... */</span>) {
</span>            </span>// ...
</span>          }
</span>       }
</span>        </span>break</span>;
</span>      </span>default</span>:
</span>        </span>break</span>;
</span>    }
</span>  }
</span>
</span>  </span>// ...
</span>  previous_buttons </span>=</span> buttons;
</span>}
</span></code></pre>
When it comes time to update the player based on input, I just check whether a
certain button is pressed and then update the player's facing direction and a
proposed position.</p>
Vector2f proposed_position </span>=</span> player.</span>position</span>;
</span>float</span> dpos </span>= </span>(TARGET_FRAME_TIME_NS </span>/ </span>1000000000.0</span>f</span>) </span>*
</span>             RUNNING_VELOCITY_MS </span>/</span> METERS_PER_PIXEL;
</span>
</span>if </span>(buttons.</span>down</span>.</span>pressed</span>) {
</span>  player.</span>facing </span>=</span> Direction:</span>:</span>DOWN;
</span>  proposed_position.</span>y </span>+=</span> dpos;
</span>} </span>else if </span>(buttons.</span>up</span>.</span>pressed</span>) {
</span>  player.</span>facing </span>=</span> Direction:</span>:</span>UP;
</span>  proposed_position.</span>y </span>-=</span> dpos;
</span>}
</span>
</span>// The the same for right, left.
</span>
</span>player.</span>position </span>=</span> proposed_position;
</span></code></pre>
Here I assume that I always hit my target frame time, and then I multiply that
time converted to seconds with my configured running velocity to get a distance
the player would have moved in meters. The screen is drawn in pixels, though, so
I convert meters to pixels, and that is my delta position (dpos</code>).</p>
I also handle down-up and right-left separately. This way the player can move
both vertically and horizontally at the same time. I handle down before up,
meaning that if the player presses both down and up at the same time, down takes
priority. They will face and move downward. (Notice that I add, not subtract,
dpos</code> in the down case--SDL's coordinate system places (0, 0) at the top-left
of the rendering space.)</p>
Handling right-left separately means that the player will always prioritize
facing a right-left cardinal direction instead of a down-up one if either right
or left were pressed on a frame.</p>
Although I simply update the player's position with the proposed position here,
I am setting myself up for handling collision. It's possible we should not be
able to move where we want to move, so I keep the proposed position separate so
I can test it before updating the player state.</p>
Here is a video of what I have so far. The grey border is supposed to be walls,
and the white is just a placeholder tile for the ground. You can see the blue
player moving around with the arrow updating in the direction the player is
facing (or the prioritized direction if the player is moving diagonally). The
frame rate is low, but you can tell by the diagonal movement that while the map
is based on tiles, the movement is based on pixel positions and is not
tile-based. Two outstanding issues are the fact that there is no collision yet
and that the player is faster if moving diagonally as opposed to just vertically
or horizontally.</p>

    
    Video not supported.
</video>


2025-184
2025-07-03T15:40:29+00:00
When I went to implement basic player movement, I needed to capture keyboard
input. This is done in SDL by polling for events and then processing
keyboard-related ones.</p>
SDL_Event e;
</span>while </span>(</span>SDL_PollEvent</span>(</span>&</span>e)) {
</span>  </span>switch </span>(e.</span>type</span>) {
</span>    </span>case</span> SDL_EVENT_KEY_UP:
</span>      </span>// Fall through.
</span>    </span>case</span> SDL_EVENT_KEY_DOWN: {
</span>        </span>if </span>(event.</span>key</span>.</span>key </span>==</span> SDLK_DOWN) {
</span>          </span>// ...
</span>        }
</span>      }
</span>      </span>break</span>;
</span>    </span>default</span>:
</span>      </span>break</span>;
</span>  }
</span>}
</span></code></pre>
What I want to focus on in this post is the implementation of SDL_Event</code>. If
you look at its documentation</a>, you'll
see that it's a union</code>. Its first member is type</code> which encodes the event
type--it's what we're switching on in the example above. If you look at the
implementation of any of the SDL_*</code> union members, you will see the first
field of each of those structs is an instance of SDL_EventType</code>.
SDL_EventType</code> is implemented as a C enum, which is represented as an int</code>
behind the scenes, which is the same number of bits (although different
semantics) as the Uint32</code> (uint32_t</code>-equivalent) type</code> member in the
SDL_Event</code> union on nearly all modern platforms.</p>
For reference, see the implementations of, for example,
SDL_ClipboardEvent</a>,
SDL_TouchFingerEvent</a>,
SDL_MouseButtonEvent</a>,
or SDL_QuitEvent</a>.</p>
In other words, no matter which member of the union you work with, the first
field will always be something encoding the event type.</p>
This construct is called a
discriminated union</a> (or tagged
union). Here is an all-in-one example:</p>
enum </span>TypeTag { </span>kFoo</span>, </span>kBar</span>, </span>kNone </span>};
</span>struct </span>Foo {
</span>  TypeTag tag;
</span>  </span>// ...
</span>};
</span>struct </span>Bar {
</span>  TypeTag tag;
</span>  </span>// ...
</span>};
</span>union </span>DiscriminatedUnion {
</span>  TypeTag tag;
</span>  Foo foo;
</span>  Bar bar;
</span>};
</span></code></pre>
With discriminated unions, you can avoid inheritance and still compose one type
that behaves as an instance of this or that type depending on some context, and
you just check the value of tag</code> to know how to access fields of the union. You
lose anything you might have otherwise gained through polymorphism, and the
total size of DiscriminatedUnion</code> is the size of its largest member (plus
padding, potentially; see the interesting note at the bottom of the SDL_Event</code>
implementation</a>). However, the
discriminated union construct supports
data-oriented design</a> by
concentrating data of interest nearby in memory instead of potentially scattered
about through a network of pointers (whether these pointers be
pointers-to-base-class in some data structure, or members of instances pointing
to this and that data, or the CPU figuring out which methods to call via
dynamic dispatch</a>).</p>


2025-183
2025-07-02T10:17:27+00:00
Today a simple feature I added to the game was a target frame rate. This is
typically done in one of three ways.</p>
The first is by using timers in your game
code. You capture the start time of when processing begins for a single frame,
then you capture the time processing ends for that frame. Subtract the times,
and if the time required to prepare the frame is less than your target frame
time, sleep the thread for the difference in times.</p>
The major issue with this approach is that the thread you're collecting timing
information on can be preempted at any time by the operating system. Depending
on which operating system (or language library) features you use to measure
time, you may accidentally be ignoring the time your thread spent off the CPU.
That time passes in the world outside the computer and so can cause
inconsistencies between the time your game thinks elapsed and the wall-clock
time that actually elapsed.</p>
The second way to achieve a target frame time is by using performance counters.
Performance counters are typically built into modern processors and track some
kind of low-level hardware event. In this way, the counter itself is independent
of operating system nuances such as scheduling. The operating system provides an
API to access the performance counter value. As we don't necessarily know what</em>
is being measured by the performance counter, we don't know what the count is
relative to. Thus, the counter value itself is not a measure of the passage of
time. The operating system also provides an API to query the frequency of
increments to the performance counter, and with this information, we can compute
the passage of time.</p>
dt_s = (perf_counter_now - perf_counter_then) / perf_counter_frequency
</span></code></pre>
SDL3 provides
SDL_GetPerformanceCounter</a>
and
SDL_GetPerformanceFrequency</a>
for this purpose.</p>
The third way is to externalize synchronization, to rely on display hardware to
indicate when a new frame can be drawn. This is done via "vertical
synchronization," also called
VSync</a>.
If your GPU supports VSync and you enable VSync in your renderer, your GPU
synchronizes drawing the frame buffer with the refresh rate of your display
hardware (ex: your monitor). If your mornitor supports running at 60 Hz and 144
Hz, and if you configure your monitor to run at 144 Hz, then your GPU will send
whatever is in your graphics buffer to the display 144 times per second, making
your display frame rate 144 Hz.</p>
To use VSync effectively in your game, you likely need to make your game loop
frame rate-independent. If your player has a very fast refresh rate on their
monitor but your game sometimes takes a while to draw its next frame, you might
not hit your frame timing. It's no problem to draw the same thing twice while
you're preparing your next frame, but you need to make sure you account for the
passage of time independent of refresh rate (performance counters help with
this). It helps to do general math in your game in SI units--meters, seconds,
etc. This way regardless of whether you hit your frame time or not, the movement
of things in your game (for example) is natural. Things don't move faster than
expected on fast refresh rates and slower than expected on slower refresh rates.</p>
SDL3 provides
SDL_SetRenderVsync</a> for
this purpose.</p>
Regarding the first and second approaches to hitting a target frame rate, they
are complicated by two assumptions.</p>
The first assumption is that your player's
display hardware is some harmonic of your desired target frame time. In other
words, if your target frame rate is 60 FPS, then if your player's monitor is
rendering at 60 FPS or perhaps 120 FPS, you most likely will not encounter
screen tearing</a>. Your 60 Hz game
loop might be out of phase of the display hardware's refresh cycle, but this
means you'll always have your next frame prepared by the time the display
hardware draws its next image. Also, your game's cycle time is not outpacing or
falling behind the cycle time of the display hardware, so you will likely never
be partway through preparing a new frame when the display hardware starts
reading the frame data to draw the next image. If your cycle timing is not a
harmonic of the display hardware's, your game loop will, theoretically,
eventually be updating a frame while the display hardware is reading the frame
buffer to draw its next image.</p>
The second assumption is that you always hit your frame time. Even if your
cycle time is a harmonic of that of your display hardware, if your game loop
runs longer than your target frame time, you are at risk of screen tearing.</p>
With all this said, unfortunately none of these three techniques guarantees
smooth rendering. See this great
article</a>
for why.</p>
As for me, for now, I am using the performance counter technique for simplicity.</p>


2025-182
2025-07-01T16:34:01+00:00
Today I implemented simple tilemap rendering. In my
previous post</a>, I discussed exporting a tilemap from an
Aseprite file as a binary file. I parsed that binary file in my game and then
used SDL3_image</a> to load the
tileset image. I was considering using stb</a>
image to do the loading, but since I'm committing to SDL, I figured I'd learn
SDL3_image. If it feels too heavy, I'll switch to stb.</p>
After building and using SDL3_image, when launching my game, the main window
would open, close quickly after, and then open again. The fix for this was
calling SDL_CreateWindow</code> with the SDL_WINDOW_HIDDEN</code> flag and then showing
the window only after I create the renderer (which I do separately from creating
the window).</p>
The gist of accelerated graphics rendering in SDL is to load your media into
a surface</a> and then from a surface
create a texture</a>. In my case, I am
dealing with tilemaps which themselves are built from tilesets. For the
uninitiated, I'll give a quick outline.</p>
A tileset consists of sprites. A sprite is essentially an image. Using text as
make-believe images, an example tileset might contain these three "sprites":
_.=</code>. Using the previous three characters, we might build the map:</p>
========
</span>=_..___=
</span>=___...=
</span>========
</span></code></pre>
Who knows what that represents, but it is a map built from the "sprites" in our
tileset. If we were talking about actual computer graphics, our map would be
some larger, rendered image. The rendered image's size in RAM would increase as
the image got larger, but we know that the image (in this examlpe) is only
composed of three unique sprites, those from our tileset. We could compress the
tilemap by instead representing it as indices into the tileset.</p>
22222222
</span>20110002
</span>20001112
</span>22222222
</span></code></pre>
The sprites in a tileset are also known as tiles. So here we have represented a
tilemap by showing which tiles to use when rendering the map by referring to
tiles (by index) in a tileset.</p>
Back to SDL, this leaves me with multiple ways to actually store the tile data.
Currently my binary tilemap export only encodes a single tilemap (due to the way
I drew the map in Aseprite). I could load that tileset and then parse individual
tiles out of its pixel memory, create a surface for each unique tile, and then
create a texture for each unique surface. Nothing wrong with this. But what I
did instead was create a single texture for the tileset, and at render time, I
index into the texture</em> to render only a portion of the tileset texture (the
tile I want) to the window. The upside of this is that there are fewer resources
to deal with, fewer allocations. The downside is that all tiles are stored in a
single texture, so I cannot apply per-tile modulation (recoloring, transforming,
etc.) as easily.</p>
Here is an excerpt of code I wrote showing how I render from this single tileset
texture.</p>
/**
</span> * Render a tilemap instance to a renderer. `tileset` is expected to contain
</span> * the entire tileset referred to by the tilemap, and the tile properties are
</span> * assumed to be compatible with dimensions specified in the tilemap.
</span> */
</span>void </span>tilemap_render</span>(Tilemap</span>* </span>tm</span>, SDL_Texture</span>* </span>tileset</span>, SDL_Renderer</span>* </span>renderer</span>) {
</span>  uint16_t tileset_tile_width </span>=</span> tileset->w </span>/</span> tm->tile_width_px;
</span>  </span>for </span>(</span>int</span> i </span>= </span>0</span>; i </span><</span> tm->height_tiles; i</span>++</span>) {
</span>    </span>for </span>(</span>int</span> j </span>= </span>0</span>; j </span><</span> tm->width_in_tiles; j</span>++</span>) {
</span>      uint16_t tile_index </span>=</span> tm->tiles[i </span>*</span> tm->width_in_tiles </span>+</span> j];
</span>      </span>float</span> tile_x </span>=</span> tile_index </span>%</span> tileset_tile_width </span>*</span> tm->tile_width_px;
</span>      </span>float</span> tile_y </span>=</span> tile_index </span>/</span> tileset_tile_width </span>*</span> tm->tile_height_px;
</span>      SDL_FRect src_rect </span>= </span>{
</span>        tile_x, tile_y,
</span>        (</span>float</span>)tm->tile_width_px, (</span>float</span>)tm->tile_height_px
</span>      };
</span>      SDL_FRect dst_rect </span>= </span>{
</span>        (</span>float</span>)j </span>*</span> tm->tile_width_px,
</span>        (</span>float</span>)i </span>*</span> tm->tile_height_px,
</span>        (</span>float</span>)tm->tile_width_px,
</span>        (</span>float</span>)tm->tile_height_px
</span>      };
</span>      </span>SDL_RenderTexture</span>(renderer, tileset, </span>&</span>src_rect, </span>&</span>dst_rect);
</span>    }
</span>  }
</span>}
</span></code></pre>
I haven't done much work on the general encapsulation; just standing things up
right now.</p>


2025-181
2025-06-30T19:28:11+00:00
Today marks my first day working full-time on my own projects. I'm focusing on
building a game. Toward learning how everything works end-to-end from first
principles, I'm building a game engine. I will likely ship with SDL3, though.</p>
My game will feature tilemaps built from pixel art tiles. I love using
Aseprite</a> for my art. At the time of this writing,
Aseprite supports building tilemaps but only supports exporting them using
an out-of-tool script</a>. This
script exports tilemaps and supporting data as JSON. I don't want to write or
depend on a JSON parser, though, so I chose to fork and extend the script to
output binary.</p>
Aseprite scripts are written in Lua, so I needed to learn Lua. I half-jokingly
searched for "learn lua in 10 minutes" and turned up
Learn Lua in 15 Minutes</a>. Using this, the
official documentation</a>, and asking an LLM
questions here and there, I picked up Lua pretty quickly.</p>
Some interesting things I learned are that Lua has a way to allow one Lua file
to import another (require</code>) which caches anything that the imported file runs
on import so that when additional imports of the same file happen, nothing
top-level runs again. There is another mode (dofile</code>) which imports without
caching, always running anything exposed at the top-level scope in the imported
file. Another thing is that Lua only has a table data structure which doubles
as an array. Array indices start from 1</code>, not 0</code>. You can use negative
indicies when accessing the command-line arguments to find arguments passed to
Lua itself, not to your script.</p>
Anyway, without showing the full glue code, I introduced this binary.lua</code> to
the exporter script, added command-line argument parsing to the main script,
and allowed the caller to either export JSON or binary. I'll stick with binary
and write a simple parser in my game.</p>
When calling a non-graphical script from Aseprite, you do so from the command
line. You pass args before specifying the script. This is for at least Aseprite
v1.3.14.3.</p>
aseprite -b foo.aseprite --script-param bar=baz --script my_script.lua
</span></code></pre>
The content of binary.lua</code> in its initial form is below.</p>
-- Export an Aseprite tilemap and supporting data to a binary file.
</span>--
</span>-- Output Schema
</span>-- -------------
</span>-- schema_major_ver: uint8_t
</span>-- schema_minor_ver: uint8_t
</span>-- schema_patch_ver: uint8_t
</span>-- canvas_width_px : uint16_t
</span>-- canvas_height_px: uint16_t
</span>-- tilesets        : array<tileset>
</span>-- layers          : array<layer>
</span>--
</span>-- array
</span>-- -----
</span>-- An array `array<T>` is a single `uint64_t` indicating the number of instances
</span>-- of `T` immediately after. The instances of `T` are contiguous in memory.
</span>-- For example, a 2-element array of type `array<uint8_t>` is laid out as
</span>-- follows in memory:
</span>--   uint64_t (num elements)
</span>--   uint8_t  (first element)
</span>--   uint8_t  (second element)
</span>--
</span>-- string
</span>-- ------
</span>-- A string is a single `uint64_t` indicating the number of characters
</span>-- immediately following and then said number of characters. The characters are
</span>-- 8-bit bytes. Each byte is a single ASCII character.
</span>--
</span>-- tileset
</span>-- -------
</span>-- image_pathname: string
</span>-- tile_width_px : uint16_t
</span>-- tile_height_px: uint16_t
</span>--
</span>-- layer
</span>-- -----
</span>-- name        : string
</span>-- tileset_id  : uint16_t
</span>-- width_tiles : uint16_t
</span>-- height_tiles: uint16_t
</span>-- tiles       : array<index_into_tileset>
</span>--
</span>-- index_into_tileset
</span>-- ------------------
</span>-- index: uint16_t
</span>--
</span>-- Notes:
</span>-- - Strings do not support Unicode.
</span>-- - All numbers are encoded as little-endian.
</span>-- - The current schema only supports a single cel per layer.
</span>
</span>local </span>binary </span>= </span>{ </span>_version_major </span>= </span>0</span>, </span>_version_minor </span>= </span>0</span>, </span>_version_patch </span>= </span>1 </span>}
</span>
</span>-- Write select keys out of table `t` to the open file `f` as binary. See
</span>-- the output schema in the file documentation for what will be written out to
</span>-- `f`.
</span>function </span>binary</span>.</span>encode</span>(f, t)
</span>  </span>-- Schema version.
</span>  </span>f</span>:</span>write</span>(string.</span>pack</span>(</span>"<I1"</span>, </span>binary</span>._version_major))
</span>  </span>f</span>:</span>write</span>(string.</span>pack</span>(</span>"<I1"</span>, </span>binary</span>._version_minor))
</span>  </span>f</span>:</span>write</span>(string.</span>pack</span>(</span>"<I1"</span>, </span>binary</span>._version_patch))
</span>
</span>  </span>-- Canvas width, height.
</span>  </span>f</span>:</span>write</span>(string.</span>pack</span>(</span>"<I2"</span>, </span>t</span>.width))
</span>  </span>f</span>:</span>write</span>(string.</span>pack</span>(</span>"<I2"</span>, </span>t</span>.height))
</span>
</span>  </span>-- Tilesets.
</span>  </span>f</span>:</span>write</span>(string.</span>pack</span>(</span>"<I8"</span>, </span>#</span>t</span>.tilesets))
</span>  </span>for </span>i </span>= </span>1</span>, </span>#</span>t</span>.tilesets </span>do
</span>    </span>local </span>ts </span>= </span>t</span>.tilesets[</span>i</span>]
</span>    </span>f</span>:</span>write</span>(string.</span>pack</span>(</span>"<I8"</span>, </span>#</span>ts</span>.image))
</span>    </span>f</span>:</span>write</span>(</span>ts</span>.image)
</span>    </span>f</span>:</span>write</span>(string.</span>pack</span>(</span>"<I2"</span>, </span>ts</span>.grid.tileSize.width))
</span>    </span>f</span>:</span>write</span>(string.</span>pack</span>(</span>"<I2"</span>, </span>ts</span>.grid.tileSize.height))
</span>  </span>end
</span>
</span>  </span>-- Layers.
</span>  </span>f</span>:</span>write</span>(string.</span>pack</span>(</span>"<I8"</span>, </span>#</span>t</span>.layers))
</span>  </span>for </span>i </span>= </span>1</span>, </span>#</span>t</span>.layers </span>do
</span>    </span>local </span>l </span>= </span>t</span>.layers[</span>i</span>]
</span>    </span>f</span>:</span>write</span>(string.</span>pack</span>(</span>"<I8"</span>, </span>#</span>l</span>.name))
</span>    </span>f</span>:</span>write</span>(</span>l</span>.name)
</span>    </span>f</span>:</span>write</span>(string.</span>pack</span>(</span>"<I2"</span>, </span>l</span>.tileset))
</span>
</span>    </span>if #</span>l</span>.cels </span>> </span>1 </span>then
</span>      </span>error</span>(</span>"Layer " </span>.. </span>i </span>.. </span>" has more than 1 cel"</span>)
</span>    </span>end
</span>
</span>    </span>local </span>cel </span>= </span>l</span>.cels[</span>1</span>]
</span>    </span>f</span>:</span>write</span>(string.</span>pack</span>(</span>"<I2"</span>, </span>cel</span>.tilemap.width))
</span>    </span>f</span>:</span>write</span>(string.</span>pack</span>(</span>"<I2"</span>, </span>cel</span>.tilemap.height))
</span>    </span>f</span>:</span>write</span>(string.</span>pack</span>(</span>"<I8"</span>, </span>#</span>cel</span>.tilemap.tiles))
</span>    </span>for </span>j </span>= </span>1</span>, </span>#</span>cel</span>.tilemap.tiles </span>do
</span>      </span>f</span>:</span>write</span>(string.</span>pack</span>(</span>"<I2"</span>, </span>cel</span>.tilemap.tiles[</span>j</span>]))
</span>    </span>end
</span>  </span>end
</span>end
</span>
</span>return </span>binary
</span></code></pre>


2025-175
2025-06-24T19:10:11+00:00
1:14</a> to 1:28.</p>


2025-172
2025-06-21T23:11:25+00:00
A friend shared this article</a> with me recently,
talking about how worrying about looking stupid often just stunts your growth. I agree!
People should see how intentionally</em> stupid ML models are while they're "growing,"
until they're suddenly smarter than Sapiens.</p>


2025-171
2025-06-20T22:19:44+00:00
My friend sent me this article</a>
recently about people spiraling into delusions aided by conversations with ChatGPT.</p>
For some reason, the phenomenon of declining birthrates in first-world countries
quickly came to mind. There are many explanations for declining birthrates, but that it
is mostly only happening in first-world countries seems like a well-veiled form of
wireheading</a>. We used to need kids to
guarantee we have hands to work the farms and sustain the empire. Then we had kids to
carry on the family lineage. Then we had kids because, who is going to take care of me
when I'm older? Then we had kids just because that's what grown-ups do, right? Now having
kids is increasingly relegated to reacting to biological urges and personally-held images
of family. The more well-off a country becomes, the less any one individual needs to be
responsible for anything critical on the community level, and things that were once
critical to survival now largely come for "free," and we feel some sort of existential
emptiness from not having a larger-than-self, meaningful goal to grind away towards. We
often fill this emptiness with both readily-available pleasures and
ultimately-meaningless, artificially-difficult quests. We're just wireheading ourselves.</p>
The models of ChatGPT alluded to in the article presumably did not have an explicit goal
to radicalize or delude anyone. The models' ability to assume arbitrary human-like
personas had an un(?)intended side-effect of finding the
holes in the swiss cheese</a> of the
constructs that help keep one comfortably integrated into society, the constructs that
sit in front of the users' psyches. Side-stepping the question of whether ChatGPT is
"good" or "bad" in this regard, it seems to me that the delusional in the article are
liking</em> the whole experience.</p>