The Island of Misfit Game Development

It's been a couple months since I've touched my project, but I've decided that this year I'm going to really push myself to build a functioning demo. I want to be able to recreate a scene from a favorite game of mine and I've planned out deliverables for the next 6 months of work.

The plan for this month is to finish the work I started last year and get a basic UI system going. To that end, I've been putting in work this week and have some good progress. It's hackier than I'd like right now, but the goal is just to get it going and de-hack it as I go.

Sat down tonight for a little pre-weekend coding.

I have created a simple UI entity that just has render and UI components. I created a UI entity in code that will load the entity from file. I also hooked up deserialization for the UI component that will load the json and create layouts and sublayouts.

It's a little scary how easy it is to not work on this while I'm home. Maybe too many distractions?

Anyway, today I re-engaged and wrote up the initial code for my UILayout and UIComp classes. Right now it's super basic: layout contains text, offset, and sub-layouts. Component has a list of layouts, which it will load from a json file. I wrote the json file and it's also very brief. I realized I'll need to do something about multi-line strings in json, but that's another day's problem.

On Saturday I spent some time re-thinking how I'm going to approach the UI system and have broken it down into much more understandable tasks.

On Monday night and tonight I've been spending some time making a character set. Currently I'm just using 12 pt font in 16x16 squares. The character table is done and maps to the ascii/utf8 order of characters for easy lookup. It's arguable that I should have just downloaded a character set... :/ In a previous iteration of an engine I was using something provided by DirectX, not sure if that's still a thing either. But, regardless, I'll need to be able to do fonts from texture at some point. Might as well do it now.

The goal for today was to make my core types and constants globally accessible. I wanted to be able to include them without having to #include everywhere and I thought precompiled headers was the answer. I dug in to that, but it didn't seem to solve my problem and was also hard for me to get my head around.

The way I ended up solving the issue was to consolidate Types.h and Constants.h into Core.h and put them in the global namespace. I still need to include Core.h in other places, but it's good enough for now.

Today I sat down and finished converting all of the non-platform-dependent code to use smart pointers. The only things remaining in raw pointers is directX pointers and vertex data. Took a couple hours to finish up and I definitely didn't do it as methodically as I'd like.

That took way longer than it should have, but it's finally done. The last bit of refactor work I want to do is making my core types globally accessible, which I think I can do with a precompiled header.

Spent some of my vacation time Sunday and Monday and finished all the smart pointer conversions for my entities, components, and entity manager.

Tonight I converted my RenderComponent and SceneComponent data to use smart pointers. Once my conversion is done I will need to do some debugging to make sure everything is getting released as expected, but so far so good. I'm also not entirely sure I'm using move semantics right, but I can dig into that later.

The last thing to convert is Rendering and any of the App layer. That should be pretty quick and then I'll be done with this upgrade.

I'm still not as active on the project as I'd like to be. I feel like it's related to me not being super enthused by the necessary work right now. It needed to be done, but I've stretched into several months what could have been done in a couple weeks.

Tonight I sat down and re-engaged with my code. I converted CollidionData and its use in CollisionComponent and PhysicsSystem to using smart pointers.

I'm wondering if my use of vectors of shared_ptr is good, but that's a problem for another time.

The 'trick' of working a half hour a day is working pretty well so far. I haven't done every day, but I've put in more work than I have in the last two months.

So far the smart pointer conversion is going ok. Singletons are all converted, along with the Entity and System managers. Tonight I finished converting the animation data classes and that took a couple nights to do. There are multiple places where I have const vectors of pointers and converting them to unique_ptr would require implementing copy constructor, which I don't want to do, so for now they're using shared_ptr.

Tonight I sat down and thought out what I want to do next on my engine. UI is clearly the next big feature so that I have something I can interact with, debug with, and reflect game state information with.

I know the basics I need, which is a font texture, a texture with UI elements, and ui layout information for the various game states. I wasn’t sure where to put this, as I’ll have to render it all as well. This got me thinking about how I render my scene right now, because it is also a collection of renderables. As I took a second to look at my code, I realized my RenderSystem does almost nothing and I’ve got calls to SingletonRender all over the place for creating renderables. This seems wrong, the whole point of this design is to not have behavior like that strewn all over the code.

From this I realized there are two refactors I need to make: first is to update RenderComponent to be able to support a collection of renderables. There’s no reason it should be limited to one renderable per component. Second is that it is time for me to implement a method for systems to be able to communicate.I had planned to do something like this for entity destruction, but this is a good use case.

With those refactors out of the way, I’ll add the UserInterfaceSystem which will get the pertinent entities, evaluate the game state, and post the messages to update the rendered UI.

I missed a couple weeks there, but I’m back now. Where I left things last time was that I had implemented a better solution for my scene streaming, but had envisioned a much better solution.

Tonight, after reacclimating to the code, I first added some execution time logging. Before I go making any changes, I want to know the current performance. Using std::chrono I captured the time at the beginning and end of the function and then got the microseconds delta. I then added that to a ring buffer of the last 60 frames, and finally I average all the times in the buffer to get the average run time for the function.

With the current state of my algorithm, the average scene update times were: When static: 0.55 - 0.65ms When moving: 0.85 - 1.2ms

I then set out to implement the new algorithm. As described, I wanted to use the min and max visible tile information along with the movement speed and direction to determine the selection of tiles at the edge of the screen that needed to be loaded or unloaded. The logic for this wasn’t too bad, although currently there’s a little bit of code duplication. 

Once I have the list of indices to load and unload I then just iterate over them and execute my previous load/unload logic. I was able to remove the visibility checks, since I know for a fact these are off-screen tiles. The last thing I needed to do was handle scene entity loading. Since scene entities are loaded by their tile row (hack for now), I loop over all the rows within view +/- move buffer and run the existing entity load/unload on them.

After all that work, I tested it out and it works as expected. I found an index out of bounds bug, but otherwise it’s all good. And the best part is it was a significant performance improvement!

With the new algorithm, the average scene update times are: Static: 0.12 - 0.15ms Active 0.55 - 0.75ms

That’s a feel good moment.

Tonight I finished my plan to only stream tiles/entities at the edge of my scene. I don’t have a stopwatch for the improvement, but it should cut down the number of tiles I was testing significantly since I was previously testing the entire scene. The downside is that I don’t take into account the direction of movement as I had wanted and account for a buffer. The reason for this is that I ran into complications when trying to discern tiles I wanted to stream out vs those I want to stream in.

In the process of thinking about the problem, I arrived at what I think will be an even better streaming algorithm. Based on the min and max tiles in view and determining a stream buffer size from the movement speed, I can use the direction of movement with this to determine just the tile indices I need to consider for streaming in and out. 

Spent some time tonight working on my scene streaming algorithm. I’m not quite there yet, but I think I’m closer. The idea is I want to iterate over only the visible tiles plus some streaming buffer. This will add/remove scene tiles and entities as they enter/leave visibility.

I determine the stream buffer based on the camera follower entity’s mover component. I made one incorrect assumption which is that I could easily tell the min and max visible tiles from what’s already been rendered, but that completely ignores where the camera is, and also that list of rendered tiles isn’t sorted in a way that makes it easy. Lesson learned :)

Building on the work from last week, tonight I added basic sorting for each depth list. Each list has a flag that, if set, will trigger re-sorting the list before draw. The sorting itself compares the lower Y bound of each sprite and sorts them in descending order. The idea being that the lower Y bound is where the object is ‘standing’ and objects with a lower Y are considered to be in front of those higher.

With the sorting in place things were looking and behaving as expected, but I noticed a strange issue: when the player was under the shadow of the tree, he wasn’t being blended. The shadow was blending with the background fine, but not with the sprite on the same depth layer as it. I poked and prodded around at a few DX settings, and then upon a web search someone recommended turning off depth stenciling for transparencies. Since I’m doing my own depth, I don’t need it on at all, so I turned it off and voila! Sprites render as I expect them too.

While I was at it, I noticed that the player’s collision was still his full sprite, so I adjusted that and fixed some code that wasn’t including his box center. Things are looking better than ever.

Tonight I started on changing how I handle draw order. Currently everything is in one big list sorted by Z depth. The problem with this is that because of the visual style I’m wanting, the ‘camera’ is actually at the bottom of the screen so I need to sort my sprites so that things closer to the camera draw over things further away.

I’ve changed my depth list to now be one list per depth: Background, Actor, Foreground, UI. When renderables are added or removed, we do so from the correct depth list. The next thing I need to do is sort each depth list based on Y height and also re-sort movers each frame.