Sunday, December 28, 2008

Particles! And More!

No, it's not a new particle system, don't worry Trad Quake fans (although I must admit I'm quite fond of the old one).

Been doing some digging into particles while I've been removing the limit on the number of them you can have, and have come up with some interesting stats. Rounding up to the nearest multiple of 1024, what we get is:

  • demo1 has up to 4096 particles on the go at any one time.
  • demo2 has up to 2048 particles on the go at any one time.
  • demo3 has up to 3072 particles on the go at any one time.
This surprised me a little; I thought demo3 would have been the particle monster, but apparently not so. I'm also surprised to find out that 2 out of 3 of the stock ID1 demos exceed WinQuake's/GLQuake's internal particle limit.

Based on this I've revised my previous estimates and have chosen an initial allocation of 4096 particles, to be increased in batches of 2048 as required (I had assumed half of each would have been sufficient).

Particles are allocated on the Hunk and therefore cleared between maps, so if map A is a particle monster, map B won't suffer on account of it. I've written a Hunk_AllocFast to handle this, as it had always bothered me that the standard Hunk_Alloc/Hunk_AllocName did a memset to 0. Of course there are cases in Q1 where the code assumes that the data is 0 (the BSP loader is a biggie), but there are also cases where we know that an allocation is going to be filled with data immediately after, so the overhead of 2 passes through it seems excessive, particularly when it happens at runtime.

The upshot of all this is that there is a bit more particle activity in the engine than there used to be in Trad Quake (noticeable even on demo1), but it reflects the actual intentions of the particle system, unconstrained by limits.



Other news; I've been testing how well this engine copes with some of the "engine killer" maps out there. I don't have Quoth, so I haven't tried some of the more recent ones, but the two I have tried are The Marcher Fortress and CaveTest2. Happy to report that it's able to load both without any trouble. Marcher looks perfectly fine in it to me, although without the skybox it's just plain wrong (not this release, probably in the next). CaveTest2 loads, but performance is dreadful. I'm not too worried by that, It's supposed to be dreadful!

I've bumped quite a few internal limits to support this, and in many cases what I've done is just increase the size of static arrays - ugly as a box of frogs, a far more elegant solution would be dynamic allocation (up to the maximum allowed by the protocol in cases where something needs to cross a client/server boundary, or throw the protocol out the window in SP games), but that will have to come later.

0 comments: