Rendering events

Archive of the old editing forum
Forum rules
Before asking on how to use a ZDoom feature, read the ZDoom wiki first. This forum is archived - please use this set of forums to ask new questions.

Rendering events

Postby Rachael » Wed Feb 15, 2017 5:30 am

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.
User avatar
Rachael
Admin
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Rendering events

Postby Nash » Wed Feb 15, 2017 6:12 am

Is RenderOverlay supposed to be for 2D stuff? Disabling custom 2D stuff would be useless.
User avatar
Nash
Twitter/Facebook/Youtube: nashmuhandes
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Twitch ID: nashmuhandes
Github ID: nashmuhandes

Re: Rendering events

Postby Nash » Wed Feb 15, 2017 6:18 am

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.
User avatar
Nash
Twitter/Facebook/Youtube: nashmuhandes
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Twitch ID: nashmuhandes
Github ID: nashmuhandes

Re: Rendering events

Postby Graf Zahl » Wed Feb 15, 2017 6:20 am

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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Rendering events

Postby Rachael » Wed Feb 15, 2017 6:46 am

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.
User avatar
Rachael
Admin
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Rendering events

Postby jpalomo » Wed Feb 15, 2017 7:02 am

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.
User avatar
jpalomo
 
Joined: 17 May 2010

Re: Rendering events

Postby Rachael » Wed Feb 15, 2017 7:14 am

No, I don't think this code penetrates deep enough for something like that.
User avatar
Rachael
Admin
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Rendering events

Postby Nash » Wed Feb 15, 2017 7:31 am

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.
User avatar
Nash
Twitter/Facebook/Youtube: nashmuhandes
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Twitch ID: nashmuhandes
Github ID: nashmuhandes

Re: Rendering events

Postby Gez » Wed Feb 15, 2017 7:42 am

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.
Gez
 
 
 
Joined: 06 Jul 2007

Re: Rendering events

Postby Rachael » Wed Feb 15, 2017 7:47 am

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.
User avatar
Rachael
Admin
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Rendering events

Postby Gez » Wed Feb 15, 2017 8:03 am

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.
Gez
 
 
 
Joined: 06 Jul 2007

Re: Rendering events

Postby Rachael » Wed Feb 15, 2017 8:07 am

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.
User avatar
Rachael
Admin
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Rendering events

Postby ZZYZX » Wed Feb 15, 2017 8:12 am

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.
Last edited by ZZYZX on Wed Feb 15, 2017 8:23 am, edited 1 time in total.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: Rendering events

Postby Rachael » Wed Feb 15, 2017 8:23 am

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.
User avatar
Rachael
Admin
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Rendering events

Postby ZZYZX » Wed Feb 15, 2017 8:26 am

The more complex GZDoom scripting becomes, the harder it will be to maintain 100% backwards compatibility with all the retarded 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).
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Next

Return to Editing (Archive)

Who is online

Users browsing this forum: No registered users and 4 guests