Time for a Coffee! - KRLV
It has been requested several times over the years, and I have now officially started work on an RLV implementation for S24. As with most things I do, however, there is a distinct KL twist involved.
One of my long-standing concerns with existing RLV implementations has been the way the API integrates into the viewer. In an environment where performance matters and every microsecond counts, some of the traditional approaches never sat particularly well with me.
For that reason, KRLV, the delightfully unimaginative working title, is being developed as a completely clean-room implementation. No code has been taken from any existing RLV project. The only reference material being used is the publicly documented RLVa command specification. Everything else is being designed from the ground up.
By my current estimate there are somewhere in the region of 180 individual behaviours and restrictions to support, although that number will undoubtedly move around as development progresses.
One of the first architectural decisions concerned state management. KRLV maintains its restriction state through a persistent state store that is loaded during viewer startup and validated before being accepted into memory. The implementation includes a number of integrity checks designed to detect unexpected state corruption or modification, while still respecting the fundamental principle that users ultimately retain control over their own systems.
Perhaps the biggest departure from traditional implementations is the absence of the classichecks scattered throughout the codebase.
eg:
if (rlv)
{
Instead, everything is treated as state. The actual integration points within the viewer are intentionally few in number and generally feature very aggressive early-outs.
A simplified example would look something like this:
KRLV enabled → Validate persistent state → World Map restriction active → Close World Map floater on the next frame regardless of how it was opened → Record diagnostic event.
The goal is to allow hundreds of active restriction states to be managed efficiently while keeping the impact on the render and interaction paths as close to negligible as possible.
Naturally, not every restriction can be handled this way, but where hooks are required they are being designed to remain minimal, predictable, and easy to reason about.
The advantage of approaching the problem with a clean-room design is that I am not inheriting historical assumptions, legacy decisions, or implementation baggage from previous projects. Whether that proves to be brilliance or madness remains to be seen, but I am hopeful it will lead to a tighter, cleaner, and more secure implementation.
Assuming no major showstoppers emerge, I currently expect KRLV to debut alongside Alpha 1.4 or Beta 1.0.
Apologies for the lengthy post. I simply wanted to let everyone know that this project has officially moved from paper and diagrams into active development.
Much love and respect,
KL
Comments
Post a Comment