ZScript Code Review Request

Ask about ACS, DECORATE, ZScript, or any other scripting questions here!

Moderator: GZDoom Developers

Forum rules
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. If you still don't understand how to use a feature, then ask here.

Please bear in mind that the people helping you do not automatically know how much you know. You may be asked to upload your project file to look at. Don't be afraid to ask questions about what things mean, but also please be patient with the people trying to help you. (And helpers, please be patient with the person you're trying to help!)
Post Reply
User avatar
solarsnowfall
Posts: 1581
Joined: Thu Jun 30, 2005 1:44 am

ZScript Code Review Request

Post by solarsnowfall »

To teach myself ZScript I decided to create a particle effect which was infeasible back in the Decorate/ACS days: streaky looking sparks. This does everything I need it to do, what I'm asking for is optimization help. Am I doing anything obviously stupid due to my very incomplete understanding of how this stuff works?

The first argument on the placeable actors sets the color of the particles spawned whose sprite consists of a 1x1 square. The particles simply spawn a series of +NoInteraction particles behind them in a line which inherit the color.

Also, I can't seem to get the editor key stuff working in UDB.
Spoiler: ZScript
Spoiler: Textures Lump
Spoiler: GLDefs Lump
Attachments
spark-test.zip
(4.46 KiB) Downloaded 23 times
User avatar
Fishytza
Posts: 793
Joined: Wed Feb 23, 2011 11:04 am
Preferred Pronouns: They/Them
Contact:

Re: ZScript Code Review Request

Post by Fishytza »

solarsnowfall wrote:Also, I can't seem to get the editor key stuff working in UDB.
It's missing //$Arg0Type 11
Like so:

Code: Select all

   //$Arg0 "Color"
   //$Arg0Type 11
   //$Arg0ToolTip "Color values (0 - 9)"
   //$Arg0Enum { 0 = "White"; 1 = "Yellow"; 2 = "Orange"; 3 = "Gold"; 4 = "Green"; 5 = "Light Red"; 6 = "Red"; 7 = "Pink"; 8 = "Purple"; 9 = "Blue"; }
User avatar
solarsnowfall
Posts: 1581
Joined: Thu Jun 30, 2005 1:44 am

Re: ZScript Code Review Request

Post by solarsnowfall »

Thanks! I also found that I needed to move the comments to the Default block to get it working. I also found Vec3Offset for calculating coordinates.
User avatar
AFADoomer
Posts: 1344
Joined: Tue Jul 15, 2003 4:18 pm
Contact:

Re: ZScript Code Review Request

Post by AFADoomer »

Not necessarily optimizations, per-se, but cleaner code...
  • You can move the code in the FloorSpark "Active" state to an override for the Activate function (override void Activate(Actor activator)) instead of in the sprite states
  • Your SparkParticle "SpriteList" state doesn't need to have all four frames defined. Just (for example), PTCW A 0; will allow GetSpriteIndex to work.
One additional thing to maybe play with: Instead of dedicated sprites for each color, you could allow the map author to set any spark color by experimenting with different render styles and setting the actor's fillcolor (SetShade(color)) or another user variable.

I implemented this technique in Blade of Agony alongside the sprites, but I was never able to get nice bright spark centers unless using dedicated sprites, so the ability to set RGB colors went mostly unused (apologies, that code is tied in with the BoA particle culling system and had to be backward compatible with old actor setups, so is a bit of a mess).
User avatar
solarsnowfall
Posts: 1581
Joined: Thu Jun 30, 2005 1:44 am

Re: ZScript Code Review Request

Post by solarsnowfall »

AFADoomer wrote:You can move the code in the FloorSpark "Active" state to an override for the Activate function (override void Activate(Actor activator)) instead of in the sprite states
Okay, so here's a potential can of worms. That works great (and thank you), but I took things a step further and commented out the States block all together. What I found was that the floor and wall sparks worked as expected, but the ceiling spark never activates. Not sure why that would be the case. If handled via that method, I can't quite see why state definitions would be necessary at all.
AFADoomer wrote:Your SparkParticle "SpriteList" state doesn't need to have all four frames defined. Just (for example), PTCW A 0; will allow GetSpriteIndex to work.
I went from spawning invisible particles to spewing imps everywhere (which crashed the game) figuring out sprite registration. :oops: Thanks for the tip.
AFADoomer wrote:One additional thing to maybe play with: Instead of dedicated sprites for each color, you could allow the map author to set any spark color by experimenting with different render styles and setting the actor's fillcolor (SetShade(color)) or another user variable.
That's sharp. My first concern is with the GLDEFS. The whole reason I defined the sprites this way was to tag them with point lights. I'll have to do some more research, but I'm not immediately aware of how to carry over the color to the glow. At the very least, it seems like I should be able to break free of the confines of the pallette and have a better range of colors. I did really want to give greater color control, but settled on this for the perceived lack of better options.
AFADoomer wrote:I implemented this technique in Blade of Agony alongside the sprites, but I was never able to get nice bright spark centers unless using dedicated sprites, so the ability to set RGB colors went mostly unused (apologies, that code is tied in with the BoA particle culling system and had to be backward compatible with old actor setups, so is a bit of a mess).
Hey, that kinda sorta exactly looks derivative of my old decorate spark actors, for which I had to assail Tormentor into giving me credit. Cool! Seriously, though, good work. I can tell I'm going to be rifling through this repository for purposes of edification.
User avatar
AFADoomer
Posts: 1344
Joined: Tue Jul 15, 2003 4:18 pm
Contact:

Re: ZScript Code Review Request

Post by AFADoomer »

solarsnowfall wrote:
AFADoomer wrote:You can move the code in the FloorSpark "Active" state to an override for the Activate function (override void Activate(Actor activator)) instead of in the sprite states
Okay, so here's a potential can of worms. That works great (and thank you), but I took things a step further and commented out the States block all together. What I found was that the floor and wall sparks worked as expected, but the ceiling spark never activates. Not sure why that would be the case. If handled via that method, I can't quite see why state definitions would be necessary at all.
I'm not sure why that would be the case... Commenting out the States block causes the actor to fall back to using the default Actor class "Spawn" state, which is the same TNT1 A -1; Stop; that you used before, so I can't see why there would be a change.
solarsnowfall wrote:
AFADoomer wrote:One additional thing to maybe play with: Instead of dedicated sprites for each color, you could allow the map author to set any spark color by experimenting with different render styles and setting the actor's fillcolor (SetShade(color)) or another user variable.
That's sharp. My first concern is with the GLDEFS. The whole reason I defined the sprites this way was to tag them with point lights. I'll have to do some more research, but I'm not immediately aware of how to carry over the color to the glow. At the very least, it seems like I should be able to break free of the confines of the pallette and have a better range of colors. I did really want to give greater color control, but settled on this for the perceived lack of better options.
Check out the [wiki]A_AttachLight[/wiki] function... You can attach lights on-the-fly without requiring GLDEFs entries - just give the light an arbitrary name, and you can also remove it later with [wiki]A_RemoveLight[/wiki]. For an example, see again the BoA spark code.
solarsnowfall wrote:
AFADoomer wrote:I implemented this technique in Blade of Agony alongside the sprites, but I was never able to get nice bright spark centers unless using dedicated sprites, so the ability to set RGB colors went mostly unused (apologies, that code is tied in with the BoA particle culling system and had to be backward compatible with old actor setups, so is a bit of a mess).
Hey, that kinda sorta exactly looks derivative of my old decorate spark actors, for which I had to assail Tormentor into giving me credit. Cool! Seriously, though, good work. I can tell I'm going to be rifling through this repository for purposes of edification.
Thanks! Yes, those were originally yours... Almost completely reworked in the transition to ZScript and our particle culling system, but the underpinning logic and appearance is still yours.

Sorry for the difficulties in getting credit - the team's approach toward crediting others improved significantly before I came aboard, and I think that we were much better about crediting others during chapter 2 and 3 development. One note on the BoA code: Most of what's in the 'decorate' folder was a direct conversion from Decorate with no ZScript optimization (so, ugly state jumps, no custom functions, etc.). Everything else is fresh ZScript, but I was learning ZScript while writing a lot of this code, so be aware that not everything is optimal. I rewrote some of the worst code before chapter 3 was released, but there are still things that can be improved on.
Post Reply

Return to “Scripting”