ZDoom

I guess that happens if you work with a 'space optimized' data structure and don't subconsciously want to whack it. :mrgreen:

Actually you changed it to short in a commit from 01/07/17 (widened ttl variable in particle_t to short to allow longer living particles than 6 seconds), before it was a BYTE. :) I've left it as pending for now BTW.

I wonder how many other such 'shorts' still exist in ZDoom. This was a very unfortunate consequence of typical 90's space saving methods.

How can I say no to a man in a santa hat with a candy cane? :P

Thank you for this.

Yep. Both my suspicion based on Lud's accurate count, as well as _mental_ were right.

In particle_t, ttl is a short - so that's why particle lifespans were .... "short". I'm hoping it's just as [url=https://github.com/coelckers/gzdoom/commit/29d2d8b3f864bc4219504af8af4a9afef05aefb8]simple as changing it to an int32_t[/url] - but I need something to test with to confirm this. (Nothing broke when I changed it, so I figured it safe to commit to master)

Maximum number of simultaneously active particles is controlled by [b]r_maxparticles[/b] CVAR.
But this limit has nothing to do with their time to live. It’s stored in [b]short[/b] variable indeed.

I don't know, Major Cooke, I'd have to look into that, but I will say this - if that were the case I doubt he'd come to such an exact number.

Come to think of it, aren't those particles removed similarly to the corpse queue when the threshold is reached?

Currently the particle lifetime will overflow if you put in any number larger than 32768. The reason why I'm requesting this is that I'm using some long-lived particles for effects and 15 minutes is definitely not enough. A workaround would be to spam 1-tic-lifetime particles every tic, which I find quite a bad idea when there's 50 actors that do it.