SpriteParticle Class

Remember, just because you request it, that doesn't mean you'll get it.

Moderator: GZDoom Developers

User avatar
Major Cooke
Posts: 8170
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Location: QZDoom Maintenance Team

SpriteParticle Class

Post by 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
Posts: 2383
Joined: Thu Feb 11, 2016 9:59 am

Re: SpriteParticle Class

Post by 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.
User avatar
Major Cooke
Posts: 8170
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Location: QZDoom Maintenance Team

Re: SpriteParticle Class

Post by 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.
User avatar
Deybar_TECH
Posts: 144
Joined: Wed Dec 26, 2018 3:36 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): Windows 7
Graphics Processor: Not Listed
Location: El Alto - La Paz - BOLIVIA
Contact:

Re: SpriteParticle Class

Post by Deybar_TECH »

Yes! excellent suggestion.
:idea:
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.
User avatar
Major Cooke
Posts: 8170
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Location: QZDoom Maintenance Team

Re: SpriteParticle Class

Post by 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.
User avatar
Apeirogon
Posts: 1605
Joined: Mon Jun 12, 2017 12:57 am

Re: SpriteParticle Class

Post by 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".
User avatar
Deybar_TECH
Posts: 144
Joined: Wed Dec 26, 2018 3:36 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): Windows 7
Graphics Processor: Not Listed
Location: El Alto - La Paz - BOLIVIA
Contact:

Re: SpriteParticle Class

Post by Deybar_TECH »

Major Cooke wrote: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.
:wink:

Apeirogon wrote: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? :?:
User avatar
Major Cooke
Posts: 8170
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Location: QZDoom Maintenance Team

Re: SpriteParticle Class

Post by Major Cooke »

Apeirogon wrote: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?
User avatar
Apeirogon
Posts: 1605
Joined: Mon Jun 12, 2017 12:57 am

Re: SpriteParticle Class

Post by Apeirogon »

Major Cooke wrote: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.
User avatar
Major Cooke
Posts: 8170
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Location: QZDoom Maintenance Team

Re: SpriteParticle Class

Post by 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.
Post Reply

Return to “Feature Suggestions [GZDoom]”