Dev Log 1/9/2021

Whew! Another three months have passed since my last dev log. Trust me, I'm more disappointed in myself than you are in me. That being said, it's high time I got y'all up to speed on progress, right?

Progress has been slow since the last update. To summarize the work I've done in the last three months, I've implemented text rendering, reworked parts of the graphics and filesystem handlers, toyed around with the idea of a custom, semi-compiled scripting language, and have made major headway on handlers for tile-sheets and dynamic world loading. 

Surprisingly enough, rendering text has been one of the more difficult parts of this project. SDL does not come with a way to handle fonts and text by default, so I had to find and implement a dedicated TTF library that plays nice with SDL. Fortunately one exists that is commonly used and is often seen as an unofficial part of the whole SDL package. Once I had that installed and setup to my VC++ project, loading TTF fonts was a breeze. All the changes I made to the filesystem handler were to accommodate safely loading font's into memory and keeping them there for future use. 

Actually rendering the text turned out to not be so easy. There are several methods with the TTF library to render strings of text. The first and most straight forward method is to use the included function to create SDL textures from a string using an already loaded font. This is the first method I used as a way to test the library. It's pretty straight forward in code and creates pretty text but comes with some hefty performance drawbacks as a new texture needs to be created every time a string is to be displayed. There are ways to work around this but nothing is perfect.

The second rendering method is to use the "glyph" datatype included with TTF library to create a table of per-rendered characters that will be used to construct renderable strings. This method is fast and memory efficient but comes at the cost of f****d up spacing between the characters. I attempted to use this method but I kept running into issues with pointers getting trampled when they were passed to my graphics handler. I decided that it would be more effort than it's worth to rework as much of the graphics handler as I'd need to for this to method to work. Especially since it works just fine with everything else I've thrown at it. 

Currently the engine is still using the first method with some tweaks. Instead of rendering strings each time they're created, the engine renders each string to a texture once as it's created, then saves that texture in memory to be called again if that string is reused. Not the most memory efficient implementation but it works faster for now and will be replaced later, so it's temporally worth it. I plan on implementing a new render method where each character in a font is rendered to a texture, then the textures can be assembled as needed to create strings. This should work faster yet as rendering only happens once and any string can then be created.

If you guys have any suggestions about rendering text, let me know in the comments below.

For a while I played around with the idea of a custom scripting language that's semi-compiled. Lua works just fine, but it does come with some drawbacks. It's entirely plain-text so it comes with the overhead of parsing strings and every script needs to be loaded raw into memory to avoid expensive I/O operations on every frame, so it's not the most memory efficient. With dozens(or even hundreds) of scripts being loaded then run on every frame, that overhead can add up. Probably not very quickly as Lua is relatively fast, but it could make a difference if I decide to add more computationally expensive operations to the engine like particle effects or dynamic lighting. 

The benefit of a semi-compiled language is that a compiler would take script files and condense them into basically a binary file of integers. All the engine would need to do is translate those integers into commands. It would  never need to even touch a string outside of being a datatype. A custom language could also be made to work specifically with features of the engine, allowing for better efficiency and parsing speeds. 

What do you guys think about a custom scripting language? Should I pursue it or is it more trouble than it's worth? I also have some documentation I've written up about it. Let me know if I should talk more about that on the technical side.

Handling tile sheets and dynamic worlds is pretty self explanatory so I'll just give a brief description of what I've done. I've been using Tiled to create tile-mapped game worlds and tile-sheets with custom properties. The tile-sheet handler I've written allows for animations to be embedded in the tile-sheet data file so animations will no longer need custom scripts like I had previously.

Not much code has gone into loading worlds yet but I have a better idea of the requirements needed. The map handler will allow for dynamic loading of entities and terrain, meaning that objects that are not visible on screen can be culled out of existence until needed. This means that maps can be theoretically as large as your storage medium without taking up all of your RAM while playing. 

In other news not related to the engine, but the game as a whole, I have started a Patreon. I hope to use it for more than just Wizards Apprentice, but for now that's all it's for. If you're interested in the game and it's development then consider supporting maybe? 

Anyway, that was a rather long winded update. I hope you guys feel sufficiently up to date on the project. If you have any questions, comments, concerns, or belligerent remarks then feel free to leave a comment.

Thanks!

Das