Tuesday, December 22, 2009

Speeds Up Again

The earlier version of the SDK seems to run more efficiently with the way DirectQ is coded, so there's a few extra frames from using it. I'm not quite certain what causes it, but I strongly suspect it's the D3D9 shader compiler in the earlier version vs the D3D10 (even on XP) shader compiler in recent versions.

Sky has just gone in to the new rendering framework, which is increasingly turning out to be very nice indeed. DirectQ can now properly handle sky surfs on ammo boxes, including proper depth clipping for non-hlsl modes (which includes sky boxes).

I can think of at least one situation where this might be useful, which is a sky room entity stored as a BSP model. Done well on the QC side you could in theory have changing skies in a single map. This is one for mappers and modders to explore if they want.

A report of slowdowns in certain busy scenes and I'm almost certain that this is particles. The DirectQ particle engine is fairly well optimized, but I've completely removed the upper limit on the number of particles. You could throw 100,000 particles at it and it will quite happily set them up and render them - slowly, but happily. ID Quake only lets you have 2,048 particles on-screen at any time, and I think I'm going to add a cl_maxparticles cvar to let you have some control over this. For comparison, of the ID demos, demo1 is the particle monster (yes, I've counted the number of particles in each demo) and it tops out at less than 4,000.

This is one situation where more widespread availability of D3D10 and geometry shaders would have been great, as particles - being totally dynamic - need to send quite a lot of data to the GPU each frame. In fact, of the entire scene, it's perfectly possible for the overhead from particles to be a number of times higher than everything else combined.

I have a totally crazy idea brewing in the back of my mind that, if I can pull it off, might just turn out to be something of a Holy Grail for Quake engine games. Right now I haven't even written any exploratory code, never mind proof of concept or production quality, so I'm not willing to go into much detail for fear that I might generate some false expectations (it might not even turn out to be that big a deal, depending on how it works in practice).

Imagine huge outdoor scenes with massive draw distances but no real slow down. That's what I'm hoping to aim towards. Even if I do start coding something I don't think it's likely to be a 1.8 feature; but - depending on how it goes - it could happen soon-ish.

6 comments:

=peg= said...

A cl_maxparticles cvar sounds good to me! I am fairly convinced particles are the cause of the slowdowns too (well either that or sounds). Here is a screenshot of DQ1.7.666c running happily at 500 fps, and here is another one with loads of particles (and sounds) where it crawls down to sub 30 fps..

The particles DO look sweet tho :D

Can't wait to check out 1.8 ;)

mhquake said...

There's not too much I can do about that I'm afraid. What you have is a scene with lots of alpha blending and overdraw over most of the framebuffer, so it's always going to be slow. Not a DirectQ bug or problem, just the way 3D rendering works. :(

=peg= said...

Hmm, well, doing that in glpro does not slow it down at all..
(but then again, it does not look as good either ;)

mhquake said...

This isn't GLPro. ;)

GLPro just does particles the exact same way as Quake, which is an 8x8 texture rendered on a single triangle. DirectQ does a 16x16 texture rendered on a Quad. Big difference.

I'm willing to bet that QRack, DarkPlaces and other engines have the same symptoms if you ran them with their non-standard particles on.

=peg= said...

You are correct, this is qrack:
no_particles vs lotsa_particles ;)

mhquake said...

I'm gonna be reworking particles a bit for 1.8 anyway. So far everything I've done has produced a speed-up, so hopefully this will too.