DarkDoomZ v1.10 [idgames]

[BROS_ETT_311]

This might be beyond the scope of this mod, but is it possible to implement a feature for casting shadows? Conceptually, when shining the light over a sprite based object or enemy it would project that actor's "shadow" on the surface behind it. I was thinking something like how Nash's SpriteShadow handles it, but taken a step further by interacting with the flashlight.

[AL-97]

You can use GShadow mod to inject some dynamic shadows into your game.

[Captain J]

The darkening effect of this addon is very impressive and dynamic! And Toggleable Flashlight is a neat touch too.

Now i wonder if we could make Ghoul Forest TC out of this...

[BROS_ETT_311]

You can use GShadow mod to inject some dynamic shadows into your game.

True! I've checked that out before and it is pretty cool, but not exactly universal since it overrides actors.

The darkening effect of this addon is very impressive and dynamic! And Toggleable Flashlight is a neat touch too.

Now i wonder if we could make Ghoul Forest TC out of this...

@Captain J, I think someone may have beat ya to to the punch there unless I'm mistaken. viewtopic.php?f=19&t=57430

[Kzer-Za]

A feature request:

Could you make an option to disregard the map information about light level in the sectors completely and calculate them from the "remoteness" from sectors that are under the sky? I.e. a sector neighboring an under-sky sector is slightly darker than the under-sky sector, the sector that neighbors the sky via at least one intermediate sector is lit even less, the next is lit less again. Starting from the 4-th or 5-th remoteness level it's pitch black. Of course, sectors separated by walls (impassable lines?) are not considered neighboring. Would you consider it within the scope of your mod?

If not, can you tell me what I need to read to try to make this adjustment myself?

[Caligari87]

This might be beyond the scope of this mod, but is it possible to implement a feature for casting shadows? Conceptually, when shining the light over a sprite based object or enemy it would project that actor's "shadow" on the surface behind it. I was thinking something like how Nash's SpriteShadow handles it, but taken a step further by interacting with the flashlight.

There is no way to project a shadow like that in GZDoom (I wish there was). The closest is GShadow, as mentioned, but it's not universal. Nash's Spriteshadow effect only really works for a very simple illusory approximation of a shadow and the effect will break down if abused, Either way, I consider it out-of-scope for DarkDoomZ.

Could you make an option to disregard the map information about light level in the sectors completely and calculate them from the "remoteness" from sectors that are under the sky? I.e. a sector neighboring an under-sky sector is slightly darker than the under-sky sector, the sector that neighbors the sky via at least one intermediate sector is lit even less, the next is lit less again. Starting from the 4-th or 5-th remoteness level it's pitch black. Of course, sectors separated by walls (impassable lines?) are not considered neighboring. Would you consider it within the scope of your mod?

I understand what you're suggesting and have considered it at length. Unfortunately Doom's sectors are not suited to this kind of light diminishing since they can be any size, shape, or even completely disconnected from themselves. It only really works for games like Minecraft or roguelikes where the lighting can be handled on a grid. Put another way, there's no way to determine a "neighboring" sector, only sectors that happen to share a line. Since the line geometry and sector heights are completely arbitrary as well, the amount of pre-processing the level would require to generate this "lightmap" would be astronomical just in script time. It'd also need to be completely static, and couldn't respond to any sort of level changes like a door opening. If you think you could tackle it, great, but I have no interest in it.

[Redneckerz]

I understand what you're suggesting and have considered it at length. Unfortunately Doom's sectors are not suited to this kind of light diminishing since they can be any size, shape, or even completely disconnected from themselves. It only really works for games like Minecraft or roguelikes where the lighting can be handled on a grid. Put another way, there's no way to determine a "neighboring" sector, only sectors that happen to share a line. Since the line geometry and sector heights are completely arbitrary as well, the amount of pre-processing the level would require to generate this "lightmap" would be astronomical just in script time. It'd also need to be completely static, and couldn't respond to any sort of level changes like a door opening. If you think you could tackle it, great, but I have no interest in it.

Could ZDRay be of use here? There is a custom compiled GZ build with support for that in the archives.

[Caligari87]

Certainly. But it's not realtime and requires engine support, so it's out of scope for DDZ.

[Redneckerz]

Certainly. But it's not realtime and requires engine support, so it's out of scope for DDZ.

Oh you also want it real time? Because you mentioned static lights..

If you merge DarkDoomZ with the custom ZDRay build/utility, would that not achieve what you want? Well, you would be locked to the 3.8-pre based build obviously, but still.. considering ZDRay is likely to remain in this state for the long haul, i guess you could just fork this and merge it with DarkDoomZ?

[Caligari87]

No, I will not merge DarkDoomZ into a broken unfinished project locked to an old fork of GZDoom.



User has warned himself for this post. ~~Caligari87

[Nash]

The "lightmaps" branch and ZDRay is nothing more than a proof of concept and is far, far, FAR from being anything even remotely resembling "usable". There shouldn't even be any discussion about it LOL.

Also, we (Cali, me, dpJudas, among others) are all in a mutual server where these engine experiments get discussed privately so I can assure you Cali 100% knows what is usable and what isn't.

[Caligari87]

Announcement

Since the last 1.5 pages have basically consisted of me turning down feature suggestions, I'd like to formally make it clear that I consider this mod feature-complete at this time, and I will not be adding any new features or tweaks in response to suggestions. Bug reports, if any, are still appreciated.

[Redneckerz]

Apologies for bringing it up. I was under the impression Nash's and Rachael's efforts into bringing it into the limelight were overseen, so i simply tried to be helpful here.

For what it is worth, i appreciate the self-warning. Some nice humor right there.

[Rachael]

FWIW - regarding the recent stuff - I just want to say I applaud Caligari for the way he handled this - yes, it was a mistake the original message, but to be fair we all have those days, and none of us are "above" the rules.

But like I said - we do all get a little snippy and annoyed from time to time, and that's why I tend to be a lot more lenient when people make angry posts, as long as they are not being malicious in doing so, or ignoring warnings.

It is fair for us all to hold each other accountable, and even better when we hold ourselves accountable. So, thank you Cali.

You may all return to your regular scheduled programming! ~♥~

[Caligari87]

DarkDoomZ v1.9 Released
Release notes and download

This is primarily small quality-of-life updates and tweaks I've made over the past year or so, nothing major but might be of interest to some people.

Highlights

• Sky sectors adjustment is now a slider instead of Half / Full / None.
• Enable "addons" by allowing the flashlight class to be replaced and aliased properly.
  • See DarkDoomZ Extended by Accensus for an example of this.
• DarkDoomZ options menu now cancels menu blur/dim so you can see your changes.
• Fix some dev console truncation warnings.

Please note that the required ZScript version is now v4.5 as I'm now using a ZScript menu class and I believe those are a newer addition. If you are using an older version of GZDoom/ZScript for some reason, you may try editing the first line of zscript.zsc to match your engine version, but I make no guarantees this will work.

As previously noted, I'm more-or-less finished with this project, so I anticipate this will be the "final" release unless something major happens. As always, bug reports are appreciated but I likely won't be adding any new features.