Sabbatical Log: November 21st

This blog series is running about a week behind my actual work, giving me time to clean things up.  The date the actual work was done is in the title, horizontal lines indicate when I stopped writing and started coding.

I’ve done a little more cleanup work this morning. I’ve removed entities from the BushSystem (so it no longer needs special compacting), and I’ve moved the compact calls into a new CleanupSystem. I like having cleanup in a system of its own, since then I get the same profiling as all other systems.

I’ve also decided that, at least for now, I’m going to trigger entity compacting every 100 GameState advances, when the ratio of dead entities to live one is >= 2, or when the EntityManager reaches the end of it’s backing buffer. Triggering any of these conditions resets the iteration count, so logically this means we’ll compact at least once every 100 iterations but may compact more frequently.

Reliably compacting entity storage also let me change the NewEntity() method into a simple bump allocator, so that’s nice.

I’ve decided today that I’m going to work on room transitions.


A random aside, I threw a memory profiler on a DEBUG build out of curiosity. It’s nice to see that there’s basically no churn once things settled down after app start.

At the moment, the only actual allocations are creating new Components. At some point I’ll move those to an object pool, and then we should get to actually zero allocations during normal operation.


I’ve now got the very basics of edge-triggered screen transitions working. There’s still a lot to do, for one the camera isn’t really aware of transitions which results in it lurching forward at the start.

The approach I went with was:

  1. Mark everything in the current room as needing to be culled
    1. This uses a FlagComponent, so it’s cheap
  2. Load up the new room
  3. Go over all the old entities and update their positions so they are in the same logical position, but now relative to the new room’s coordinates
  4. Disable loads of systems that shouldn’t be running during the transition
  5. Apply a velocity to the player in the appropriate direction, to keep them moving into the new room
  6. Let the game state advance until the camera lies entirely within the new room
  7. Go remove all the entities marked in step 1
  8. Re-enable all the systems disabled in step 4

This approach is pretty generic in terms of keeping things where they “belong” during a transition, and involves a minimum of new code. The only tricky part was getting the math down for transitioning between the rooms – I’m not convinced it’s completely correct.

I’ve been fighting a headache for an hour or so, so I’m going to call it for today. Tomorrow I’ll focus on fixing up the camera’s behavior, making sure transitions work between rooms of different sizes, and getting some test cases in.

Here’s the current behavior.

If you pay attention to the trees you can see the old entities getting culled at the end of the transition. The camera jump is apparent as well – it’s a consequence of the camera always wanting the player to be in the center of the screen, unless at a room’s edge, and the logical removal of aforementioned room’s edge.

Continue onto November 22nd and 23rd



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.