I'm not an expert, but in this case the discard would not account for translucent pixels, anti-aliasing on text or sprites, etc. If you were to include a p.a < 1.0 block the shader, it would need to account for blending modes and/or shaders that could change between the objects that are being rendered. All that can only ultimately be solved by rendering back-to-front.

I don't suggest making this as a default shader because this territory is where a graphics engine splits off into different solutions that very depending on the limitations/specs needed by the engine. For your Usagi engine, the shader is a great solution. It might even work well for Labyrinth of Lore, actually since at this time there were no "requirements" for translucent pixels in sprites (but there are requirements for different shaders on sprites 🤔).

Anyway, I did a little bit of research for this topic during the KrampusHack (due to a need for rendering billboarded sprites that also have transparent pixels). The general consensus seems to be that these faces should be rendered back-to-front of the camera, in a separate pass, which may seem a bit odd because it seems like that's what the depth buffer solves for in the first place. The technique ensures that "behind" pixels are rendered before they are potentially depth-checked against pixels that might be "in-front" that would otherwise block them from being rendered.

A similar technique is used in Labyrinth of Lore's "TileMapWaterMesh", which (will) render a transparent layer over the existing "TileMapMesh". The overlayed water mesh layer needs to be rendered separately, after the TileMapMesh, so as not to prevent the pixels from the TileMapMesh from being blocked out by the transparent layer.

In the case of ordering objects back-to-front, the technique should not a difficult one. Given a master list of in-world-entities:

std::vector<Entity::Base*> all_entities;

A collection is extracted, sorted and rendered. It might look like this:

// Billboarded sprites are picked out
std::vector<Entity::Base*> billboarded_sprites = Rendering::BillboardSelector(all_entities).select();

// Sprites are sorted using a dot-product distance function
std::vector<Entity::Base*> sorted_sprites = Rendering::DistanceToCameraSorter(camera, billboarded_sprites).sort();

// Render
for (auto &entity : sorted_sprites)
{
   Rendering::EntityRenderer(entity).render();
}

That's the sketch of what was planned for Labyrinth of Lore, but that feature was actually spec'd for after the hack, since the existing artifacts were negligible and no entity shaders were slotted for the hack version.

A common basic solution that most 3D engines do* is separating the materials into three categories: opaque, translucent and punch-through.

Opaque would be the first result you got (depth write on any pixel).
Punch-through would be your second result (write only pixels that are above a certain alpha threshold).
Translucent would be no depth writing whatsoever. This normally required careful placement from the artists and sorting from back to front.

Unless you have a really big number of entities, I'd recommend the sorting approach for a first implementation without a depth buffer altogether. You could speed it up with some better data structures considering the fixed perspective, but better tackle that later if it becomes a problem.

*: Without getting into order-independent transparency implementations, which are another different kind of headache you probably shouldn't get into yet.

That sounds about right. If you really wanted it to only be one sprite, you'd need its depth information in another channel/image at least combined with using the depth buffer. This is one approach I've used in the past (inspired by this guy's video), and I believe it is currently being used in Pillars of Eternity so the backgrounds (which tend to be a few large pre-rendered/painted over images) have occlusion with the 3D characters.

EDIT: How Pillars of Eternity's rendering works. You can see an example of the depth buffer information embedded into the background around the 1 minute mark.

I remember seeing in the Allegro source code that it really already supports 3 coordinates, so it is easily possible to add a feature that allows the use of the Z coordinate without using a transformation.

In the shader, you are able to access the depth buffer pixel value from the .a member (in the sense of "rgba") of the gl_FragCoord. You might use this to draw an image you could use to help you debug.

The "DepthDarken" shader in Labyrinth of Lore darkens the scene if it's further away from the camera. Essentially what's happening is the depth buffer is being drawn on top of scene (with some scaling and range capping), and it's intended to emulate light from a torch carried by the player. It looks like the image posted on the KrampusHack log:

{"name":"612300","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/b\/a\/bad4a64898e533fa00142dd877746d1f.jpg","w":960,"h":551,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/b\/a\/bad4a64898e533fa00142dd877746d1f"}

This file is the quintessence for that shader, highlighted is the fragment shader source: DepthDarken shader

Specifically, if you look at line 81, it shows pulling out depth_value from gl_FragCoord and then multiplying the fragment color for that pixel by that depth value, here.

The values contained in .a, though, I'm not sure what the ranges are. I think it could be 0..1, but in the example above I noticed some colors were blowing at "near" ranges, so it's possible the ranges could be something other than 0..1.