I recently got GLSL fog working in the RMQ engine, and since the RMQ engine has recieved shader code from DirectQ (ported to GLSL, and optional, of course) what better way to return the favour than doing fog in DirectQ?
OK, support is fairly limited at the moment as I've just implemented it with a static colour, static density and on world surfaces only as a test, but now that I've cracked the problem it's going to happen.
The bad news is that it's in the HLSL path only. As you might have guessed from previous posts, I don't have much interest in maintaining the non-HLSL path going forward, so consider this the first indication that it's becoming deprecated.
Direct3D doesn't emulate the old fixed-functionality fog on Shader Model 3 and upwards hardware (unlike OpenGL, which does), so there are practical reasons for doing it this way too.
Like a wise man once said:
...the cost of adding a feature isn't just the time it takes to code it. The cost also includes the addition of an obstacle to future expansion.I'll definitely get 1.8.666b out after I've got this done. It's been a long time coming, and the only reason I've been putting it off is pure laziness at this stage. I'm due a short break from RMQ anyway, so it's nice to spend some time on something else.
Sure, any given feature list can be implemented, given enough coding time. But in addition to coming out late, you will usually wind up with a codebase that is so fragile that new ideas that should be dead-simple wind up taking longer and longer to work into the tangled existing web.
The trick is to pick the features that don't fight each other. The problem is that the feature that you pass on will allways be SOMEONE's pet feature, and they will think you are cruel and uncaring, and say nasty things about you.
_____________________________
Update
Fog is now done. It looks good and doesn't slow things down at all.
Another problem - the timer has gone all jerky on me. This is most likely a result of my having (ab)used DirectQ for some experimental work before I wised up and got a dedicated experimental engine. I'll likely need to end up rolling back code to the previous version and then bringing on the important changes. Oh well, not that big a deal and it will mean things are more solid overall.
It's a pity though as getting this out is becoming important. I really really really want to start gutting the old legacy code and reworking some parts that recent experience has taught me a lot about. There's potential for this engine to go considerably faster and this old crap is genuinely holding things back right now.
_____________________________
Update 2
I replaced the screenshot.
Another bug; things get seriously jerky when r_wateralpha is set below 1. This one actually dates back to 1.8.666a; I just never caught it at the time (I rately use r_wateralpha).
I need to run some profiling I think.
5 comments:
That looks absolutely great! I am going to test some mods from QuakeWiki.net and fog will surely spice things up.
Weee, fog was one of my pet-features in DirectQ, will be nice to see it back ;)
What kind of fog is it? Darkplaces, Fitzquake, random glquake child with the usual ugly fog?
It would be nice if this was not yet another different looking fog implementation. Some people might like to set parameters for their maps that make it "perfect".
I decided to go with FitzQuake fog. Totally agreed that the world doesn't need yet another fugly implementation, and at least Fitz fog behaviour is what a lot of mappers (the Func_ crew) will expect.
Only difference is that it's per-pixel, of course, but otherwise it works the very same, "fog" command and all.
Sweet, Fitz's is good. Thanks!
Post a Comment