Feb 18 2024

Asciibrain - Memory Issues

How a simple feature, developed in one afternoon, turned into a memory corruption bug hunt that lasted almost a month… I’ve been so proud of how simple, and easy to use, my custom memory allocator has worked. Then suddenly the memory issues started happening and I had to deep dive into all kind of memory related debugging. And what started as one bug, soon turned out to be three different ones. READ MORE >>
Jan 07 2024

Playing around with opengl

Metro Siberia assets

Spent a few hours reading up on OpenGL this winter holliday. Haven’t messed around with it for 11 years.

What’s was most interesting was optimizing compile times. Using VIM and a bat-script for compilation made it pretty much instant.

Well. I realized that even if it’s nice to have basic knowledge, I find it boring. And also realized that OpenGL is considered more or less ‘deprecated’ now as a cross platform graphics api (since Mac no longer supports it). I wasn’t aware of that as a more or less established status before. If you are interested in graphics programming, then you should look into webgpu instead, it seems.

But this will be it for now. Time to go back to my beloved AsciiBrain project again.


Jan 05 2024

Status of AsciiBrain - end of 2023

Yikes, who's in charge of this enemy spawning X'-)

Haven’t posted in a while, so let’s do something about it! Big time!

Here’s a summary of all that’s happened to asciibrain (that I haven’t yet posted about) during at least the past 1,5 years. Quite a lot, this is still very much a live passion project for me.

Feb 20 2023

Asciibrain running on Linux

Migrated the project to CMake and tried compiling it on my ancient linux netbook. Had to shrink the window, other than that it worked fine!

Here you’ll also see a glimpse of my ascii smoke and text layout code…

White laptop to the left is running Lubuntu and the laptop to the right is running Windows 11.

Sep 12 2022

Ascii particle mockup

I love particles in ascii, and started prototyping on a first-look on a fire/explosion type of effect. So far it’s hard coded to explore the kind of style I’m after and see what the requirements are… Here’s the process it went through!

First try. Yellow to black. Delay per cell based on distance from center with a small offset to not have it ’too symmetric'.

Second try. Red to yellow to black.

Third try. Kick up the offset and make it longer.

Fourth try. LoL, explosion should start with yellow then fade to red (doh). Added in smoke and lowered that offset again.

Fifth try. Minor changes and tweaking. I really liked this one!

Here it is together with a fire-trail and damage implementation, how it currently looks in the game.

Jul 31 2022

AsciiBrain, UI mockup

In order to proceed with all features, I figured I need to know how my UI should look and behave. Sat down and tried to do a mockup. Damn design is hard and time consuming (I just want to code). Well, I’m happy enough with how this turned out.

Although it is a bit too much Demeo rip-off right now. Don’t worry too much about it, I’ll move away from that soon enough =)

Oct 10 2021

Asciibrain, rendering glitch

I needed to refactor my rendering pipeline for improved flexibility (adding a speed improvement in the process). But sometthing went a little wrong resulting in the following images…

This might be one of the coolest bug of my entire career!!

Another glitch
Aug 13 2021

Multiple characters and perf stats

Tiny update this time.

Support for more than one playable character
Print out performance stats in top left corner

TICK is the number of milliseconds for main update loop

BUFF is when we process our graphics buffer and create the SDL commands to draw it

REND is when SDL actually renders to screen (it’s so high because of VSYNC)

The first value is actually quite high right now, because I’m very wasteful and calculate shadowcasting and A* every frame even when nothing changes.

Apr 26 2021

Ascii rougelike progress

Haven’t written about this in a while, but there is a ton of new stuff going on…

  • Multiple states (start screen, main game) in a classic old fashioned FSM
  • Multiple entities in a turn queue
  • Simple sequence pattern for animations and commands
  • Heatmap generation to calculate moverange
  • A* pathfinding
  • Color pallette adjustments (oh, this needs to be worked on)

(oh, and those red dudes are not ascii… did some experimentation but did not really like it)

…more to come, I promise =D

Apr 17 2021


Been working a couple of evenings on this little Super Mario Run-clone for my kids to play with. It’s obviously quite early in development, but they love it anyway!

Godot has a pretty decent physics system, but as usual I prefer to do the physics myself. Starting to feel pretty good.

Jan 13 2021

Recursive Shadowcasting

Been a while since I worked on this one. But I have some very intriguing ideas, so I wanted to pick this up again. New features since last time:

  • Recursive Shadowcasting
  • Support for custom FG/BG colors
  • Mouse input
  • Text output

More to come…

Dec 27 2020

Teamed up with new artists...

Jumping crab and flying birds

Been talking with my kids for quite some time that it would be fun to make a game together, Now Edda has started actively talking about it, so during the holidays I went ahead and made one.

Funny thing is that Sigrid is the one who made the graphics so far. It’s placeholder though, as she wants her graphics for another game (not supposed to be a jumping crab!!!)

Sep 13 2020

Pew pew pew, part 8

Starting to refactor systems. Split out the enemy wave manager into a ship builder class (build and configure enemies based on type), spawn position solver, and a waveManager (that decides WHEN to spawn WHAT ship). Turns out I need to put more effort in the last part, while the two former worked pretty well.

Did a new enemy type as well. A re-make of the shotgun turret from pewpew5 (that never made it into the game).

It is supposed to be a bullet hell after all =D

Sep 08 2020

Pewpewpew, part 7

Finally got some time for this old prototype again!

Added one more enemy (you can glimpse him in the gif), strolling around and planting mines to hinder your movement!

Turns out that having enemy bullets (and mines) be solid color really messed up your sense of depth. And that is super important in this game! So I changed it to simple lit. Sense of depth is improved, but it looks really ugly now! I need an artist to fix this… =(

Jul 16 2020


There is a known problem that occurs when you try to have a large number of objects moving towards the same exact point… they will meld together and in the end seem like a single object.

Jerky animation because of low framerate of the gif

In Ripple I avoided this problem by making sure we did not have enough flying/following enemies on screen at the same time. However, I have a case now where I want a ton of theese… a swarm of enemies.

Funny thing is that the math for moving an object towards a point is dead simple. Does some kind of scatter function have to be incredible complex? Or can we do it in an almost as simple way? I had a theory I wanted to try, here’s the psuedo code.

   for each enemy in enemies
   if enemy == me: continue
   if distance D is less than minAllowedRadius R
      move me away from enemy in opposite direction by distance D

Result 1


Looks glitchy. Figured out pretty quick that we push by distance D, which means that if minAllowedRadius is 25 and you touch the outer rim of it, distance will be 24, and you will be pushed 24 units instead of 1 unit. And the opposite, if your are 1 unit away you will only be pushed one unit. We obviously need to push it 1 unit in the first example and 24 units in the second.

Result 2

Ladies and gentlemen... a fine swarm indeed!

Whoa! That looks amazing! I did not expect it to be that fluid!!!

Here is the final psuedo code

   foreach enemy in enemies
   velocity = (playerPos - enemy.pos).normalize * speed
   lookAt = velocity.angle() // update lookAngle before calculating scatter

   pushback = new Vector2(0,0)
   var newPos = enemy.pos + velocity
   foreach checkScatter in enemies
      if (checkScatter = enemy) continue
      otherTowardsMe = newPos - checkScatter.pos
      if (otherTowardsMe.squaredMagnitude < minAllowedRadiusSquared)
         // Too close to someone!
         otherTowardsMeMagnitude = otherTowardsMe.magnitude
         // need to adjust amountToPushBack, or we get gif number 2
         amountToPushBack = minAllowedRadius - otherTowardsMeMagnitude
         pushback += otherTowardsMe / otherTowardsMeMagnitue * amountToPushBack

   enemy.pos = newPos + pushback

As you might (or might not) notice is that I use the squaredDistance and squaredMagnitude in the first check, where we see if we are in contact. This is to avoid using squared root in the inner loop (that would be a lot of square root calculations).

However, if we do have a hit we calculate the actual magnitude, so we can adjust the amount of pushback. I store it in a variable as I need it twice.

There might be even more optimized ways to do this, but doing a sqrt for N^(N-1) seemed a bit too expensive.

Oh… and this was also my first attempt at using Godot engine. Is was actually really pleasant! I might actually start using it instead of Unity for experiments and personal prototypes… at least for a while, as a test!