Or at least the "correctness" aspect of it will go. This is now definite.
Bottom-line: it's slowing down map loads, preventing me from reintegrating my renderers properly, and eating up a huge chunk of memory. At this point in time continuing to support the correctness element is going to cause a lot of ongoing grief for what is essentially a legacy mode.
I'll still be retaining a non-HLSL water mode however, and I'm going to ensure that the surfaces are at least not static (maybe something like what DarkPlaces does), but the time has come to jettison the difficult parts and get it working from the same data structures as the HLSL mode.
UPDATE
The deed is done.
Non-HLSL warps are now just a simple circling flat surface. It doesn't look too bad, so at least something is present for the non-HLSL folks.
This saves somewhere between 3MB and 6MB of memory per map, depending on the number of warp surfaces in them (and the sizes of those surfaces). As a really nice bonus it now goes through exactly the same render path as the HLSL warp, so we're finally starting to see some code integration here.
While experimenting with r_hlsl 0 mode here I noticed that I had managed to mess up the sky. I don't know if that made it into the alpha, but as I'm planning on keeping the non-HLSL sky for now (it doesn't mess things up nearly as bad as the warp did) I'm going to need to fix it.
Late-Breaking
It occurred to me after I posted this that anyone who may be annoyed by what I've just done deserves a bit more explanation. Everybody has their own pet features, and as there is only one of me I can't possibly do them all. A clean and stable code-base is my priority number 1, and implementing something involves a lot more than just writing the initial code. It needs to be maintained as time goes on, bugs that crop up in it need to be addressed, I need to ensure that it lives happily with the rest of the engine and that something else I do doesn't upset it (or that it doesn't upset something else I do).
All of this eats into my time. In the specific case of the non-HLSL warp it required a different vertex and surface format, so retaining full support for it effectively doubled my workload so far as water is concerned, and would have led to a situation in the future where it required it's own ongoing handling completely separate from everything else.
It had gotten to the point where it was no longer sustainable, basically. In order to move forward I would have needed to go back and rewrite all the other surface code to conform to the non-HLSL setup (the other way around wasn't possible).
This is called "diminishing returns", and something had to go.
If you're still annoyed at this, just think that now I'll be better able to re-integrate the surface refreshes, meaning more time available for those other features you'd like to see - time which would have otherwise been spent on maintaining the non-HLSL warp.
Wednesday, January 13, 2010
Non-HLSL Water Warp is going to go
Posted by
mhquake
at
8:21 PM
Subscribe to:
Post Comments (Atom)
1 comments:
That's actually not a big deal at all, but I could see where some might be annoyed.
Well done.
Post a Comment