There's still a lot of work needed to separate out quake from
quakeforge, but this lets my test scene get a rather mangled scene
rendering (weird translucency: not sure what I've done wrong: probably
bad clear).
It turns out what I thought was a cascade selection bug was just very
bad choice of cascade steps: factors of 8 just don't work nicely. I'm
not sure that simple factors work all that well, either. I need to make
the cascade system configurable and probably support more cascades.
This puts pixels that have not been rendered at infinity. I was rather
surprised to see fog in my test scene, but it depended on my position
relative to the origin, so something was definitely off (the pixels were
at the origin).
I'm not sure why the final range was only a factor of 4 instead of 8.
There are still issues with range selection, but I'll look into them in
a bit (flying around my little test scene really shows the problems).
IN_UpdateAxis (for nice handling of axis updates, especially relative
motion for mice) and IN_Binding_HandleEvent because registering an event
handler blocks qwaq's internall call to IN_Binding_HandleEvent.
With this, it is a little easier to make qwaq independent of quake. The
default dirconf is still meant for quake, and fs_dirconf can still be
used to override the configuration.
While every possible subsystem needs an initialization call, all that
does is add the actual initialization task to the render graph system.
This allows the render graph to be fully configurable, initializing only
those subsystems that the graph needs.
Scripted initialization is still separated from startup as render graph
creation needs various resources (eg, attachments) defined before
creating render and compute passes, but all those need to be created
before the subsystems can actually start up.
Finally. However, it has effect only when no render config is provided.
When a config is provided, things will break currently as nothing is
done yet, but getting a config in will take some work in qwaq and also
the render graph system as I want to make the startup functions
configurable.
The config is a pre-parsed property list. Currently unsupported by
anything but Vulkan (but only a warning is given, not a hard error at
this stage), and Vulkan doesn't use it yet.
Now, if either ormask is set or the first character of the string to be
printed is 1-3, the quake character set is used, otherwise utf-8 is
assumed. Other changes are for mapping untrusted strings.
Even the comment says it's 8.8, so no need for 32 bits for each value.
It seems to have made a very small improvement to my glsl stub test, but
it's probably just noise (< 0.5%). However, having it "officially" 16
bits means that cached values can be 16 bits thus reducing struct sizes
when I rework lightmap surface data (taking the cache from 16 to 8
bytes).
I had gotten confused about how dynamic lights were calculated and thus
used the wrong radius in the final intensity calculation. Takes care of
the scruffy corners often visible on the dynamic lights.
This gets dynamic lights working again (well, minus the bad updates, I
need to figure out what's up there, but they're nothing new). I guess I
checked only for things running, not that dynamic lights worked.
And clean up the resulting errors. While some were tricky, there weren't
all that many: just some attachment issues and the multi-stage image
copy for scraps.
Fixing scraps required a barrier between copies. It might be overkill,
but a transfer_dst to transfer_dst image barrier worked.
Fixing attachments was a bit trickier:
- depth needed early and late fragment tests to be treated as one stage
- all attachments that were read later needed storeOp = none (using the
extension)
- and then finalLayout needed to be correct to avoid ghost transitions
- as well, for some reason the deffered gbuffer subpass needed a depth
dependency on the translucent pass even though neither one writes to
the depth attachment (possibly a validation bug, needs more
investigation).
It's not perfect (double fog on translucent surfaces, the
scatter/absorption isn't right, and no local lighting on the fog
itself), but it at least seems to look ok.
I think has been one of the biggest roadblocks to breaking free of
quake, so having dual render paths and thus the different new scene load
sequence has proven to be unexpected helpful. There's a lot more to be
done to make the render graph actually usable by anyone but me, but just
making scene load configurable frees up a lot. I think there needs to be
renderer startup/shutdown configuration too, but this seems to be enough
for now.
Other than decoupled lightmap support, I think that has the vulkan
forward renderer feature complete (though a little buggy with its
lightmap updates and fisheye gets validation errors).
It's just lightmap vs lighting (scene load and bsp rendering) and
compose (attachments or no) that need sorting out, and, of course, a way
to select between the two.
Missing any possibility for fullbrights or colors (only because no
attempt is made to load such), and more deferred breakage, but it acted
as a nice proof of concept for cleaner skin loading (taking advantage of
resources and QFV_PacketCopyImage).
QFV_PacketCopyImage is quite handy, but when used before
QFV_GenerateMipMaps, the final image barrier is not wanted as
QFV_GenerateMipMaps expects the image to be transfer_dst, so skip the
barrier if dstBarrier is null.
In a quake context, I suspect iqm models should use the same skin
concepts as alias models. I'll probably be proven wrong, but it should
make things nicer for now, especially with forward lighting. However,
Mr Fixit is too bright because the skin isn't set up correctly.
Deferred is getting more and more smashed, but I'll fix that up when
I've got forward "done".
The output framebuffers array is dynamic, so trying to index it before
it has been created results in a segfault (which is rather inconvenient
during shutdown).
