ZScript Discussion

[dpJudas]

Something like Qt's polish/unpolish approach, if anyone here is familiar with that.

Code: Select all

class RenderEventHandler : EventHandler native
{
  Actor CurrentThing; // default null

  virtual native void RenderBeforeThing();
  virtual native void RenderAfterThing();
}

So then you can override RenderBeforeThing and RenderAfterThing, and save current state in first and restore in second (to a handler field).
And refer to the currently processed thing as CurrentThing.
The problem that I have with this currently, is that things are not processed one-by-one, they are stored as a vissprite list (and analogous structure in the GL renderer). So we can have a Before, but not After. Or it can be an "after" that is called once the vissprite is added to the list... going to test.

This is a very bad idea. You are trying to build the scripting system around a specific renderer implementation. This will lock all future versions of GZDoom into rendering only in this exact manner (or simulate that it is doing so).

In fact, you already showed that if your script interface had been implemented before the current renderers, then they'd have been unable to store them in such a vissprite list without copying all the actor data (RenderAfterThing might change it). Or they'd have to wait with calling RenderAfterThing until after the entire list had been drawn, thus breaking an unknown number of mods out there that now would first have relied on RenderAfterThing being called before the next RenderBeforeThing.

Keep in mind that GPUs have gotten so fast that it is quite possible that a future GZDoom might just send all actors to the GPU every frame. Such a renderer would be forced to emulate the entire thing. Or a future GZDoom would do the visibility test in a compute shader - the CPU then would not even know which actors were visible and which weren't.

[ZZYZX]

How do you suggest pushing/popping the previous actor data then? ZScript currently has absolutely no way to extend fields of existing class.
People always hacked with Inventory, continue to hack with Inventory and will continue to hack with Inventory.
I really don't disagree with your statement, but I personally have no other idea how to nicely do it.

This is a very bad idea. You are trying to build the scripting system around a specific renderer implementation. This will lock all future versions of GZDoom into rendering only in this exact manner (or simulate that it is doing so).

See large-scale game engines. They don't block you from fiddling with rendering pipeline-related code just because it may change in the future.
Otherwise let's not add any features, otherwise they might be blocked by another new feature that might arrive sometime near year 2025.
Currently both OpenGL and Software renderers work in a way similar enough that this works. Further deepening into the renderer-specific code is not planned.

Keep in mind that GPUs have gotten so fast that it is quite possible that a future GZDoom might just send all actors to the GPU every frame. Such a renderer would be forced to emulate the entire thing. Or a future GZDoom would do the visibility test in a compute shader - the CPU then would not even know which actors were visible and which weren't.

I have a feeling that something like this would require a global engine update and some functions disappearing/getting deprecated won't be the largest problem really.
Also, what is "future GZDoom"? Are you sure that Doom as a community will live to a date when someone will actually make the engine work like the latest 2016 game engines?
As for the ordering: we can just say that order of before/after functions is undefined, the only thing that's guaranteed is that variables in the event handler will match the state that was before thing rendering. Internal implementation is not exposed in any way.

[dpJudas]

See large-scale game engines. They don't block you from fiddling with rendering pipeline-related code just because it may change in the future.
Otherwise let's not add any features, otherwise they might be blocked by another new feature that might arrive sometime near year 2025.
Currently both OpenGL and Software renderers work in a way similar enough that this works. Further deepening into the renderer-specific code is not planned.

I am talking about specifically adding event handlers for internal matters of the renderer. In this case, a call to a script function before an actor is drawn and after it is drawn. That kind of events are extremely dangerous as they lock things in stone. Note that I'm NOT talking about whether there should be event handlers elsewhere (I don't even have an opinion on that - don't know those parts of GZDoom well enough to comment).

The large-scale professional game engines allow you to modify state, and THEN it renders whatever you modified, just like GZDoom already works today. They do not allow you to hook event handlers into the renderer unless they don't target backwards compatibility at all. Like for example they might allow you to do it with C++ code, but then they don't promise you that this code will continue to function in the next version of the engine.

I have a feeling that something like this would require a global engine update and some functions disappearing/getting deprecated won't be the largest problem really.
Also, what is "future GZDoom"?

Today nothing in the engine cares about how things are rendered, except the automap (lines are flagged as seen) and AlterWeaponsprite. You could turn the entire renderer off and the playsim would not know. That is no longer the case if renderer events are added.

Are you sure that Doom as a community will live to a date when someone will actually make the engine work like the latest 2016 game engines?

Depends on which feature in modern engines you have in mind. If you mean batch rendering it all, then yes, I think that will arrive sometime in the future.

Are you sure that Doom as a community will live to a date when someone will actually make the engine work like the latest 2016 game engines?
As for the ordering: we can just say that order of before/after functions is undefined, the only thing that's guaranteed is that variables in the event handler will match the state that was before thing rendering. Internal implementation is not exposed in any way.

You're ignoring the fact that a more GPU based renderer won't even know exactly which were drawn. Should it now call RenderThingBefore+RenderThingAfter on all actors on the map? Not call them at all? Either way, you're going to break some mods unless you emulate the old behavior (bye bye speed).

[Graf Zahl]

I have to agree with dpJudas here. Hooking event handlers into the specifics of how the renderer works is not going to pan out. For once, the renderer processes a lot more sprites than are actually visible, if even one pixel of a sector gets drawn, all sprites in that sector will be processed, and thanks to your recent submission, also those sprites which touch the sector.

Furthermore, any sprite on a portal boundary will be drawn multiple times in the same frame in order to get rendered completely.

And the matter of renderer refactoring is also a thing. Maybe at one point in time it is actually possible to just dump all actors with texture data, render style and a bit more info into a large array and let a compute shader or whatever gets invented create the actual primitives from it. And then the hooks would become pointless because the GPU cannot call them.

And even if that sounds far out, here's something far closer to reality: Multithreaded data processing! If the renderer is rewritten to dispatch its data processing work across multiple threads you get a synchronization nightmare in your scripted events, if two threads are processing the sprite lists of two sectors at the same time! Large parts of the engine are completely incapable of multithreaded processing and you can bet that the scripters will not be aware of this so a shitload of synchronization stuff will have to be added to the interface, and even then the out-of-order processing will make this a nightmare to deal with.

And last but not least, VM calls are a very expensive matter. A single VM call on a function with 2 parametest takes approx. 40x as long as a C function call. Hook only one event handler into this loop and it can bring down performance quite effectively without a filtering system that restricts the whole thing to specific actors. We already had that effect when calling a C-function to check dynamic light visibility. That part absolutely murdered performance, and this one would be on the same level, if not worse, because running the VM will quite throroughly kill the CPU's instruction cache, as it tends to run through a lot of code.

I can see where you are going, and the basic idea definitely sounds interesting, but this is the stuff future mod breakage is being made of. Depend too much on this and eventually stuff will stop working.

[ZZYZX]

Today nothing in the engine cares about how things are rendered, except the automap (lines are flagged as seen) and AlterWeaponsprite. You could turn the entire renderer off and the playsim would not know. That is no longer the case if renderer events are added.

Technically ZScript is no longer playsim-specific. Even before my stuff. It already has gameaction variable that breaks out of playsim
Point is, I believe it's the general direction ZScript is going to head in.

Depends on which feature in modern engines you have in mind. If you mean batch rendering it all, then yes, I think that will arrive sometime in the future.

Will FrozenT finally stop lagging ?

Also, actually, I think if it's that dangerous and broken I can easily remove the actor-specific hooks and add another one on global render finish (after RenderView's been called from the main game loop).
That way you at least can revert stuff if you are using your own property backup system.

And last but not least, VM calls are a very expensive matter. A single VM call on a function with 2 parametest takes approx. 40x as long as a C function call. Hook only one event handler into this loop and it can bring down performance quite effectively without a filtering system that restricts the whole thing to specific actors. We already had that effect when calling a C-function to check dynamic light visibility. That part absolutely murdered performance, and this one would be on the same level, if not worse, because running the VM will quite throroughly kill the CPU's instruction cache, as it tends to run through a lot of code.

Checked with FrozenT. No performance regressions found
Checked with nuts.wad. FPS dropped from 67 to 35, but then again, it's 10000 monsters rendered at once.

— this is with RenderFrame+RenderCamera+RenderBeforeThing+RenderAfterThing.

But yea, I'm going to remove this part and replace it with something more backward compatible.
What about other things though? @Graf
What about per-portal hook? Unlike the other stuff it's actually important that you can make custom shadows/picnum overrides face the right direction, as well as do proper CheckSight (for example combine all checksights based on viewpoint locations during rendering), and custom skybox parallaxing (consider a skybox viewport that moves at 1/16th of player's speed for example, while retaining all other properties — including portals and exact camera position (bobbing, etc)).
Consider this code here: https://github.com/jewalky/ZSDuke/blob/ ... d/base.txt (the line that says about "awayFromCamera").
Most importantly: what about serialization? I don't know how it works, at all.

[Graf Zahl]

Checked with FrozenT. No performance regressions found
Checked with nuts.wad. FPS dropped from 67 to 35, but then again, it's 10000 monsters rendered at once.

You may not see any obvious regression with Frozen Time, you have to check 'stat rendertimes' and not the FPS counter to see the impact.

What about other things though? @Graf
What about per-portal hook? Unlike the other stuff it's actually important that you can make custom shadows/picnum overrides face the right direction.
Consider this code here: https://github.com/jewalky/ZSDuke/blob/ ... d/base.txt (the line that says about "awayFromCamera").
Most importantly: what about serialization? I don't know how it works, at all.

What do you mean by 'per portal hook''? Calling this once before a single camera viewpoint gets rendered? Be careful here, that part is just as much subject to potential refactoring than the innards of the sprite renderer. It may well be possible to not only multithread a single viewpoint's render data but also multithread the rendering of two different viewpoints because that allows even more parallelization because you could also paralellize the BSP traverser and visibility clipper which have to run sequentially for each viewpoint, but there's nothing prohibiting two viewpoints from being done in parallel. (the most obvious case being with camera textures because those get done before the main scene.) And then again your event system will completely fall apart because it can alter the data that's about to be rendered.
I'm sorry but I really thing that it's not a good idea at all to add any kind of hook into the renderer that allows the user to tinker with the data. It's guaranteed to cause problems when stuff needs to be refactored.

Serialization for scripted class members is automatic, if the object gets serialized. For native members you have to implement the Serialize method, and to make sure it actually gets written out at all you have to implement a global SerializeEvents method that gets called from the savegame code. And do not use OF_Fixed for anything that needs to be serialized. That doesn't work. OF_Fixed means 'fixed' for real, i.e. it may not change unless first getting unfixed or deleted.

[ZZYZX]

What do you mean by 'per portal hook''? Calling this once before a single camera viewpoint gets rendered?

Yes. What RenderCamera currently does.

Serialization for scripted class members is automatic, if the object gets serialized. For native members you have to implement the Serialize method, and to make sure it actually gets written out at all you have to implement a global SerializeEvents method that gets called from the savegame code. And do not use OF_Fixed for anything that needs to be serialized. That doesn't work. OF_Fixed means 'fixed' for real, i.e. it may not change unless first getting unfixed or deleted.

I use OF_Fixed for things that should not be serialized (EventHandlers from MAPINFO).
This is because, like I said, we don't want global stuff (like UI or HUD or whatever) to reload from save games, besides the really global handlers (those from GameInfo section, which are not even linked to a map and exist before/after the world) don't have any point in serializing them to the saves. That's the whole point behind having a separate EventHandler branch called Staticblablabla.
Actually, I only use OF_Fixed for these eternal classes. Even per-map MAPINFO handlers aren't fixed already, so they unload naturally using GC.

What do you mean by 'per portal hook''? Calling this once before a single camera viewpoint gets rendered? Be careful here, that part is just as much subject to potential refactoring than the innards of the sprite renderer. It may well be possible to not only multithread a single viewpoint's render data but also multithread the rendering of two different viewpoints because that allows even more parallelization because you could also paralellize the BSP traverser and visibility clipper which have to run sequentially for each viewpoint, but there's nothing prohibiting two viewpoints from being done in parallel. (the most obvious case being with camera textures because those get done before the main scene.) And then again your event system will completely fall apart because it can alter the data that's about to be rendered.

Well I believe it could be optionally synchronized later, only if there are defined hooks with specific signatures.
And warned with large red letters: THIS SLOWS MULTITHREADING DOWN.
Some people might actually still consider it useful enough to continue using it despite breaking multithreading.

I'm sorry but I really thing that it's not a good idea at all to add any kind of hook into the renderer that allows the user to tinker with the data. It's guaranteed to cause problems when stuff needs to be refactored.

Well, like I said, I'd only want to keep the global started/stopped hooks (these don't depend on particular implementation anyway) and the portal hooks, and as for multithreading see above.
The ability to have a reliable way to do stuff based on real view location IMO outweighs the fact that we'll have to synchronize simultaneous portal rendering by checking for some function like E_CheckCameraHooks.
Multithreading of single viewpoint does not matter here, because I'm not trying to do anything inside the viewpoint processing once it's been entered.
Note: the functions don't expect any particular order of portal queries.
The point is that this is one of the very common tasks that modders try to solve, and usually end up simply using player position which breaks horribly (ex.: cameratexture, portal, chasecam, F12 coop spy, viewbob).
Now in ZScript you can also use player.camera, which breaks less horribly, but still doesn't support viewbob and portals transparently, and not sure about chasecam.

[Graf Zahl]

That may be but the mere fact that such a feature can get in the way here is enough for me not to consider it. Render hooks of any kind are not going to fly because there's too many variables here, how things might change.

Just an example: Imagine someone manages to solve the problem with a Build style renderer and its wall sorting performance. such an approach would allow to render many portal constructs without any stencil as one scene, and suddenly all the assumptions you make about being able to make such a callback are thrown out of the window. It again locks the renderer to a certain way of doing things. Fortunately, the Doom renderer for the most part never calls back into the playsim, the only part that actually does right now is AlterWeaponSprite - but since the HUD sprite is the very last thing done on a scene it can't cause many problems if abused. It's still something I'd rather see gone because it's just a shitty way to do stuff and gets in the way of translucency for overlays.

[ZZYZX]

How would you implement something like I've done in the example pk3 then? 100 unique subfeatures in the form of Actor properties that somehow resolve to something remotely similar?
Also if you render portals as a single render pass, the renderer will still have to somehow decide how is actor rotated in relation to the camera. Perhaps put something there?
Anyway, RenderCamera does not lock anything to anything. If you render everything as single scene, RenderCamera should be called every time actors have different relative position from the previous camera. Simple as that.
This is going to happen even when you render everything as a single pass, because there will be a point where you gather and combine all the stuff to send to the rendering pipeline.

(sorry, I really want to be able to do these 15+ features that hooking portals enables)
(I want that enough that I can even promise you to assist with any porting of the stuff in case you really decide to rewrite the renderer from scratch!)

Also, again, in the documentation, we can say this: "this function is renderer-specific and is not guaranteed to be supported on all renderers".
This is somewhat possible, as we will have differences between renderers either way. Here, it just moves the responsibility to the modder.
Yes, I understand that most modders would look at the feature list and be like "wow fuck the compatibility". But then you can still point at them and say that it's their problem that something broke

[Graf Zahl]

Careful!

You are already basing the whole thing on faulty assumptions. As you can see, the sprite rendering code consists of two functions - process and draw.
But, when portals come into play, the order of execution will be:

- process for main
- process for portal1
- process for portal2
- process for portal2.portal
- draw for portal1
- draw for porta2.portal
- draw for portal2
- draw for main

so if your callback makes some alterations, it still may ultimately not work as expected, depending on what the callback does.

[ZZYZX]

Careful!

You are already basing the whole thing on faulty assumptions. As you can see, the sprite rendering code consists of two functions - process and draw.
But, when portals come into play, the order of execution will be:

- process for main
- process for portal1
- process for portal2
- process for portal2.portal
- draw for portal1
- draw for porta2.portal
- draw for portal2
- draw for main

so if your callback makes some alterations, it still may ultimately not work as expected, depending on what the callback does.

Depending — yes. But this is easy to account and list things that are safe to change — say, rendering-related flags, +position, +picnum, and store these into your rendering structure before pushing it to the drawer.
This is what current renderers do, namely the software one, which assembles the list of vissprites then renders it. I'm resetting actor structure after vissprite has been added, but it works. (same for OpenGL, btw!)
The order won't matter here already, as RenderCamera is context-less: it will enumerate all things on the map (with filter obv) and alter them according to current state, so that the renderer can then pick up the new actor states. The only requirement here is that it should be done before BSP traversal, because otherwise things will be added in the wrong order if they are moved around (this is important for the software renderer, and possibly for some other later), + the requirement that there are no simultaneous camera renders (at least while hooks are enabled and processing).
All that matters during RenderCamera call is that ViewPos and angles are valid. Not even Camera is required, I believe, if that field is hard to account for.
Pretty sure this basic level of compatibility is easy to achieve on any renderer.

Also — side question — can I try to do something with UI, input and Screen.DrawHUDTexture?
Since you already looked at what the system is going to look like

Also (x2) — can I add Console.Printf()? Would be quite useful to disconnect logging from actor and not have to write stuff like A_Log(String.Format(...)), and Console class is already there.

[dpJudas]

The only requirement here is that it should be done before BSP traversal

You might find it useful to know that I have an experimental renderer that draws the scene without doing any BSP traversal at all. It doesn't do portals right now (amongst a bunch of other things), but the point is that you can't assume that the rendering will be done exactly as GZDoom does today. This includes collecting information about which things to draw.

Pretty sure this basic level of compatibility is easy to achieve on any renderer.

If you mean that any renderer could simulate that it drew some portals, then yes. But a future renderer might find a way so cheap to draw portals that it just always draws all of them - except once those hooks are there, drawing all portals might get unexpectedly expensive due to scripting concerns.

Edit: you also have to remember that once you run scripts during rendering, the data used as input into the renderer is no longer immutable. That means any multithreaded setup cannot reference the original data - it has to be copied. If we take vissprite in the software renderer as an example, it could theoretically dispatch the projection part of those vissprites to multiple threads and then finish off with a map/reduce kind of pattern for sorting. But once the script code enters the picture it first has to copy all input data used for projection before it can dispatch it.

[ZZYZX]

Ok, I'll reword: not before BSP traversal, but before collecting actor data for the current portal instance.
Portal instance does not mean stencil. Portal instance does not mean separate function. Portal instance means having actors not where they should be if scene did not have portals.
This is going to be processed on CPU in either case, and can be passed to scripts. IMO.
Unless you want to push the whole linedef, sector and actor structures to the GPU, but I don't know of any GPU that would be capable of handling that properly.

Also — a future renderer which gets below 35fps with slightest render hooks can as well choose to not support them — see what I said above about "renderer-specific feature is not guaranteed to be supported fully".
For example, it might call RenderCamera only once for compatibility, at the same time as RenderFrame, which is a game loop hook and is not renderer-specific.
The modders' code will assume that there are no portals and somewhat work.
Key word is "somewhat", but then again it will happen maybe, sometime and in the future, while the working stuff already happened.

Edit:

Edit: you also have to remember that once you run scripts during rendering, the data used as input into the renderer is no longer immutable. That means any multithreaded setup cannot reference the original data - it has to be copied. If we take vissprite in the software renderer as an example, it could theoretically dispatch the projection part of those vissprites to multiple threads and then finish off with a map/reduce kind of pattern for sorting. But once the script code enters the picture it first has to copy all input data used for projection before it can dispatch it.

This is legit, but then again, how much input data is used for projection compared to what is already stored in the vissprite? (of those stuff that resides in AActor?)
No one is going to create or delete actors during this stage. No one is going to change the camera (at least this should not be possible and perhaps even checked explicitly).
Perhaps I have serious imagination problems, but I don't see any problems with this above the "will have to be accounted for" level of difficulty.
And like I said, I'm ready to help with the compatibility stuff for the scripting if someone implements new fancy renderer pipeline that's completely unrelated to the current one.

[Graf Zahl]

The only requirement here is that it should be done before BSP traversal

You might find it useful to know that I have an experimental renderer that draws the scene without doing any BSP traversal at all. It doesn't do portals right now (amongst a bunch of other things), but the point is that you can't assume that the rendering will be done exactly as GZDoom does today. This includes collecting information about which things to draw.

I have also experimented with this, you can find it in src/gl/unused/gl_builddraw.cpp, but this was too slow with large area sectors so in order to work it will require some splitting of large sectors by a different method than a BSP normally uses.

Would you mind sharing your idea, if it's in a presentable state?

Edit: you also have to remember that once you run scripts during rendering, the data used as input into the renderer is no longer immutable.

I think this point cannot be stressed enough. In the entire renderer there's exactly two points where the code mucks around with the actual actors - that's the aforementioned AlterWeaponSprite and to make the actual player's sprite invisible on portal boundaries. The former one needs a good idea to get refactored away and the second one was a mere matter of convenience, the needed info might as well be stored in the current camera's drawinfo struct and keep the play data immutable. In fact for multithreading this would be necessary anyway.

I'm on the same side here: The assumption that the data the renderer gets is immutable is important - changing this very basic fact will render a large number of possible optimizations inoperable. And in this context we should not forget that right now we are at a point where new rendering APIs with a radically different approach are being introduced. GZDoom is still very old-school in this regard, but it certainly won't remain so. And there's the very real danger that these scripting hooks will seriously get in the way of doing a Vulkan based render path that takes full advantage of parallelization, which could even be something as seemingly banal like branching off at the first level in a BSP, traversing both halves in parallel if the node line's angle allows for doing this without too much of a speed hit (i.e. it's close to the view axis) - including processing of portals in both halves. This is another thing: To create the render data for a portal you do not need a stencil. All you need is a maximum angular clipping range, so once you know that you can fire off the subscene right away and not wait until the main scene has rendered its solid geometry.

[ZZYZX]

To create the render data for a portal you do not need a stencil. All you need is a maximum angular clipping range, so once you know that you can fire off the subscene right away and not wait until the main scene has rendered its solid geometry.

Well my point was that you *can* do parallelism, but also can *not* do parallelism based on whether hooks are enabled. But whatever.
So the deep render hooks are put away for now or whatever. At least until the new renderer is available. Being able to get ViewPos before rendering the scene, and being able to get sub-tick precision with that is enough feature set already, if you accept that part.

But anyway, can you please answer this one too before it gets lost in the conversation?

Also — side question — can I try to do something with UI, input and Screen.DrawHUDTexture?
Since you already looked at what the system is going to look like

Also (x2) — can I add Console.Printf()? Would be quite useful to disconnect logging from actor and not have to write stuff like A_Log(String.Format(...)), and Console class is already there.