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.
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).
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.
The lightmaps aren't updated at all yet, so everything is static.
Figuring out how lightmap data gets to the gpu was a chore thanks to the
spaghetti in the bsp data, and then I'd forgotten that I was
pre-expanding the light data to rgb so wound up with weird lightmaps,
but without water or particles, demo1 is getting 5000fps at 800x450, and
it seems to be CPU limited.
Finally, quakeworld gets its *ahem* fancy skins. I'm not happy with how
skin loading is handled, but the whole model and skin support needs a
redesign.
Closes#74.
And further clean up skin api.
It turns out that skin functions must all be in the render libs, and
this results in Skin_Set (was Skin_SetSkin) needs to be accessed via a
function pointer rather than directly :(
This takes care of the double free and also cleans up a lot of the skin
api. However, the gl renderer lost top/bottom colors (for now). Vulkan
skins still don't work yet.
It should be much harder for a malicious server to crash the client
(there were a few holes in there still).
Also, set the fallback (server didn't specify) top/bottom colors to be
such that the default colors from the skin are used instead of white.
That is, those with more than 65520 vertices. Not properly supported for
sw or gl, and glsl isn't rendering properly for some reason (renderdoc
does see the meshes, though, so maybe depth or winding issues).
It was a right cow to get working at all due to the tangled mess of
dependencies between different hierarchies (switching to hierarchies as
components helpt), but other that some vertical positioning (paragraphs
and descenders), it's working fairly well now (and fairly quick other
than I think I need to ensure the shaping cache is used).
Some of them were actual leaks, but tracking memory should be a lot
easier now. However, there's a lot of room for optimization of
allocations (eg, recylcling of hierarchies. There is now 1 active
allocation (according to tracy) when nq exits: Qgetline's string buffer
(I think an api change is in order).
This makes it possible for hierarchies to clean themselves up (by
deleting their entities (though that will cause other problems later
when the hierarchy doesn't own the entities)), thus plugging a memory
leak when parsing passage text.
The main goal of this change was to make it easier to tell when a
hierarchy has been deleted, but as a side benefit, it got rid of the use
of PR_RESMAP. Also, it's easy to track the number of hierarchies.
Unfortunately, it showed how brittle the component side of the ECS is
(scene and canvas registries assumed their components were the first (no
long the case), thus the sweeping changes).
Centerprint doesn't work (but it hasn't for a while).
It's used for finding the entity that has the actual canvas component
attached. Useful for sharing a single canvas between multiple view
hierarchies, and worked as a proof of concept for doing similar with
hierarchy references, and might work for properly destroying canvas
items (fills etc) when a view entity is deleted (if attached to every
view).
This is for scroll boxes (the nesting of canvases is for the clipping
they provide). There are some issues with automatic layout, but this
gets things mostly working, in particular the management of the link
between hierarchies as a canvas is always the root of its hierarchy.
With the scroll box work I'm doing, I realized 16 bits is a little
cramped. Although I doubt it would be that much of a problem, switching
to 32 bits turned out to be free because of alignment.
