Will the new dyn. lights struct ever be exposed to ZScript?
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!)
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!)
- phantombeta
- Posts: 2088
- Joined: Thu May 02, 2013 1:27 am
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
- Location: Brazil
Will the new dyn. lights struct ever be exposed to ZScript?
I'd really like to know this, as some things currently can't be done in ZScript anymore, such as lights that don't light their owners. It'd also be nice for doing ZScript-controlled dynlights with less of a performance impact.
I imagine it would be possible to make an interface that doesn't expose the internals of the dynamic light struct, allowing them to be changed later if needed.
I imagine it would be possible to make an interface that doesn't expose the internals of the dynamic light struct, allowing them to be changed later if needed.
Re: Will the new dyn. lights struct ever be exposed to ZScri
I wouldn't mind doing the work to make this happen, but whether it ever happens and the specifics of it are up to Graf.
As far as I know, dynamic lights are fully playsim safe despite being a renderer function. But I expect actually manipulating these variables every tic will likely produce a ton of lag since it would require relinking the lights when they move or change. I don't know if disabling r_lights or gl_lights would affect this though.
As far as I know, dynamic lights are fully playsim safe despite being a renderer function. But I expect actually manipulating these variables every tic will likely produce a ton of lag since it would require relinking the lights when they move or change. I don't know if disabling r_lights or gl_lights would affect this though.
- phantombeta
- Posts: 2088
- Joined: Thu May 02, 2013 1:27 am
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
- Location: Brazil
Re: Will the new dyn. lights struct ever be exposed to ZScri
I would also be willing to do that, but I wouldn't do it unless Graf said I could - otherwise, there'd be a very real chance of wasting my time because he didn't want it or wanted it done in a specific way.Rachael wrote:I wouldn't mind doing the work to make this happen, but whether it ever happens and the specifics of it are up to Graf.
Relinking would only be necessary for changing position and radius. Colour, angle and pitch don't affect the linking. It also wouldn't really produce any more lag than moving lights already do.Rachael wrote:But I expect actually manipulating these variables every tic will likely produce a ton of lag since it would require relinking the lights when they move or change.
Re: Will the new dyn. lights struct ever be exposed to ZScri
Agreed - my concerns exactly. Which is why, like you, I am not interested in investing any work into this unless he says something.phantombeta wrote:I would also be willing to do that, but I wouldn't do it unless Graf said I could - otherwise, there'd be a very real chance of wasting my time because he didn't want it or wanted it done in a specific way.
Colour you're right about - however, I expect the situation with pitch and angle changes to be temporary. There may yet be changes in the future (if they haven't happened already - I don't think they have yet, though) so that spotlights only link their relevant surfaces. This is what I am a bit iffy about - just because dpJudas might say he has no plans to change this, doesn't mean it will never change, be it by him years or so down the line, or by someone else. It's one of those "very low priority needs" - and so when the change occurs, this assumption will break the system, you will have to prepare for that in advance.phantombeta wrote:Relinking would only be necessary for changing position and radius. Colour, angle and pitch don't affect the linking. It also wouldn't really produce any more lag than moving lights already do.
- phantombeta
- Posts: 2088
- Joined: Thu May 02, 2013 1:27 am
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
- Location: Brazil
Re: Will the new dyn. lights struct ever be exposed to ZScri
I'd say doing such a thing would be a VERY bad idea. Changing angle and pitch is likely to be used more often than movement, and that'd make changing angle and pitch an expensive operation, which I'd argue would be worse than slower relinking on movement. (which probably isn't likely to be done as often as changing pitch or angle)Rachael wrote:Colour you're right about - however, I expect the situation with pitch and angle changes to be temporary. There may yet be changes in the future (if they haven't happened already - I don't think they have yet, though) so that spotlights only link their relevant surfaces. This is what I am a bit iffy about - just because dpJudas might say he has no plans to change this, doesn't mean it will never change, be it by him years or so down the line, or by someone else. It's one of those "very low priority needs" - and so when the change occurs, this assumption will break the system, you will have to prepare for that in advance.
I'd also argue they should only relink after everything is done ticking/when actually needed, anyway, to allow for modifying them more easily without relinking the same light a hundred times in a single tic.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Will the new dyn. lights struct ever be exposed to ZScri
This struct won't get exposed to scripting, it's render side data that's allocated through means that do not work with scripting for performance reasons. What should be done is to add functionality to let the user attach and detach lights through some utility functions.
- phantombeta
- Posts: 2088
- Joined: Thu May 02, 2013 1:27 am
- Operating System Version (Optional): Windows 10
- Graphics Processor: nVidia with Vulkan support
- Location: Brazil
Re: Will the new dyn. lights struct ever be exposed to ZScri
Why not expose only setters (e.g., "SetPos", "SetFlag") instead of making such a thing, if what you don't want is people reading the dynlight data?
If we have to spawn light actors anyway, it'd go against the entire point of separating dynamic lights from the actors. And if we are forced to use only GLDEFS-defined lights, that'd be a pretty bad and useless feature.
If we have to spawn light actors anyway, it'd go against the entire point of separating dynamic lights from the actors. And if we are forced to use only GLDEFS-defined lights, that'd be a pretty bad and useless feature.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Will the new dyn. lights struct ever be exposed to ZScri
What needs to be done is to give class Actor a method AttachLight that sets up an internal structure and gives it an identifier, so when you call the function again with the same identifier, it will modify the light, otherwise it will add a new one. Of course there also needs a DetachLight method.
The internal structures should neither be readable nor settable directly and scripts shouldn't be able to get a pointer to them.
The internal structures should neither be readable nor settable directly and scripts shouldn't be able to get a pointer to them.
- Caligari87
- Admin
- Posts: 6174
- Joined: Thu Feb 26, 2004 3:02 pm
- Preferred Pronouns: He/Him
- Contact:
Re: Will the new dyn. lights struct ever be exposed to ZScri
So... it seems this is going to break an extremely important feature of one of my mods. I'm happy to do it in a different way if necessary, but I really need a way to access dynlight-affected lightlevel. I hope we can get something canonical for that.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49067
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: Will the new dyn. lights struct ever be exposed to ZScri
Attached lights are no longer actors. This was changed for 4.0 already, the reason mainly being that the old method was extremely inefficient and had a heavy impact on how lights affected the game's performance. Since 4.0 the dynamic light actors are no longer the actual lights but merely anchor objects to attach lights to that do not belong to a 'real' map actor.
That code doesn't even work properly if shadowmaps or glowing textures are being used. And it may also break if the lighting model sees further changes, e.g. if the currently abandoned lightmaps branch gets resurrected.
That code doesn't even work properly if shadowmaps or glowing textures are being used. And it may also break if the lighting model sees further changes, e.g. if the currently abandoned lightmaps branch gets resurrected.
Re: Will the new dyn. lights struct ever be exposed to ZScri
Wow, that's some fancy script you've got there! It looks like some of that code might be generic enough that it could make sense to, one day, bake into built-in functions, for additional speed, reliability, and compactness. It's a chicken and egg problem: You need to provide the abilities to do some low-level stuff in the script language, to know what functionality people want. But, once they start using the language to the fullest, you start to identify common constructs that people need everywhere. Then, it may make sense to provide some built-in support for some of them. Which is all good, as long as you don't recreate the .NET CLRCaligari87 wrote:So... it seems this is going to break an extremely important feature of one of my mods. I'm happy to do it in a different way if necessary, but I really need a way to access dynlight-affected lightlevel. I hope we can get something canonical for that.