ZScript Discussion

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!)
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49184
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by Graf Zahl »

Major Cooke wrote:
ZZYZX wrote:Incorrect wording, not replacement, but adding a global postprocess thing to the existing pipeline, the same way as current user shaders work (just not binding to a particular texture name).
Normal GZDoom stuff should still fire without any way to change it.

That's for dpJudas to answer, I haven't looked too deep into the system.
User avatar
Rachael
Posts: 13794
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: ZScript Discussion

Post by Rachael »

Major Cooke wrote:
ZZYZX from Mantis wrote:Incorrect wording, not replacement, but adding a global postprocess thing to the existing pipeline, the same way as current user shaders work (just not binding to a particular texture name).
Normal GZDoom stuff should still fire without any way to change it.
I can stand behind this one - as long as the user has the option to turn it off. Sorry - I know the first argument will be "but mapperz want 2 maek it mandatory cuz thats how der mapz were sposed 2 look" - I do not support that argument. But being able to define custom shaders is something that would definitely be nice.

Besides, making it user-optional is better than the no official support we have at all right now.
User avatar
Major Cooke
Posts: 8196
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Location: QZDoom Maintenance Team

Re: ZScript Discussion

Post by Major Cooke »

Eruanna wrote:but mapperz want 2 maek it mandatory cuz thats how der mapz were sposed 2 look
:laff:
Changelog wrote:Note that the internal struct String had to be renamed for this because the stricter checks did not let the type String pass on the left side of a '.' anymore.
Does this only need to be taken into account for whenever the String(Struct) functions are used, or do we need to do anything about this on our end?
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49184
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by Graf Zahl »

It just means that the struct has a different name, all old code should continue to work.
User avatar
Ed the Bat
Posts: 3060
Joined: Thu May 03, 2012 1:18 pm
Graphics Processor: nVidia with Vulkan support
Location: Maryland, US

Re: ZScript Discussion

Post by Ed the Bat »

Graf Zahl wrote:That function looks up the sprite name and matches it to the original Doom item type owning that sprite. Its sole purpose is to emulate pickup type determination by sprite like Doom originally did. It is entirely useless outside Dehacked.
Very well. I'll just continue manually identifying the pickups, then.
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine

Re: ZScript Discussion

Post by ZZYZX »

If it's by sprite, and you really want to do it like that, then you can build your own function that maps sprite names to classes that use them.
edit: C implementation from GZDoom source code: http://pastebin.com/YDqaTRcB and http://pastebin.com/mgPRKDGy
Last edited by ZZYZX on Mon Jan 23, 2017 1:23 pm, edited 2 times in total.
User avatar
Ed the Bat
Posts: 3060
Joined: Thu May 03, 2012 1:18 pm
Graphics Processor: nVidia with Vulkan support
Location: Maryland, US

Re: ZScript Discussion

Post by Ed the Bat »

That's what I originally wanted to do, but I have no idea how to approach that. The fact that DeHackEdPickup needed its own, unique, native function implied to me that it can't be done entirely in ZScript. But if it can, could you teach me how? It would save me so much trouble.
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine

Re: ZScript Discussion

Post by ZZYZX »

Maybe for syntactical purposes (not sure if you can define an array like that in ZScript).
Or maybe it's not possible to reference the global sprites array from ZScript yet. This is better to ask Graf.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49184
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: ZScript Discussion

Post by Graf Zahl »

Ed the Bat wrote:That's what I originally wanted to do, but I have no idea how to approach that. The fact that DeHackEdPickup needed its own, unique, native function implied to me that it can't be done entirely in ZScript. But if it can, could you teach me how? It would save me so much trouble.
It can be but I saw no point converting this

Code: Select all

// Sprite<->Class map for DehackedPickup::DetermineType
static struct DehSpriteMap
{
	char Sprite[5];
	const char *ClassName;
}
DehSpriteMappings[] =
{
	{ "AMMO", "ClipBox" },
	{ "ARM1", "GreenArmor" },
	{ "ARM2", "BlueArmor" },
	{ "BFUG", "BFG9000" },
	{ "BKEY", "BlueCard" },
	{ "BON1", "HealthBonus" },
	{ "BON2", "ArmorBonus" },
	{ "BPAK", "Backpack" },
	{ "BROK", "RocketBox" },
	{ "BSKU", "BlueSkull" },
	{ "CELL", "Cell" },
	{ "CELP", "CellPack" },
	{ "CLIP", "Clip" },
	{ "CSAW", "Chainsaw" },
	{ "LAUN", "RocketLauncher" },
	{ "MEDI", "Medikit" },
	{ "MEGA", "Megasphere" },
	{ "MGUN", "Chaingun" },
	{ "PINS", "BlurSphere" },
	{ "PINV", "InvulnerabilitySphere" },
	{ "PLAS", "PlasmaRifle" },
	{ "PMAP", "Allmap" },
	{ "PSTR", "Berserk" },
	{ "PVIS", "Infrared" },
	{ "RKEY", "RedCard" },
	{ "ROCK", "RocketAmmo" },
	{ "RSKU", "RedSkull" },
	{ "SBOX", "ShellBox" },
	{ "SGN2", "SuperShotgun" },
	{ "SHEL", "Shell" },
	{ "SHOT", "Shotgun" },
	{ "SOUL", "Soulsphere" },
	{ "STIM", "Stimpack" },
	{ "SUIT", "RadSuit" },
	{ "YKEY", "YellowCard" },
	{ "YSKU", "YellowSkull" }
};


to something the script compiler can handle.
dpJudas
 
 
Posts: 3134
Joined: Sat May 28, 2016 1:01 pm

Re: ZScript Discussion

Post by dpJudas »

ZZYZX wrote:Incorrect wording, not replacement, but adding a global postprocess thing to the existing pipeline, the same way as current user shaders work (just not binding to a particular texture name).
Normal GZDoom stuff should still fire without any way to change it.
Adding such a thing is relatively simple and IMO a good idea. Bind the user shader, render a screen quad, call the NextFBTexture() function or whatever I called it. But there's a few things that would need to be sorted out for it to become a reality:

1. You need a way to specify the user shader.
2. An OpenGL shader needs a specific version it targets (the #version xxx line). As GZDoom runs on a wide variety of hardware, it may not always be possible to use the shader. What should happen in those scenarios? Should it attempt to patch the shader for old versions, like GZDoom does internally?
3. Shaders need input - otherwise they can't really do anything interesting. So you need to be able to specify textures (bind texture DOORTRAK to DoorTexture uniform), samplers, uniform variables. In an ideal situation, some of those uniform variables could be set via ZScript.
4. You need to define some insertion points in the pipeline. Or at least decide on where they should run in an initial release of such a feature. For example, if we say the effect is an old TV monitor screen effect, if you run it before the pickup flash it gives one effect, but if you run it after you get a different effect.

I think for such a thing to become reality, we need a formal proposal (or a PR) on how to deal with all four. Probably best to create a new thread for it. I don't think those issues are particular hard to resolve, but it is of the kind that once we merge it in, we have to keep supporting it.
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine

Re: ZScript Discussion

Post by ZZYZX »

https://zdoom.org/wiki/GLDEFS#Hardware_shaders
This was supported for ages (I know for sure that Zandronum 2.1.2, which is ZDoom 2.5.0, supports it).
It's just that currently it requires you to provide a specific graphic (texture, sprite, flat, whatever).
That's the only reason people hack with replacement shaders.

Although it does have one problematic thing — GLSL compiler's error reporting will report wrong line, because files are concatenated on CPU side, which makes it quite hard to debug your stuff when it doesn't build.
If GLSL compiler's log format is defined and deterministic, then it probably can be parsed and modified on GZDoom side.
dpJudas
 
 
Posts: 3134
Joined: Sat May 28, 2016 1:01 pm

Re: ZScript Discussion

Post by dpJudas »

Yes, but those hardware shaders hook in elsewhere in the system. What I'm saying is you need to suggest in more exact terms how you intend to extend GLDEFS to list screen space shaders.

As for the error reporting, there's actually #line directives that GZDoom can insert into it that makes it write out the correct line numbers.
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine

Re: ZScript Discussion

Post by ZZYZX »

Ok, so per point.
dpJudas wrote:1. You need a way to specify the user shader.
2. An OpenGL shader needs a specific version it targets (the #version xxx line). As GZDoom runs on a wide variety of hardware, it may not always be possible to use the shader. What should happen in those scenarios? Should it attempt to patch the shader for old versions, like GZDoom does internally?
3. Shaders need input - otherwise they can't really do anything interesting. So you need to be able to specify textures (bind texture DOORTRAK to DoorTexture uniform), samplers, uniform variables. In an ideal situation, some of those uniform variables could be set via ZScript.
4. You need to define some insertion points in the pipeline. Or at least decide on where they should run in an initial release of such a feature. For example, if we say the effect is an old TV monitor screen effect, if you run it before the pickup flash it gives one effect, but if you run it after you get a different effect.
1. Two kinds:
- replaceshader shadername { ... } (works per-polygon, same properties as normal one: file, speed; if we are going to add more uniforms, then also list of allowed uniforms, so that their identifiers can be cached internally)
- overlayshader shadername { ... } (affects whole screen like postprocessing shader)
2. Current way does not specify the version and simply works on whatever GZDoom uses the same way GZDoom does it. Not sure how it works.
3. We can't specify textures in normal GLDEFS hardwareshaders.
We can't bind uniforms right now as well, and it's a shame because you can't for example make desynchronized instances of same shader (all of them will use the same render timer).
This can be changed as now we are going to have render frame scripts, and won't have to rely on the rendering subsystem in order to update shader's uniforms.
This certainly needs to be extended, but IMO it's beyond the scope of the suggestion (insert a pipeline hook for replacement shader).
4. overlayshader: I think these should run on the very final picture the same way as bloom/tonemapping, but before both.
replaceshader: After texture's getTexel (from GLDEFS hardwareshader) has been called, but before the very final value in the vertex program is returned.

(the replaceshader doesnt reflect the function properly I believe, but not sure what to call it).
dpJudas
 
 
Posts: 3134
Joined: Sat May 28, 2016 1:01 pm

Re: ZScript Discussion

Post by dpJudas »

The material shader ("hardware shader") works by taking main.fp and then pasting your custom shader at the end of it. Almost all the listed uniforms on the wiki are basically just uniforms that the shader already used internally.

For the screen space shaders we could do something similar, but note that today none of the screen space shaders use a shared shader like that. This means that there are no uniforms for you to play around with in the shader. If we take the original palette tonemap mod done by leileilol, she could not implement it properly because there was no way to bind a LUT texture. I really think it is crucial to allow custom uniforms to make them useful.

Edit: about the names you're suggesting. I think screenshader and materialshader are the proper names for the two types of shaders. Maybe make 'hardwareshader' an alias for material shader.
Last edited by dpJudas on Mon Jan 23, 2017 2:42 pm, edited 1 time in total.
User avatar
Ed the Bat
Posts: 3060
Joined: Thu May 03, 2012 1:18 pm
Graphics Processor: nVidia with Vulkan support
Location: Maryland, US

Re: ZScript Discussion

Post by Ed the Bat »

Graf Zahl wrote:It can be but I saw no point converting this

Code: Select all

 to something the script compiler can handle.[/quote]
These arrays are something I could certainly recreate on my own end. But perhaps I'm misunderstanding: is there a ZScript function available to modders that would return the name of the sprite in the actor's spawn state (which would be suitable for my purposes; doesn't have to be the sprite at time of player pickup)?

Return to “Scripting”