ZScript Discussion

[Graf Zahl]

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.

[Rachael]

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.

[Major Cooke]

but mapperz want 2 maek it mandatory cuz thats how der mapz were sposed 2 look

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?

[Graf Zahl]

It just means that the struct has a different name, all old code should continue to work.

[Ed the Bat]

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.

[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

[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.

[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.

[Graf Zahl]

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]

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.

[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]

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.

[ZZYZX]

Ok, so per point.

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]

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.

[Ed the Bat]

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)?