A good reason to use colour rather than color in your code is that colour has the same number of letters as both albedo and normal so you can align your code better.
Fixed now. Turns out that the box filter trick of add one from rhs, remove one from lhs can go slightly negative, and gamma correcting a negative value is bad for your image.
I've been using Linux since it was first practically available (early 90's), UNIX before that, a variety of other OSs including UNIX derived NeXTSTEP, and I can genuinely say that Windows has many advantages and continues to do so.
Whilst part of the advantage comes from being the primary OS (for games, 96.76% market share on Steam), some comes from its feature set.
Most programs which work continue to do so (I have a 25 year old game I made, for which the installer and game still work).
@eniko Sadly some of my later games do not work well. We had workarounds for issues with some early DX drivers and these cause problems now. The OpenGL ones are fine though.
It's going to be interesting to see how Windows ARM pans out, and whether gamedevs targeting Windows now have another platform to worry about - considering changing our 'for Windows' info to 'for Windows x64' or something.
I recently did some work on improving the import/export of emissive materials in Avoyd to/from @ephtracy's .vox format and whilst doing so saw this interesting pattern during rendering.
I've not tried to reverse engineer the MagicaVoxel rendering (Avoyd uses standard unidirectional path tracing), but this has me intrigued as to the algorithm and whether it's been written about anywhere.
Note: voxel emission increases by a factor of 10 each voxel from top (darkest) to bottom (brightest).
@ephtracy's MagicaVoxel is an amazing tool - its ease of use reminds me of what Alex Evans (MM Dreams etc.) said about aspiring to make tools which were as intuitive to use as a pencil.