#graphics programming

The reason we don't do it is because our eyeballs perceive things in perspective, not orthogonal projection. The believability of a perspective projection is much higher for the same reason that games feature humans and humanoid characters - it's what we're used to and comfortable with. A constant orthogonally projected view would get really weird after a while.

The closest we get to true orthographic projected cameras is in the isometric 2D sprite-based games like Sim City, where we didn't actually do 3D rendering, so a perspective view was impossible. It looks fine in a stylized visualization, but seeing it more realistically rendered would cause a sense of unease in the viewer, due to the expectation of a perspective view.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Short questions: Ask a Game Dev on BlueSky

Long questions: Ask a Game Dev on Tumblr

I contributed a 9000 word article about making this effect! note you will need a browser with WebGPU, and for reasons I don't quite understand, I get bad performance hitches on Firefox, so unfortunately it works best in Chrome. native version can be compiled from the source here

It's about divergence-free fields, and writing cross-platform compute shader programs using Rust and wgpu! If those sound like things that might interest you, give it a read :3

Last weekend I released my first demo "CorpseTravel" for Raspberry Pi Pico 2 at the demoparty Xenium.

A few weeks ago I decided I am fed up with the current state of things particularly in the demoscene (but also a bit in game development) when it comes to using a prepackaged engine versus people knowing or learning how to use their own thing, so I put together a quick tutorial for how to write the beginnings of a framework that renders a mesh and plays some music - it took less than 400 lines of C++ and about 40 steps.

Bodies with atmospheres using scatterance, absorption, and emission in my space sim/game. Solid surfaces are drawn first, then the volumetric atmospheres. Also shown is a multicoloured galaxy (from the inside) using the same thing with its glowing dust, with extinction (scatterance and absorption's combined dimming effect) also applied to the stars which are additively blended in. Their transmittances (the remaining luminance after extinction occurs) are calculated in a compute shader. The galaxy's sampling function could be made a lot more realistic (though I did give it spiral arms!), and some dark nebulae would be good to really showcase the fact that I actually added realistic volumetrics.

OpenGL = Portal Vulkan = Portal 2

I'm once again playing with dragon curve shaders, this time with a unity implementation. Friendly reminder this is an entirely parallelized gpu implementation, something which is not an easy task to derive!

We've made some serious optimizations this time with our newfound number theory interpretation, though it cant handle as large of numbers as my old matrix multiplication interpretation, because I haven't hard-coded the higher precision types. Still this should be able to handle ~31 iteration dragon curves, and it will do so re-generating it in real time. I've yet to profile it but Just looking at the code it should be much cleaner.

In fact, I can fit the fragment shader and Dragon method into a single screenshot, and look at how clean it looks! Granted we're missing some bells and whistles from the old version, but I'm still happy with this. The only new math I haven't posted about before here is the way I'm shading the curve itself.