Corpse queue-like particle limit option
Moderator: GZDoom Developers
- Major Cooke
- Posts: 8175
- Joined: Sun Jan 28, 2007 3:55 pm
- Preferred Pronouns: He/Him
- Location: QZDoom Maintenance Team
Corpse queue-like particle limit option
A nice feature would be an option to toggle particles being treated similarly to the corpse queue system where if there's already a full list of particles up against the limit, the oldest ones are destroyed to make way for the new ones.
Often times at lower particle settings I would find myself unable to spawn new particles because of a low limit that doesn't destroy the older particles, so I have to risk dragging my system down due to raising it.
So if enabled, the oldest particles are destroyed to make room for the new ones if the limit is already reached.
Often times at lower particle settings I would find myself unable to spawn new particles because of a low limit that doesn't destroy the older particles, so I have to risk dragging my system down due to raising it.
So if enabled, the oldest particles are destroyed to make room for the new ones if the limit is already reached.
Re: Corpse queue-like particle limit option
Bump for support. This would actually be helpful for maps that utilize particle effects. Hell, it would be helpful for a lot of stuff. If possible, it should be able to be forced via MAPINFO, perhaps.
- Major Cooke
- Posts: 8175
- Joined: Sun Jan 28, 2007 3:55 pm
- Preferred Pronouns: He/Him
- Location: QZDoom Maintenance Team
Re: Corpse queue-like particle limit option
Agreed, except for the mapinfo part. That's a questionable one. If anything, I'd see it as something enforcable like jumping and crouching -- being the player's choice ultimately but allowing the map to decide.
- Major Cooke
- Posts: 8175
- Joined: Sun Jan 28, 2007 3:55 pm
- Preferred Pronouns: He/Him
- Location: QZDoom Maintenance Team
Re: Corpse queue-like particle limit option
...I'm not even sure how the hell this thing works. I think this is better left to someone else who can handle it better.
- Matt
- Posts: 9696
- Joined: Sun Jan 04, 2004 5:37 pm
- Preferred Pronouns: They/Them
- Operating System Version (Optional): Debian Bullseye
- Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
- Contact:
Re: Corpse queue-like particle limit option
Seeing as this is a purely aesthetic/interface matter I am in favour of such a thing being determined by the user.
That said, what would the consequences be of having no particle cap at all?
That said, what would the consequences be of having no particle cap at all?
- Major Cooke
- Posts: 8175
- Joined: Sun Jan 28, 2007 3:55 pm
- Preferred Pronouns: He/Him
- Location: QZDoom Maintenance Team
Re: Corpse queue-like particle limit option
Ever tried spawning 65535 particles before? I have. Turns FPS to SPF. A fuckin' crawl. And those didn't even move.
Re: Corpse queue-like particle limit option
Few things that I've already mentioned in private talk with Cooke, but think they should be expressed here as well.
Currently (where "-" are particles that aren't drawn in case of too many, and "=" are particles that get to drawing):After Cooke's suggestion:
Whereas particles visible to the player might look like this (spread in the list as "#"):
Since there is no relation between where these particles are and how old they are, it will lead to the same issue — if many particles are spawned in a single frame, you end up with them flickering/being deleted/being not visible at all (if many 1 tic particles are spawned for a complex animation like this).
With corpse queue this works only because corpses are created by the player, and normally somewhere near player's current location.
What makes more sense with limits like this one is:
1) don't spawn particles that have <35tic lifetime if they are not visible from the camera (assume 360 fov)
2) if particle overflow happens with visible particles, delete not the oldest, but the farthest or currently invisible particles first, or prefer particles with <0.5 alpha and nonzero fade (that is particles that ARE fading and are close to their death).
The complex part here is visibility check that should account for literally everything:
Graf, with his "we might eventually move all rendering to GPU including visibility checking and camtex rendering" will probably be against this.
Currently (where "-" are particles that aren't drawn in case of too many, and "=" are particles that get to drawing):
Code: Select all
|===|--------------|
Code: Select all
|--------------|===|
Code: Select all
|#---###---#-###---|
With corpse queue this works only because corpses are created by the player, and normally somewhere near player's current location.
What makes more sense with limits like this one is:
1) don't spawn particles that have <35tic lifetime if they are not visible from the camera (assume 360 fov)
2) if particle overflow happens with visible particles, delete not the oldest, but the farthest or currently invisible particles first, or prefer particles with <0.5 alpha and nonzero fade (that is particles that ARE fading and are close to their death).
The complex part here is visibility check that should account for literally everything:
- skyboxes
- portals
- cameratextures
- F12
Graf, with his "we might eventually move all rendering to GPU including visibility checking and camtex rendering" will probably be against this.
Re: Corpse queue-like particle limit option
As long as particles have no effect on the game sim, I doubt that Graf will be against it. You already have particles refusing to spawn based on a client-settable setting, anyhow, and that does not affect game sync. This isn't even hacky. (What's hacky is when the same principle is applied to actors, when actor lists should, in fact, be exactly the same on all systems regardless of how they are rendered)
Re: Corpse queue-like particle limit option
If the renderer is used, then the visibility checking can be generalized to the list of sectors drawn in the last frame, which is easily done by using an approach similar to validcount (sector_t::drawtime==level.time) to avoid generating an actual list.
Then, either way, a particle that's about to spawn will find the sector that it's going to belong to (even without this system it's already doing it), and if this sector wasn't drawn, just don't spawn it.
The only real issue that I see with this approach is when people spawn particles and expect them to spawn reliably and instantly.
For this, I'd suggest to set the default global cap to 65536 as opposed to 1000 or 4000, but also have two flags:
Then, either way, a particle that's about to spawn will find the sector that it's going to belong to (even without this system it's already doing it), and if this sector wasn't drawn, just don't spawn it.
The only real issue that I see with this approach is when people spawn particles and expect them to spawn reliably and instantly.
For this, I'd suggest to set the default global cap to 65536 as opposed to 1000 or 4000, but also have two flags:
- ALWAYSSPAWN: spawn particle even if it should be blocked by this system
- ALWAYSOPTIMIZE: optimize particle even if it has longer lifetimes (for e.g. particle foutains)
- Major Cooke
- Posts: 8175
- Joined: Sun Jan 28, 2007 3:55 pm
- Preferred Pronouns: He/Him
- Location: QZDoom Maintenance Team
Re: Corpse queue-like particle limit option
Unfortunately that's quite a bit over me at this point. My attempts have flopped terribly due to utter confusion on how to get this working since Randi coded this thing with pointer arithmetic...
Re: Corpse queue-like particle limit option
Pointer arithmetic is easy as long as you know how many bytes each structure is and you have the structure definition in-hand.