SpriteParticle Class

[Major Cooke]

I can't remember if something like this was suggested before.

One thing I think we could benefit from is having an official SpriteParticle class, or SpriteEffect, whichever you want to call it. The point of this is to introduce an official means of an optimized special effect entity versus initializing something via an actor inheritance.

• Never any interaction code, much easier processing, less RAM, etc.
• Allows for the following properties: Angle, Pitch, Roll, Scale, Velocity, Position, Renderstyle, Alpha, etc.

Something of this caliber could greatly improve gameplay mods that want to spawn a lot of effects.

[Accensus]

If possible to implement in the class, this would also benefit from this feature: viewtopic.php?f=15&t=58831
It'd allow modders to make flashlight effects out of volumetric particles. In fact, Caligari has already done something like that in his Ugly as Sin addon, but when used with square particles the effect is less than satisfying.

[Major Cooke]

While this will still be a bit more bulkier than particles themselves, it'll have a decently lesser size for certain. I'm willing to bet that mods could greatly improve performance if they can have something of this caliber, visually speaking, especially when lots is going on. With this being a heavily trimmed down class, less things to initialize and more effects can be used.

[Deybar_TECH]

Yes! excellent suggestion.

I also need a simple class for the effects
instead of creating a base actor with:
(+ NOINTERACTION +NOGRAVITY +DONTBLAST + + + etc ...)
it would be nice to at least be able to set
its appearance with some custom Sprite
or maybe be able to animate it with ANIMDEFS if it is more a graph than
a sprite.
perhaps it would also be necessary
to increase the maximum limit of (r_maxparticles = 65536)
the railgun use a large amount of particles.

[Major Cooke]

Technically if it has +NOINTERACTION and +NOBLOCKMAP that's all you need. None of the other flags like +NOGRAVITY, +DONTBLAST, etc are even needed.

-----

I'm thinking about giving this a try but I'm honestly not entirely sure how best to handle it. This is going to be difficult, but with any luck, I'll be able to do get something. Primarily, it's the states that might be of concern.

...but then again I have no idea what I'm doing here, heh.

[Apeirogon]

NOINTERACTION implies NOBLOCKMAP, NOGRAVITY and some other flags actually.
And also, IIRC, due to some gzdoom quirks, you should also add to it NOCLIP flag. Otherwise simple NOINTERACTION actor would prevent other actors from spawning, if its "inside" other actors spawning "volume".

[Deybar_TECH]

Technically if it has +NOINTERACTION and +NOBLOCKMAP that's all you need. None of the other flags like +NOGRAVITY, +DONTBLAST, etc are even needed.

Thanks for the info.
I will probably not rededicate my
projects exclusively to GZDoom,
so I no longer need this feature.

NOINTERACTION implies NOBLOCKMAP, NOGRAVITY and some other flags actually.
And also, IIRC, due to some gzdoom quirks, you should also add to it NOCLIP flag.

the bad thing about +NOCLIP Flag is that
it prevents objects from exceeding
the ceilings and floors.
very similar to +FLOORHUGGER & +CEILINGHUGGER.

+THRUACTORS could be a better option?

[Major Cooke]

NOINTERACTION implies NOBLOCKMAP, NOGRAVITY and some other flags actually.
And also, IIRC, due to some gzdoom quirks, you should also add to it NOCLIP flag. Otherwise simple NOINTERACTION actor would prevent other actors from spawning, if its "inside" other actors spawning "volume".

Yes but did you know the engine wastes time applying the NOBLOCKMAP flag when the actor spawns if you don't apply it already when spawning it?

[Apeirogon]

Yes but did you know the engine wastes time applying the NOBLOCKMAP flag when the actor spawns if you don't apply it already when spawning it?

It just un link actor from blockmap and link it back in without inserting actor into blockmap, cleaning all render/other lists.
But it will save some processor time, if actors lives long enough. Because in actors tick non interactive, actors just move around and thats it. It dont need to check that this line was crossed, is collision was happened, etc.
Plus, you also can cache actor for later use, so that gzdoom will not allocate memory on spawn of a new actors of the same type next time.

In any case, problem with gzdoom actors performance lies in their size. Because CPU, when it process some class/object, loads into its cache whole actor definition. Because thats how computer works. Its impossible to read just half of an object. For actor case that mean scale, mass, size, position, rip level, damage type, basically every line from here
https://github.com/coelckers/gzdoom/blo ... s#L89-L268
It dosent looks like "too much of a data", but that ONLY zscript side definition. Add to it internal (c++ side) variables, serialization, tender specific things, virtual functions, something something... And boom, we have 4 mega"bites" sized single actor. Or how big they are, 1 megabyte?!

What I meant here is, CPU reads too much "garbage" data too often.
Wanna check is two actors are able to collide? Here, have their position and collision box sizes and also water level, sprite id, reaction time and alpha.
One actor damaged another? Oh my, here health of victim and also its current state, amount of tics, min missile chance and target.
And so on.

[Major Cooke]

It also matters if you spawn like a hundred actors at once. It does have notable difference if you already have the actor unlinked or not. Some mods do this a lot and it slows down the game so having NOBLOCKMAP already specified is recommended.