AI level data processing tech and asset compilation were the two things I found most important in these two weeks. There were some other things, though.

 

Direct3D11 port is finished

...and it has pretty much replaced the Direct3D9 renderer at this point.

Seems to be working fine too.

 

Fixed hitbox issues

The frequent bullet misses are no longer a problem

For quite some time I was wondering why it was so hard to hit the enemy. Found out that there were some issues with hitbox raycasts. That's solved now.

There are still plans to improve the controls, making aiming more appropriate for gamepads. Currently it's decent only for mouse users, gamepad users might find it a constant struggle against an ever-changing time/position reference frame. Some might enjoy it but from my observations they appear to be a minority that spent their childhood playing hardcore games. And I'd like the game to be more inclusive than that.

 

Covers and their absence

If I was an AI soldier, where would I stand...

After some thinking, I came to a conclusion that the most efficient placement for enemies if they wanted to attack is... simply the inverse of standing in places shadowed by covers. The picture shows these places, calculated against player's position.

So I implemented that, as well as somewhat statistically correct point selection within those lines, taking distance into account, and line-sphere clipping to avoid stepping into positions that are already occupied.

This concluded AI tech development, which means that all I have to do now is to assemble the pre-made pieces into a proper virtual adversary.

 

Asset compiler

How many times should polishing transforms be manually applied to work-in-progress art?

This is not all done just yet, however it shows great promise already, sometimes even more than that.

The goal of the asset compiler is to automate the redundant actions done by the artist (currently, it's only me) to make art editing more pleasant and thus allowing to create more stuff in less time. This is done by creating a tool where it's possible to register all assets and the actions they require.

Currently supported texture filters: color [de]linearization, resizing, sharpening (3 types of kernels), range expansion, brightness/contrast/gamma.

Mipmaps can be pregenerated if the format supports it. For texture input, everything stb_image supports can be loaded. If the format supports extended attributes, they're also saved.

Here's a comparison between the generated texture and the original image:

Red tint was removed, color range expanded and the image sharpened. And thanks to the texture duplication option, I can easily transfer this set of filters to another texture.

As for the models, they're much more simple - data is loaded using Assimp, material parameters and some fixed filters are applied and textures are linked to them.

One unusual little feature for which I got the idea from my breakable glass implementation and the way Assimp handles model parts - I can export the same model part more than once with different settings. This is useful in situations that require multipass rendering (like glass). For example, first pass uses the "multiply" blend mode, rendering the glass tint. The second pass would render the dirt/crack layer, which needs the default blend mode.

Now, this isn't all fun and games - I still have to figure out how to handle asset revisions and caching in a way that deals with changes in source art, changes in script, relocated asset outputs, overwritten assets etc.

It is also likely that I'll generate SVG fonts here and implement some basic file copying. Not sure what to do about maps, particle systems and characters but it's likely that they'll stay unchanged for now.

 

The current goal - prototype. Having most of my tech prepared for this, I should finally start putting things together. As they say in movies - this is the moment of truth...