The Playfund system is now working end to end. We did the February payout, and people got their money.

The payout threshold is $100. If you haven't earned $100, then it'll roll over to the next month. We can pay out in a number of different ways (paypal, echeck, bank transfer) to a ton of different countries.

This was the last big piece of this puzzle, and now that it's working, we can iterate and improve it.

Most texture based components can be animated with texture sheets, I gave the same treatment to decals.

To support this, I extended decals with an extra data buffer which is future proof for whenever we need to add more features without breaking older shaders.

The audio occlusion previously used a collision group called "sound" to determine what surface should occlude. By default this hit the "solid" layer. But that was stupid, because all physics automatically get a solid tag. So it hit everything, including the player controller's physics. So technically no sound could reach your ears.

So now you define the collision tags it should hit on the Mixer. Each mixer can override these settings, so you can have sounds that go through some objects, and sounds that don't. The default now is that they hit any object tagged with "world". All the static walls created by Hammer are automatically tagged as "world".

More progress has been done on our version of Datacore (Now Depot), Progressing through what assets are needed and freshening up old assets.

We've enabled ReadyToRun on our published builds. This means that it's pre-compiling the code in our c# dlls instead of using JIT to compile it just before it's used. The end result is that it reduces any micro-stutters you'd see when doing things for the first time.

The only real downside is that the dlls are a bit bigger.

I added a couple more sculpt modes this month.

Assets weren't being fully preloaded. This gave a small hitch when you did something like creating a prefab for the first time.. because it was loading all the models and textures associated with it.

Now they're preloaded, so everything is in memory, ready to be used. You can diagnose these hitches using the convar resource_log. Set it to 1 to log whenever a resource loads.

Mixers can define the maximum amount of sounds that are allowed to play on them at one time. If more voices than are allowed want to play, it'll only play the newest.

This is a performance strategy. You can divide your sounds to go to different mixers, so you can limit particularly common and inconsequential sounds (like impact sounds), while always allowing high priority sounds (like gun shots, speech).

Our Post Processing effects system is all driven by components & our managed pipeline, we removed the last bits that used Source 2's native post-processing system.

Bloom was still using that system, this gave me the opportunity to rework bloom entirely and ends up looking much better and simpler by using our texture downscaler.

The new effect can look very faint or as overblown as you want.

While removing the C++ post process pipeline, I've done some other optimizations on some post processes, which should result in overall better performance as well.

We've been thinking about open source. Obviously, we can't open-source Valve's code, but we can open our C# code. And other than our obvious embarrassment over the state of it, I don't see any reason to keep it closed.

Our challenge here isn't the decision, it's how. How would we marry the native dlls with the open source c# repo. Do we use submodules (fuck no)? Do we do use subtrees (fuck knows)? Do we make each assembly its own nuget and go super modular (my head hurts)?

I just wanted you guys to know it's on the cards. I see no value in keeping it closed source, it's just about getting the logistics right so we don't end up in a nightmare.

Glass Shader & anything that requires a framebuffer copy was reworked so that the fetching is done at the same time we are about to draw the primitive and in the correct order, this fixes translucents not showing up on glass and gives the option for multiple things that uses refraction and blur to be drawn intersecting at once.

For our rendering pipeline we use Forward+ Rendering, it's great and fast, but unlike deferred we can't implicitly fetch some material information before we do our lighting pass, things like SSAO had surface information derived from depth, so was very blocky, and dynamic reflections was an entirely different pass.

In our rendering pipeline we use Depth Prepass which rasterizes all objects before main draw to reduce pixel shader overdraw, by calculating pixel information at the same pass we can have material information ahead of time and still retain the benefits of a Forward+ pipeline, all transparently while retaining the same API that ShadingModel uses with no significant overhead.

This greatly improves effects like SSAO and allows us to move Dynamic Reflections to be entirely a compute shader pass.

In any shader you can use Normals::Sample( int2 ScreenPosition ) to get accurate normal map information.

Most of the internals of Movie Maker were completely rewritten this month, cleaning up all the hacks I did while quickly iterating. The main public API that lets you read movie clips, define tracks, and bind those tracks to stuff in the scene seems to be in a good place right now. Here's how it looks:

The editor code has been completely overhauled too, aiming to make it easy to write new edit operations and to make sure it can support undo / redo without much memory overhead. Here's how that looks:

I added a "smoothen" operation to test out the new way of defining edits, which lets you apply a blur filter to recordings. You'll be able to define your own editing operations in your project's editor code, in case the ones we include don't cover your needs.

Speaking of recordings, I've made it super easy to record player controllers by adding relevant tracks automatically when you drag one into the track list. Ideally we'd want a clean way of describing which tracks to auto-populate like this for custom components.

Now that the big rewrites are just about done, I'd like to get it published as a package for people to start using in their projects. After that I'll iterate based on your feedback, and I'm excited to see where we'll take it together.

Cylinder traces are now supported, this avoids having to create a cylinder hull shape approximation to trace with.

Shape traces can now optionally request their hit point, these are optional because they're not always needed and takes a bit more processing to calculate.

As we move closer to release we're starting to think about how our release cycle will look. When we're released we can't be pushing every commit we make to the live version on Steam - because things will be too unstable.

What we're thinking will happen will be a main "stable" branch will generally be updated only once a month (other than urgent fixes). 

Then we will have a staging branch that will receive what will likely be daily updates, which at the end of the month all get bundled together and pushed to the stable main branch.

What we want to build is a system where developers test their games on the staging branch. While we will always avoid breaking games, I think it's inevitable that we will have pain days every now and then. 

This is something we're putting a lot of thought into right now.

As you can tell, we're kind of slowing down on the flashy stuff. We're now rounding all the corners off, making what we have work better.

Getting the PlayFund stuff working end to end was a good achievement for me. We now have a fully legitimate way for creators to make money in s&box. And it's working. Now we know it works, we've started increasing the fund - so everyone will make more.

We're going to do our thing and keep steadily improving things over the next few months. Thanks to everyone who is helping us out by making suggestions and reporting issues - you're helping us make a much better engine.