I've been setting up my new render-to-texture framework, and have it working with the underwater warp the same as the old code did, but now with the ability to chain multiple effects. I haven't quite tested that last part yet, but will do so soon.
It needed some heavier refactoring throughout more of the codebase than I had initially planned, but I'm (mostly) happy with the result. As a first cut it's pretty good and any further changes will be for code-tidiness rather than functionality.
This of course opens the possibility of adding more effects - which will usually be of the optional-and-disabled-by-default variety - SSAO was one that was requested (not certain how easy that is in Quake without heavy rewriting elsewhere, but at least this obstacle is gone), heat-haze is definitely down for a good attempt now, and others are possible.
Things can slow down considerably as more such effects pile up, of course, but that's a normal side-effect and overall I do think that this kind of subtle-but-interesting effect is of more value with Quake than trying to beat on the data and model formats in order to get them to do things they were never designed to do. It's also a good use of the rendering muscle behind DirectQ.
One nice side effect of all this is that an old problem whereby the wrong render target would be cleared if gl_clear was set to 1 has been fixed up.
Another nasty bug was that when I first set it up it was running a lot slower than it should. That was odd as the extra framework code should be quite lightweight - the heavy work happens in the shaders (which are the very same as before). A quick bit of investigation soon revealed that the overlay screen tint was also being drawn - normally I add this to the waterwarp shader which lets me get it for free (almost) and relieves a LOT of the fillrate burden.
That was just a simple order-of-operation bug that didn't affect the old code but has become significant now. Put the offending function call in a better place and it goes away. A good example of the kind of traps that Quake's wackiness lays for you.
Thursday, July 5, 2012
A Scurrilous Bug Squashed
Subscribe to:
Post Comments (Atom)
3 comments:
Might be a good opportunity to experiment with the frame-stacking idea?
Garry's Mod recently added that, but with DirectQ's speed running Quake with true motion blur at 60 fps seems like a possibility.
http://garry.tv/post/23182356175/frame-blending
Frame stacking would work outside of this system, which is more set up for chaining multiple effects in a single frame.
I see that the Garry's mod version uses 16 frames, which would mean that you'd need to be averaging 1000fps to get an end result of 60. That's definitely achievable but I'd feel more comfortable with a 500fps average for big maps and heavy content.
The 64-bit render target that I feel you'd need frightens me a little. It's not something I'd want to automatically create for everyone on startup; it would need to be created and destroyed on demand and as the cvar to enable/disable this is toggled.
Otherwise a standard 32-bit RT would need a high number of texture samples per-present which would slow things down.
Probably will experiment with it at some point in time though, but not all the details have been worked out yet.
it simulates using 16 frames, yes.
but it discards 8 of those to simulate shutters being closed half the time or something.
which means that its only actually fps = frames/8 if you can simulate that effect some other way.
which it should be possible to do, by delaying angle changes and interpolation timedeltas until they can be consumed in bursts, which would give 60fps if your engine could pull a constant 480fps already (assuming you have infinite gpu power and are purely cpu bound).
some 10+10+10+2 rendertarget format would probably be sensible, yes, to avoid precision errors in your accumulation buffer.
Post a Comment