It won't happen tomorrow (Tuesday) but it should happen Wednesday.
I've implemented a Q3A-alike shader system like I've been threatening to. OK, it doesn't parse .shader files (the parameters are hard-coded into the engine) and it doesn't support multiple passes, and is quite primitive really, but the guts of the support is there and running well (and fast). It's quite a bit more flexible than my old VBO framework too. Right now it's got solid surfaces, alias models and shadows in it, but it needs a little massaging before I can start putting other stuff in.
I've also heavily optimized the vertex submission. This isn't actually a bottleneck in Quake (and especially not in DirectQ), but I view this optimization as providing headroom for possible future work that may take it back down again.
A nice result with shadows - switching them on hardly even slows things down at all. There's an awful lot of good things to be said for batching states and primitives. This performance boost has started me thinking about shadow volumes, and I've done some preliminary reading. I'm not certain if I'll even code them yet but it would be interesting to get a demo app up and running. If I do they would likely be a HLSL-only feature. I've not too much interest in fooling around with multiple render paths.
Up next I want to see if I can fine-tune occlusion queries. Some tests indicate that they're flip-flopping between rendering everything and working correctly every few frames, so I need to see if I can figure what's causing that. This is a pre-1.8.3 job and is the main reason why it won't be released until Wednesday.
I also need to test alpha support with my shaders and tidy up a few small things, but otherwise it's pretty much there.
In other news, I've been fooling around with a version of Aguirre's Engine (mentioned one post back, link there). This is just distracting experimental work, and is purely as a test bed for some ideas - no release here. The objective is to see if I can get it into a state that makes it a more useful engine for actually playing Quake with, and the work mostly involves moving a lot of the big static arrays in it to fully dynamic allocation. I'm also seeing if I can bring a limited OpenGL version of DirectQ's renderer onto it. It's a learning exercise for me rather than anything else, and good fun to just be able to hack and slash at code without worrying about consequences.
Some of what I do here might make it into DirectQ. Some code from my WinQuake experiments has already done so (in a very roundabout way and in a completely different part of the engine), so it's not impossible.
Tuesday, April 13, 2010
Release 1.8.3 is Imminent
Posted by
mhquake
at
12:29 AM
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment