Nooooodes!

It's been a little while since my last post (over a month as a matter of fact), so there's quite a bit to cover. 

So first of all, I recently started working on my first mod for Deus Ex; Tiny JC.

It came out a heck better than I expected and it was awesome seeing how easy doing this sort of thing is in the Unreal Engine compared to say, pretty much any Quake derived engine.

I'd meant to upload it this weekend gone but unfortunately wasn't feeling up to much, so that didn't happen. I need to find the time to sit down and pretty much play through a larger portion of the game just so I can iron out the remaining issues.

Besides that I also toyed around with getting the Source Engine compiled with VS2019 during a week. It was painful, but not as painful as I'd expected and I'd made some reasonable progress.

I haven't touched it since as I've been focused on other things - and there wasn't really any sort of goal or reason in mind, other than to just see how much work it'd be.

But what's been going on in the land of Yin, and co.? Much of what I've been doing since the last update has been more on the boring side of things (less visual and more under-the-hood) - this has included the following.

• Node data format; both binary and text types
• Reintroducing texture compression to the packaging utilities
  
• Support for both Quake II's and Half-Life's model formats (I.E. MD2 and MDL)
• Supersampling
• Post-processing; FXAA
  
• Minor changes to the level editor
• Started experimenting with introducing a sidebar that provides a view of the current resources
• Minor collision improvements
  
• Experimenting with TCC (Tiny C Compiler)
• Various improvements to the Platform library
• Introduced support for querying available memory on both Windows and Linux
• Minor progress on Vulkan backend
• Support for instancing (hasn't been pushed yet)
  
• Made the shader compilation a little less verbose (still provides about the same information, just not with a wall of text)
  
• Fixed a bug with the virtual file system for cached files
  

I'll go into some of these in detail below, starting with the Node data format.

Node Data Format

The Node format is a tree/hierarchical text and binary format that is going to be used for nearly everything. That includes the level format, models, configuration and materials.

Yes, I did say both binary and text. The serialisation and de-serialisation processes can support either, with the latter having the benefit of pre-processor directives - though typically the binary version is intended for release and text for development (the packaging utilities will handle the conversion when packing everything together).

Why not something like JSON? Because I wanted to have the ability to interchange the format between a binary and text representation, in addition to comments and other expanded functionality. The Node format also has more strict typing.

Additionally, the Node format also supports links to other Node files. This is an important component to the level format so that users can embed levels into other levels or point to existing data for reuse, rather than storing all of their geometry into the same file.

Unfortunately this has been somewhat responsible for my lack of progress on the editor as of late, as the plan has been to solidify this so the editor can use it as an export/import format. Everything is done at this stage with the exception of the text parser, as this still needs some additional work.

MD2 and MDL Support

So for some reason I opted to add support for Quake 2's MD2 format just because it was so easy to do. In hindsight I probably should've gone with MD3 but it's too late now.

Support for Half-Life's MDL format is in progress - not quite done yet but getting there.

My plan once the Node format is done, is to possibly move the loaders for these into the package utilities and have those convert these formats into a more uniform node-based format, either during the packaging process or as an extra option, but I'm still trying to decide.

Supersampling and FXAA

Recently I upgraded my PC and was toying around with Gears of War Ultimate Edition, having recalled how poorly it ran when it came out. I was disappointed that the game still seems to suffer an odd stutter now and then, but generally looked and played great!

One of the things I immediately picked out on was that a combination of supersampling and FXAA actually cleaned up the image pretty nicely. I probably spent more time fiddling with that then I did actually playing it in the end.

Of course this then lead me onto implementing supersampling for Yin and soon after followed support for FXAA which was fairly straight-forward. I ended up using the shader made available here with some small alterations.

You can see how the combination looks in Yin in the image above. I wouldn't say it looks as clean as it does in Gears of War Ultimate, so I might need to tweak it a bit more in the future, but otherwise it looks alright for my needs.

Both the supersampling and FXAA are bound to their own configurable variables, so if you want one or the other, you can toggle them to your own needs.

FXAA obviously doesn't compare to MSAA which is something I will be implementing support for next, but the FXAA implementation did give me a good opportunity to get a post-processing pipeline in place, so post effects such as bloom should be possible now.

Right now a lot of it is also hard-coded, but my plan is to allow it to be configured via a Node file which will outline the various stages.

Tiny C Compiler

So I haven't set myself a deadline yet, but my plan is to get a little prototype game implemented in Yin before the middle of the year. Obviously this currently depends on a lot of things coming together, which is a lot of work for one guy.

My long-term plan, as mentioned before, is still to introduce my own interpreted language called YinC but that's still a long way off.

So what other solutions do we have? Well I don't want to have the game code intertwined with the engine, and I also wanted the game code to be easy to access without having access to the rest of the codebase - this lead me to looking at TCC or the Tiny C Compiler.

Essentially TCC gets statically linked with the engine, and the engine can compile the game code, which is provided under a scripts directory, on launch. With this we can also somewhat easily implement a hot-reload feature as well so that changes can be recompiled without necessarily closing the engine.

That's what I'm currently working on right now alongside getting the Node interpreter completed.