So my Anachronox re-implementation now compiles on both x86 and x64 architectures - and on Linux, finally. SDL2 implementation is done, though introduced a bug with movement speed... Rest of simulation seems fine, just movement is slow? Stupid shitty lockstep crap. Will look into it later given we'll be rewriting the movement logic anyway.

Apparently someone got it running on an ARM device as well? I do have an Raspberry Pi here (actually 3/4 of them), but had not really considered doing this yet as I'd like to rewrite parts of the renderer first.

Things on Yin have been busy busy busy. There's been more work on the client/server architecture, entity components, input, audio and the material system. I've been bouncing around a lot. 

Entity components are mostly done, but not yet had a reason to migrate over from the Actor system just yet, and there are some questions about how things will work from a user perspective (currently investigating entity templates outlined via node files). I've not yet considered how networking is going to work in relation to the components though...

New input stuff is mostly done, but again, not had a reason to totally migrate to it just yet, but you can outline a collection of actions with associated keys and the rest of the logic will automatically look out for any key activating said action before using a callback to do whatever is required.

For audio, there's now the AudioDriverInterface, which functions as an abstract interface towards whatever audio system is available on the given platform - in the case of Windows I've been working on supporting XAudio2 and on unix platforms I'll probably use OpenAL Soft instead. This isn't high up my list but I felt it was a good idea to get the ground work in place for doing something more substantial than what we had before, i.e. using SDL2 Mixer.

This was something that was originally envisioned for Hei but I'm on the fence about it for now, but if we have an abstraction layer for graphics in there it would probably make sense to consider one for audio, particularly as there's been a large explosion of audio APIs lately... Perhaps I'll migrate it down the line.

There wasn't really anything that substantial changed for the material system, however the post-processing is now handled through the material system finally, which was very much influenced by a bug I was trying to tackle. This did require changing how we handled the render target built-in variable, as previously this just threw over the render target used for the menu as a bodge job introduced for the game jam. The way in which we hand over the viewport size has been changed a little bit as well for the material system, but nothing too interesting to say about it.

Generally though, it's more flexible now. It also gave me an opportunity to experiment a little bit more with other effects and I think it might be likely I'll be looking at adding effects such as bloom, depth of field and more relatively soon perhaps.

Otherwise, I've been working on a tool to convert maps produced by Hammer/Jackhammer/Trench into geometry that Yin can use and been making pretty good progress. Been lacking motivation but I really hope to have it finished very soon, the only thing left to do is serialization and then we should be back to having proper environments again!

Added support for QOI to Hei before I went to bed today too. It apparently features compression close to PNG, but with a faster decoder, so that's pretty neat. It actually reminded me of arguments I'd had on another project about the speed of decoding a PNG though - dumbest argument I've ever had given it was a retro-style game with pretty small textures, so the impact was absolutely negligible, and if anything contributed to the load time it was our crappy material system we had at the time (which I take full responsibility for.) Anyway, that's all a story for another time.


Been a little while.

The language spec for Yang is pretty close to completion and the lexer is pretty much finished, though some things to figure out in-terms of the preprocessor - so much for not being a priority.

Made further improvements to material system in Yin. It's now possible to declare what defines should be used when compiling a shader stage, allowing for swapping features without having to split things into multiple files. Pretty damn happy with material pipeline now, so much is possible without having to depend on hard-code.

There was a tech demo that was shown and described yesterday, which was produced on the N64 and demonstrating portals. Implementation seemed something close to what I was working on, but my plan was to utilise stencil-buffer - though rather than using stencil-buffer, they max out z values for polygon covering area they rendered to? Not sure I entirely understand the technique, but keen to experiment.

On the side, have been reverse-engineering something rather special that I've been granted early access to with the intent of publishing an article about it on TalonBrave.info the day that it gets released (which is early December, if you're wondering). Ended up recycling an old 2D engine of mine (now under GPLv3) to demonstrate some bits and in-turn ended up rewriting quite a bit of the rendering side (typical). Changes are on a branch named 'bacon', for no particular reason.

Slowly shifting my Anachronox reimplementation over to use SDL2.

That's about it for now.


Wasn't feeling too awesome today so didn't get much done. Been making progress on the entity component system for Yin - probably almost done, but need to prototype functionality to make sure I've got everything covered. Design feels dirty, probably a better way to do it; components are registered into a template list which hold a list of instances, which we then iterate through (tick, draw, serialise and deserialise). Each component has a pointer to it's associated entity so that's used as a reference for dealing with communication between different components (i.e. does this entity have a component called x?)

Settled on calling scripting language for Yin, Yang. Very original. But I'm happy with it so whatever. Still settling on initial set of opcodes and sorting assembler, but it's a very low priority right now. Unlikely to be used for current game still, but we'll see.

In other news, starting to prototype AI for game using older foundation as a starting point. Collection of sensors settled on and gradually working out logic from there, so every tick they will search for whatever based on their type and pass input to the "brain", though brain won't do anything with that yet and need to decide on storage type when passing input - brain needs to be able to make associations and determinations based on input, and some input might be more pressing than others (i.e. pain).


Little curious how Blogger deals with an entry without a title. Hrm. Anyway felt inspired to try to do more regular updates, maybe it'll make me feel a little more accomplished, we'll see. Will be great if I can do these daily.

Today rolled the actor code into a legacy folder for the engine as work begins on the new ECS solution. Thought I'd had a good design in my mind, but having not written that down anywhere, was somewhat lost, and so a little bit of thinking to do.

Figured switching to ECS makes more sense to me in a language such as C, as we don't have the luxury of inheritance there as a language paradigm. Typically though I dislike ECS in an object-oriented environment, as I prefer the simplicity without (totally get the arguable elegance and simplicity of ECS in other aspects however.)

Currently entity holds a descriptor alongside list of components. Collection of callbacks are provided into component that run logic. Not sure how and where to best handle these callbacks right now, and how the communication between them should work.

Outlined a few basic components for starters; transformation, model and brain. In the case of the game, brain needs sensors and thus I currently suspect sensors would be another component. Ideally the brain could have just one or multiple sensors, which could be sensors of different types (sight, sound).

Flopped around considering proper client-side input API. Seems daft engine doesn't have this. Right now input is just piped all over the place, and really not keen on how actors currently check for input as the console and menu can't tell it they're pulling input. Also got me thinking about mouse-look as it's still not something supported, but due to the way camera works right now it's pretty awkward to introduce a generic handler for that.

We dooo have a global camera? Want to avoid toggle states or states in general for camera though if I can help it (was considering, fps state etc.) Right now camera gets attached to an actor and then the actor just deals with that logic for as long as that camera is attached to it. Suspecting though that something like mouse-look will end up perhaps becoming handled by a component. It all seems wrong or gross though.

Was looking to use models from Outcast as a placeholder recently, as the models look really nice. Took a look at the format, reversed it as far as basic geom, thought it was all easy, though it looks like I got the faces wrong... Lost motivation to continue with that - Hei supports Outcast's package format now at least. Have fun? Did also consider how much effort it'd be to create modding tools for Outcast; too much work right now, plus no free or open-source solution for compressing data back into pk format (i.e. implode). Bleh.

Teeny bits of work on assembler for engine scripting language. Plan is assembler first, virtual machine second and then everything else on top. Language doesn't yet have a name (internally called YScript and YinScript, but that sucks), but it currently is inspired by PL/M, PL/I and C (though leaning more towards C as it evolves.)

Oh, prototyped methods for sorting 3D environment for prototype. Yes. Wasn't happy with solutions though; absolutely suck with Blender, and did dabble with the idea of converting Quake maps (something I'd worked on in the past) - geometry isn't optimal from latter solution. Been tempted to fork Quake tools and modify qbsp to generate geometry in the way we need from the map, just until tooling for engine is completed. Not sure on effort involved though, so don't know if I should bother. Not a real problem until ECS is functional.


And Another Game Begins...

So for those that weren't aware, I had been participating in a game jam called the Quad Cities Arcade Jam, and last month I released my game! It's really nothing particularly special, as most of the time working on it was spent wrestling with getting parts of my engine into shape for it and probably about three weeks actually on the game itself, but here it is for anyone that wants to take a look.

Otherwise, I've provided a video below.

The theme of the jam was 1980s-1990s arcade games, so I picked Asteroids since it seemed like the easiest thing in my mind given the state of the engine at the time.

And now for a quick post-mortem... 

What worked well? 

Eh, not a whole lot. By the end of it, it at least felt like a somewhat reasonable demo of the versatility the engine provided.

What could've been done differently? 

Well for starters, I should've forked the engine a lot sooner - instead I thought, "oh, I've got loads of time," and continued working on making radical sweeping changes to the engine. A lot of time ended up being wasted near the end quickly bandaging parts of the engine to "work" as the deadline approached closer and closer. Oh, and I should've created a design or plan for the game - a lot of ideas came in at the end, by which time it was too late, due to poor planning.

Overall it was probably a good experience though and I look forward to trying again next year.

Open Sourcing Again!

An earlier version of the source code is now available here (this is from over a year ago if you're curious.) Unlike last time where I released the code under public domain, this time it's under GPL v3 and that will probably be the case for any other releases going forward.

Some code was stripped from the release but anyone motivated enough could pretty easily get it compiled. I've not included the content required for this either, mostly because it's a mess and would take too much time to tidy it up immediately.

If you're curious what version of the engine this is, it doesn't really have a version really but I've sort of dubbed it as "1.5" - it's somewhere between the latest version (2.0) and the first version anyway. Big shrug.

I've provided a video below showing what v1.5 looked like in action.

What's Next for Yin?

Since the jam was finished, the engine has already started to radically shift and change once again. The big target immediately has been overhauling the material/shader system further to allow for more flexibility, without depending on hard-coded tricks, which has been pushed up the list given some limitations encountered when working on the game for the jam.

For starters, the material format now uses my Node format, as a material object. I'd discussed the Node format a little bit previously here. You can see an example material below, which applies toon-like shading and an outline for a character.

The program objects, which essentially outline the shader program, have been enhanced with the introduction of a default pass which basically provides a default state a material should use when using that shader program. This means if a single pass either depends on a very specific state or set of parameters being enabled, those don't always need to be provided via every material.

It's not functional just yet but the program objects will soon also be able to provide a set of "definitions" to use when compiling the shaders too. 

I've provided an example of what they now look like below.

And the result of both of these is shown below (though instead using a placeholder model and texture.)

Beyond that, work on the editor has been restarted from scratch. We'll see how that goes. And I'm also killing off the interface layer between the engine, game and launcher - everything will just be statically linked into a single binary instead.

Next Game?

There's a game concept I've had going since 2017 now in various forms, sparked from a game jam, but it's still not quite made it's way into something actually playable - pretty much due to it's complexity from an implementation standpoint. I've never discussed what it is publicly because I don't think it's something done before? But I have uploaded ambiguous videos to my channel of some progress made towards it in the past.

From 2017 and up until August of this year, it's been on-and-off as a 2D game utilising Allegro (there was an interim where it was using Godot but it didn't provide what I needed at the time, so I rolled my own engine instead.)

After the recent jam was completed, I've decided that I will be using my new engine, Yin, instead of the 2D engine that was originally written for the game (it didn't make sense to be writing two separate engines anyway.)


I've also decided that, because the original idea was so complex to achieve on the scale that was in mind, I'm instead simplifying the concept down into a different game which will be used as a stepping stone to prototype and prepare the technology that will be necessary for my original concept.

That said, I don't think this simplified derivative will be any less interesting! I'm just hoping it actually takes off and importantly, will be fun to play.

Given the restart though, consider these now released into the public domain. Credits would be appreciated though!

What Else?

I've been taking a partial break to work on another project of mine that modifies the Quake 2 engine to support a fantastic game called Anachronox, which is creatively called 'hosae'. You can find out more about the project here.

It's been making some pretty good progress lately, though I'm obviously biased. Models are now supported with the exception of multiple skins which I've not bothered with yet, there's support for 64-bit, progress is being made to get it compiled on Linux, support for fog and alpha textures, and more.