Been a while since the last update but I have been working away behind the scenes on a few things, just tuning and optimizing more parts of the engine.
There is a change in the visual appearance of the particle dot, which has now moved from being a resource embedded in the engine to being a procedurally generated texture. It's not generated in the shader, but rather in engine code; all the same it does mean that you can now control it's quality level (although in practice there's no performance gain from using a lower level, so it's for visual preference only) via the r_particlequality cvar.
Particle transforms have moved entirely to the GPU (which was very nice to do) and performance is up overall.
Likewise the underwater warp texture has made a similar move to a procedurally generated texture and can be controlled with r_waterquality. This texture is also used for controlling regular water warps, so I felt justified in using the same name as FitzQuake uses. I've also chosen the same default value for this as Fitz for better engine cohabitation. In this case there is actually no quality gain from chooing a higher value, and I recommend that you just leave it at the default.
Dynamic light updates have been improved with better lighting falloff and faster updating in general; the lighting model looks a little different to GLQuake now, but overall I think it's better.
Brush surfaces have also been changed a little with better vertex buffer locking/unlocking behaviour; there's still huge room for performance improvements with this code, but it is getting better all the time. I'm currently debating what to do with the old gl_keeptjunctions cvar; this was present but did nothing in previous versions, but I've now restored the behaviour. In case you don't know what it does, setting it to 0 (GLQuake's default) will remove some vertexes from surfaces, which gives higher performance but at the expense of the occasional blinking pixel onscreen. I've tested a few heavy scenes and can confirm that it can make things go up to 20% faster (typical scenes will be lower, of course), but is the visual tradeoff worth it? So what should the default be? You decide.
Finally, and now that it seems that on-the-fly window resizing is stable, I've added two cvars - d3d_width and d3d_height - to save out the new sizes. The reason why these are "d3d_" and not "vid_" is the same reason why I chose "d3d_mode" instead of "vid_mode" - these cvars with Direct3D don't coexist peacefully with OpenGL engines. I'll probably also add cvars for saving out the window position too - right now all I do is just center the window onscreen whenever a mode change happens.
So with all of that I'm considering a breaking change to video startup. The current mode list is divided in two, with approx the first half being windowed modes and the second half being fullscreen. Under the new way I'm planning, mode 0 will be the only windowed mode and the d3d_width and d3d_height cvars will control it's size; modes 1 and above will be the fullscreen modes. This will actually roughly realign DirectQ with the way GLQuake handled it, and it's also attractive because I can provide arbitrarily sized windowed modes in the menu, so it's fairly definite that I'm going to do it, but the only question is; do I do it now or do I wait until after the next release?
Saturday, May 14, 2011
DirectQ Update - 14th May 2011
Posted by
mhquake
at
8:39 PM
Subscribe to:
Post Comments (Atom)
3 comments:
"Procedurally generated texture"? Is that like those crazy 64kb demos; you run them and they seem to have all these great textures and effects, but there's no external files. Everything is in the demo exe and there are no textures or anything at all, just the -code- needed to create them! See the "product" demo by farb rausch for what I'm talking about, if you don't know.
That's it, but in this case it's not giant textures, it's just a 32x32 circle. :)
"...gl_keeptjunctions... So what should the default be? You decide."
I'd say go for quality with the default setting.. If someone really needs that extra bit of performance, it is probably time to upgrade their PC anyways.. I mean, this is quake we are talking about (and the fastest client to date at that).. any PC younger then 5 years old should run it with ease.. besides.. since the baseline is DX 9.0c compatible hardware, performance should not really be an issue..
Post a Comment