One of the really neat things about working on two different engines at once is that I get to try out many ideas in both, and cross-check how something works in one with the other. The net result is that something that's potentially new and dangerous becomes a lot safer and more robust.
So the whole FPS-independence thing is coming to a very satisfactory close. There are just a few edge-cases to work out, but overall it's working extremely well and completely glitch-free. Both RMQ and DirectQ now have it, with DirectQ being used as the trailblazer and RMQ being used to consolidate, confirm and cross-check.
One really good thing about it is that the code took a very unexpected turn and ended up being far far simpler than I had ever anticipated. In fact, on a first read it seems more or less identical to ID Quake; a few functions have been moved around, a few got an extra "frametime" parameter, and a few were split into two functions. But nothing totally earth-shattering came out of it.
MDL movement interpolation has also taken a strange turn - again in both. It turns out that the old QER code is - fundamentally - total bollocks for a lot of cases. I'm still using it for multiplayer games, but for single player I ended up scavenging some code from an early DarkPlaces that does movement interpolation on the server. This works a LOT cleaner and neater, and doesn't suffer from occasional timing glitches.
The by now mandatory "other news".
RMQ is getting IQM as an optional replacement for MDLs. Things have gotten to the stage where the limitations of MDL are becoming a serious factor, and something better is just flat-out needed. Thankfully a sane and sensible option is available, rather than a horrible monstrosity with everyone's favourite feature bolted on. Now if only similar was available for BSP...
DirectQ has gone through another evolution of it's particle system. Previously it used one of two modes - either with or without hardware geometry instancing. That's all been ripped apart and replaced by a much cleaner and simpler (and less CPU/bandwidth deficient) system. If you're familiar with the DirectX SDK Instancing Sample, it's option 2 - "Shader Instancing with Draw Call Batching". This gets particle submission down to a single vertex per-particle (instead of 4), runs on SM 2.0 hardware, and - in all of my tests - is a good deal faster than anything else when under load.
I've used a similar technique for controlling the view model interpolation, so it's no longer necessary to refill a dynamic vertex buffer with blendweights each frame. All small stuff in the performance stakes, but small stuff can add up.
Occlusion queries have come and gone again in DirectQ. I was considering them for RMQ as well, but they won't be used in either now. The simple fact is that I was optimizing for freak extreme conditions which ended up being slower in 99% of more common cases - sometimes much slower. Occlusion queries are really only of value when the effort required to just draw the thing is higher than the overhead from issuing queries, drawing bounding boxes and collecting results. You also need to have most of the objects in your scene actually occluded for them to work right - otherwise you're expending extra effort just to get back a "yeah, draw this object anyway" result.
I'm still slightly intrigued by the possibility of using them as a replacement for PVS, but that of course is only valid on the client. The server still needs it's own PVS and you can't replace that with renderer code.
Finally, both engines have now got ultra-smooth player movement. There's always been some low-level grittiness or jerkiness in Quake's player movement, which has been completely eradicated. It's now even possible to run at the standard 72 FPS and not get even a single jerk, but combined with the FPS-independent stuff, if you want to go faster for whatever reason (to match your monitor's refresh rate, say) you can.
Over the next short while, implementing IQM is going to be my primary thing, so I'll probably write some on that soon-ish.
Thursday, May 26, 2011
Updates - 26th May 2011
Posted by
mhquake
at
12:47 AM
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment