ZDoom

While merging in GZDoom today, I had to do a couple manual merges, and noticed this among the things I had to merge in:

https://github.com/raa-eruanna/qzdoom/c ... a8676eR780

Should this be allowed? I thought we discussed against having it.

EDIT: Graf said he went ahead and disabled them temporarily pending discussion and evaluation here on the forum.

Is RenderOverlay supposed to be for 2D stuff? Disabling custom 2D stuff would be useless.

As for RenderFrame, I think he added it in response to this:

viewtopic.php?f=3&t=55073&p=976011&hilit=roll#p976011

Which IMO isn't too unreasonable of a use case.

Of course, I don't know what other problems could happen.

The render event is fired before the camera is set up. In general events like this, which are asynchronous to the playsim, must not, under any circumstances, mess with game data in any way or may the consistency of what they get for granted because you never know what interpolation settings are active here. So the usability of these events is naturally very limited.

I want to see concrete and valid use cases before enabling them again.

Graf Zahl wrote:I want to see concrete and valid use cases before enabling them again.

To add to that, and this is just my opinion, I would also like to see these use cases not be doable any other (at the very least simple) way.

It can't be used to create custom screen wipes, can it? That would be the only use case I could think of that isn't really doable with what is already available.

No, I don't think this code penetrates deep enough for something like that.

Just speaking for myself, I would use it to set the camera's roll and pitch for purely visual FX stuff, like screen tilting when you move, or some complex camera-only animation from a melee weapon like swinging an axe.

I want to give users the ability to disable the animations if it makes them nauseous while playing... If I have to alter the Actor's roll, that's already touching the playsim, and it won't be too graceful when used in multiplayer (either all players leave the feature turned on or turned off).

And about RenderOverlay? That's just only for drawing 2D stuff, right? Why would it be disabled? I don't see any other way to draw stuff on the screen in ZScript currently, except through PowerUps.

Could there be a "tagging" of functions, kind of like the "const" keyword in C++, that guarantees that it will not have any impact on worldsim? I have no good idea at the moment for how to name them, so let's just go with "cosmetic" for the purpose of discussion.

If you have cosmetic functions that are guaranteed not to affect worldsim, then you can have cosmetic scripts that only use cosmetic functions. And then you can have events that can only trigger cosmetic scripts.

What could be cosmetic functions? Stuff related to drawing and printing things on the screen, playing sounds, and perhaps spawning cosmetic actors -- actors that are prevented from interacting with normal actors or modifying them. They could still read values from normal actors, but not change them, so you could for example create some overhead health indicator that would warp on top of a monster and change color depending on the current health/starting health ratio, but not move the monster or heal it or whatever.

This would also double as a freebie for Zandronum -- anything cosmetic would be safe to have client-side only.

I like Gez's idea and how it plays on Nash's idea. But in the current implementation I don't know how much work Graf et. al. are willing to do to restrict functions enough to make such things available. If someone's willing to do it - I'd support it.

To develop it more: you'd have also cosmetic variables. Cosmetic functions could read normal variables but not write them. They could read and write cosmetic variables. Normal functions could not read cosmetic variables, though they could write them.

Cosmetic variables could be readable as long as there is some way to broadcast it over the network - that goes for both GZDoom and Zandronum. Basically - think of it this way - if it hits the net, it's fair game for the playsim itself.

While bouncing these ideas off of Major Cooke - this seems a bit out of the question but it's an idea that might be worth considering to see if it is adaptable to our current situation - what about copying the render queue, or the actors and thinkers within it, to a special place within ZScript, that allows it to modify them at will and non-destructively without affecting the playsim, that gets destroyed (or overwritten) after every frame? And then have both renderers act on these copies instead of their originals - and for the copies the game sim would not under any circumstance be able to access?

However - that does sound like a huge performance hit.

Please enable RenderOverlay. That's the only valid way to draw things.
I do agree however that RenderFrame's usefulness is quite limited (up to being completely useless). I originally intended to use it for interpolation, BUT since it can only change the playsim physically it doesn't make sense.

Now, if people use RenderOverlay for playsim alteration, then they will simply produce broken shit and it's their problem, I don't think we should disable or limit RenderOverlay because of that.
The fact that RenderOverlay is not synchronized to 35 tics is a huge improvement over ACS HudMessages and it's been waited for for decades (+RenderOverlay, as well as the UI stuff, is accessible outside of playsim, which means you can naturally change levels via an UI dialog once level changing is implemented, if not yet).
Plus, if you want to restrict it to the playsim, you will have to write gross hacks to queue InputEvents and UiEvents, because these are currently received ASAP as well, not trying to sync it with anything.

Anyway, my point shortly, to sum it up:
- RenderFrame can be safely removed as I personally don't see any uses of it anymore
- RenderOverlay is the best thing ever invented for statusbar extensions and UIs and should stay in the current state

Overall to Eruanna: I honestly think that your attempts to reduce everything to the playsim are going to work well with ZScript.
ZScript is by definition designed to allow more direct access to the engine, and you already can break things even without using events (see DrawPowerup virtual method, you can actually put anything in there and it'll be executed without sync to the ticrate).
Demo and networking compatibility can't be helped by preventing the modders from doing things, only by completely redesigning the demo and networking protocols.

ZZYZX wrote:Now, if people use RenderOverlay for playsim alteration, then they will simply produce broken shit and it's their problem, I don't think we should disable or limit RenderOverlay because of that.

That sounds all and well - until you consider past mods which have made their way to fame and ZDoom history, but are inherently broken because of vid_renderer hacks that we still have to deal with to this day.

The problem is - if something works, and someone abuses it, and something needs to be changed later - then their mod breaks - and everyone else has to deal with it because the chances of someone coming back to update their mod to the proper way of doing things is extremely rare.

So normally, I would agree with you on this - except that does happen, and it is a big problem for us.

The more complex GZDoom scripting becomes, the harder it will be to maintain 100% backwards compatibility with all the [censored word] coding practices employed by everyone.
ZScript is already complex enough that maintaining backwards compatibility with it would be the same as maintaining backwards compatibility with a third-party C++ DLL.

The main mistake that you are making here is that it's as well very hard to not possible anymore to hide all the engine internals from the modders — ZScript is not just a fancy syntax to ACS or DECORATE, ZScript itself is internal.
Which means that we are indeed required to provide interface-level compatibility, but making it 100% deterministic is simply not possible, especially as more features get ported from C++ to ZScript by Graf.
And then authors of mods will either have to upgrade their mods to the new GZDoom versions or players will have to use the old versions of GZDoom — that's just how it is with any other software and is an inherent limitation of a powerful plugin system.

My point here is — the less hacks there are, the better compatibility there will be! Because, for example, if people used CheckFeature(FT_3DFreelook) instead of vid_renderer, it'd continue to work correctly in QZDoom, but no, we don't want to give modders enough control over their mods, because it escapes the playsim and stuff, so people hack and hacks will inevitably break because we don't even try to support them (and often plainly can't: in this particular case the only way to "fix" the hacks would be returning fake values if vid_renderer, like you proposed in the other thread, which makes we actually stack one hack on another to compensate).