Particles shut off shortly after level start (at least in Boomsky megawad) in Doom
When playing Boomsky in most levels, the particles mostly disappear and even shut off after about a half minute after the level starts. Strangely, when I quickly save and load, they briefly appear again, but after about 30 seconds, even when no particles are being given off, I notice they disappear when firing a gun or blood is spilt.
I tried the latest stable (1.13.2) and this doesn't seem to be an issue, but with 1.14 unstables, it is a problem. However when trying the previous stable 1.13.2, I do notice that blowing up a toxic barrel doesn't leave pieces behind, though it does in the recent unstables if the particles don't shut off. Quickly saving and loading restores the particles for a little while, but not for long.
here is a pic of my addons: http://i.imgur.com/eTGFoDX.jpg
Boomsky an be found here 3rd one down in alphabetical order: http://edsdoomsite.tripod.com/id11.html
Fixed|Renderer|Particles: Particle generators disappear unexpectedly
A classic confusion between 1-based and 0-based indexing.
#1 Updated by vermil almost 7 years ago
I would like to state that I have noticed an issue similar to this with one of my old mods that only features a very small handful of, admittedly inefficient, state based generators. While playing it in the latest unstable builds, all generators sometimes very quickly shut off and I don't think the number of active generators was anywhere near 512 in spite of their inefficiency.
DaniJ co-incidentally has a copy of the mod in question, to explain why I am not attaching it to this report.
To go off topic a little, it might actually be a cool feature if Dday were to have some sort of console command or dynamic counter a user could display on screen, that displays the number of active generators, for as long as Dday has a generator limit (by which I mean for as long as the limit isn't raised to something like 63553 etc etc). I am assuming that Dday doesn't already have such a feature of course (I'm not aware of it having such)?
#4 Updated by vermil almost 7 years ago
A visual display of active generators has its place, but all it tells the typical user is that they have turned off, with no indication why and that is why I made the suggestion of a counter (admittedly, here is the wrong place to make that suggestion and I should have made an RFE for it, but I got carried away writing, as I do).
Dday has never given any indication to the user, that the active generator limit has overrun (i.e no message was ever logged in the out file when it occurs).
Thus, over the years, IIRC, users who experience the limit overrunning come to the forums asking things like 'why has/does the blood turned/turn off' (i.e these users will naturally not know what a generator is).
An in game message saying the limit has been breached would be the perfect use of Dday's new error logger and help the user understand Dday a little more (i.e at the most simple level that the blood comes from something called a generator).
A dynamic counter would be a useful debug aid on top of this; when the generators turn off, a user (or a modder making a map that uses a lot of generators) will then be able to reload the map with the counter on to retest the scenario. They will also then be able to see if the generators turned off due to the limit being overran or whether they have stumbled across a bug of some sort.
For instance, I currently believe my above mentioned mod is breaking the generator system, rather than breaching the active limit (Gary's original report also suggests something is broken). But we have no way of knowing for sure and I’m sure Deng Team would prefer not to be told there is a bug in the generator system and spend time looking at it, only to find out that it’s actually just a case of the generator limit being over-ran?
#5 Updated by Gary almost 7 years ago
Getting rid of that limit could also help. Dani talks about ho that would require rewriting the whole system from the ground up. Yet on the FreeSpace (a space simulator) Open source code, they just add a string of code to get rid of the limit and set it higher. I think Boomsky is a bug; not a problem with the limit. If you try the last stable (1.13.2), most particles, save from the barrel debris, seem to stick around. On Boomsky with 1.14, they don't take long to shut off on all levels. Too bad one can't force them to stay on because it makes me PO'd when they do that.
#6 Updated by danij almost 7 years ago
Allow me to clarify a couple of points:
Firstly, I completely agree with your reasoning, Vermil, as to why a total count of the number of particle generators would be useful. I was simply pointing out that a debug display (of sorts) does already exist.
My point about the particle generator system needing a complete rewrite was not so that we can increase the limit. I did not say that, Gary. What I did say was that simply bumping up the limit (yet again) won't solve the fundamental issue of the particle system not leveraging the GPU, which, is the primary reason for the existence of the low fixed limits.
There may well be a bug in the generator/particle management. However, we've just found and fixed a game timing issue which might have some effect on this.
#7 Updated by danij almost 7 years ago
Judging from the various user reports on this issue it is now pretty clear that some change after 1.12 stable has resulted in the particle generators behaving as described above.
While it is indeed expected behavior that they shut off when too many are spawned, it would appear that a bug somewhere is leading to premature generator shut down.
#9 Updated by skyjake almost 7 years ago
- Tags set to Particles, Renderer
- Category set to Defect
- Status changed from New to Resolved
- Assignee set to skyjake
- Priority changed from Normal to High
- Target version set to 1.14.1
- % Done changed from 0 to 100
This was caused by mismanagement of particle generator IDs.