Shadows, fog and the Half Life texture palette are the only real items that remain outstanding in terms of the 1.7.x feature set. I'm working pretty flat out to get this ready for release and hope to have the first two of those items completed shortly.
To be honest I couldn't really care too much about the Half Life palette at the moment. If I heard that a mod team were working on a release that used the Half Life BSP format I could turn it around quickly enough, but until then it remains a novelty feature that's good for tech demos but not much else.
I'm of the opinion that if one was to look for an extended map format to either replace or complement Q1 BSP, Q2 or Q3A BSP are much better choices. Areaportals, light grid, lots of niggles with Q1 BSP resolved, GPL loading and rendering code - all nice. HL BSP just inherits far too much baggage and doesn't seem enough of a step forward to warrant much investment - until such a time as it's used in the Real World, of course.
Back to DirectQ. I've also started moving certain allocations I had put into my permanent memory buffer over to flexible dynamic per-map buffers. Temporary entities were the first to move across, and the max number has now increased from 512 to 21,845. Others will follow, with similar increases (I have over 1GB of address space to play with here), but I don't know if I'll get any more done for the first release. The really nice thing here is that despite the stupidly large maximum, DirectQ will only use as much memory as it actually needs, on a per-map basis.
The ability to switch hardware T&L on and off has also been added. If you have a GPU that has barely sufficient capabilities to run the Aero desktop but not much else you might get a performance boost from doing your T&L in software. This can be done at any time and doesn't need a video restart. vid_hardwaretandl is the cvar, and it's also in the Video menu.
The "directq.cfg" file thing I talked about earlier has been added and the startup sequence is now default/config/directq/autoexec, with changes written to directq.cfg on shutdown. This should help DirectQ play nicer with other engines living in the same folder as it; now it won't stomp over their config settings and they won't stomp over it's.
I've been struggling to get better performance out of the ne_tower map, but those torches are killing me every time. The ones used are exceedingly complex models that don't optimize to an indexed mesh very well, and are scattered all over the place - over 20 of them in many scenes. There's one particularly brutal scene at the very bottom of the tower where if you look up and around your framerates will plummet, and it's entirely down to those torches - removing static entities from the render prevents it.
I'm going to console myself that I can't at present optimize for extreme cases, and the fact that I still manage a decent 35-45 FPS in this scene (other engines get 10ish, one engine drops to 1!) is enough of an accomplishment for now. I may well come back to it and hit it with occlusion queries at some point in time, but it would be a shame to have what I think is a "cop out" solution that won't work on all hardware.
Sunday, January 10, 2010
More 1.8.0 Updates
Posted by
mhquake
at
1:09 AM
Subscribe to:
Post Comments (Atom)
2 comments:
I remember what you were doing with the old MHQuake; how you had support for running Quake One maps in a new Quake Two-style engine, and it looked amazing, but wasn't playable; you could load up the maps and look around in them but that was all. You should add support for playing the Quake II maps in DirectQ, so you (and We, the players) have one engine that can run both 'Quakes.'
Nice idea but not yet! Right now the absolute top priority is to get this current work done and out the door, then fix bugs in it.
Post a Comment