Saturday, April 2, 2011

...Don't Even Bother Doing It...

OK, release is being held back to try catch some last minute minor bugs, so in the meantime here's a brief list of things that there's no point in bothering doing with DirectQ.

-heapsize

It has no effect. DirectQ's memory manager is completely rewritten and it will use as much (or as little) heap as it needs, up to a maximum of 512 MB. That doesn't mean that DirectQ uses 512 MB memory all the time when running. If the current map only needs 10 MB then only 10 MB will be actually used.

Note that DirectQ is much more efficient than GLQuake with it's memory usage, so the amount of heap memory it needs is probably between about half and three quarters that of GLQuake, depending on content.

-particles

DirectQ has no effective particle limit and setting -particles has no effect at all.

-bpp 32

Again, DirectQ is not GLQuake. If you're running a 32 bpp desktop then you'll get a 32 bpp video mode so you only need this if - for some bizarre reason - you're actually running a 16 bpp desktop.

r_speeds counts

These are almost completely irrelevant. I've amended the counters to provide some more useful and relevant information, but the old wpoly and (especially with the upcoming version) epoly counts don't mean much any more.

For wpoly counts, the number of draw calls needed (and each draw call more or less represents a texture change) is far more important. Traversal of a deep and complex BSP tree will be what hurts you more on the CPU side. If lots and lots of entities are on-screen, QC overhead will be more likely to be your bottleneck. But poly counts? Forget about them, they're not much of a meaningful metric.

epoly counts are even more meaningless. MDLs are completely stored in GPU memory with all operations (interpolation, lighting) being done on the GPU. Each MDL is - at most - one draw call. With instancing enabled multiple MDLs (up to 400) can be handled in a single call. Transfer of data from the CPU to the GPU only occurs with instancing (maybe 80 bytes per MDL) or with the view model (which needs a few blendweights to fix up muzzleflash interpolation).

0 comments: