If I was to come with a suggestion, then it'd be cool if r_visibility adjusted the range of this. Though whether or not that's possible is something I'd have my doubts about.
Edit: A first bug would be that sprites totally ignore the sector brightness:
And I'd like to say that this is an absolutely game-breaking bug. I can't see whether it's a teammate or an enemy unless I'm literally five meters away. (NOT GOOD)
Doesn't really help that it provides total obscurity to enemies in darker landscapes. (Admittedly it'd be dirty cheating in a very bright map. But that's only yet another reason as to why it's broken.)
Last edited by Blox on Fri Dec 21, 2012 4:10 am, edited 1 time in total.
Fixed the liteamp bug in Zandronum. First post updated. Windows Source code
Also:
Nash wrote:Shouldn't these be contributed to their respective port authors/maintainers for inclusion into the official versions?
Unfortunately, all this is just a quick hack. I am happy as long as there is software renderer's lighting, even as separate GZDoom/Zandronum version and don't actually care about official versions as long as I have teh lighting. I'd say it is just a proof-of-concept that software renderer's lighting is easy to do in OpenGL. And sorry, I am too lazy, have other projects, I am not ready to contribute in a more serious way.
Last edited by Korshun on Mon Dec 24, 2012 11:37 am, edited 1 time in total.
It's a shame, but understandable, that you don't want to get bogged down in making a patch that would allow integration into the official versions. Your lighting mode looks very nice and very Doom-like indeed but your exe will become outdated as far as other engine features are concerned (in fact it already is as far as SVN version features goes) so it's not particularly useful to me as a player or modder.
Well, this definitely needs some cleaning up first. There's far too many places where changes were made instead of just altering the core lighting functions. I don't see any reason though why this should not become official.
I didn't mean I am abandoning this forever. I will update it with ports' releases because I can't play without it anymore .
Also, I want to play online with software renderer's lighting in OpenGL. Updating would mean incompatibility with current Zandronum servers. And Zandronum is so outdated compared to even current GZDoom yet everyone plays it.
Graf Zahl wrote:Well, this definitely needs some cleaning up first. There's far too many places where changes were made instead of just altering the core lighting functions. I don't see any reason though why this should not become official.
Sorry, was excited with getting it to work ASAP and when I realised that I can just modify core lighting functions, I didn't bother to rename them back . But when I was making Zandronum version I already knew what to change so it is cleaner (but has hacks for outdated gzdoom).
That's exciting news. And it's late here so I don't have time to build the recent commit. I'll have to leave it until tomorrow. Thanks for doing that though.
shoober wrote:I like the software render because it keeps the grittiness and dirty look that makes Doom a much scarier game. Trying to pretty it up with OpenGL doesn't do it justice.
I couldn't agree more, it's just that working with paletted images is so damn annoying... Just when everything looks great, you convert to it to Doom's palette and what does it look like? It looks like garbage:
Screenshot_Doom_20121219_095511.jpg
This is the only reason I am working on both GZDoom mods and ZDoom mods. Converting textures and sprites to paletted images and doing touch-ups is very time consuming.
I think palettes can be a very powerful tool if you are conscious of your palette and preferably design it specifically for your mod. For Operation Serpent I made a new palette and every color was carefully chosen. A well-done palette that all your graphics adhere to is a great way to unify the art style of your project.
(my colormap kind of sucks though and it seems like it's not going to be possible to fix it without hand-tuning because the RGB algorithms that SLADE3 and XWE use are pretty dodgy and the CIE ones are worse).
shoober wrote:I like the software render because it keeps the grittiness and dirty look that makes Doom a much scarier game. Trying to pretty it up with OpenGL doesn't do it justice.
I couldn't agree more, it's just that working with paletted images is so damn annoying... Just when everything looks great, you convert to it to Doom's palette and what does it look like? It looks like garbage:
This is the only reason I am working on both GZDoom mods and ZDoom mods. Converting textures and sprites to paletted images and doing touch-ups is very time consuming.
Do you mean to tell me that your rainbow gradient sky that was obviously designed for a high color display mode.... doesn't translate properly into a palette that you did not take into consideration at all while creating it?
Well, I'm convinced. Paletted graphics are a horrible abomination.
Graf Zahl wrote:I merged in what you had here. I'll do a new release once Randy fixes the automap bug that got reported today.
Wow so quick . Thank you very much. And fullbright fog in "software" lightmode is a nice touch (but maybe it is not so good for map compatibility).
A list of bugs you may already know about:
Textured automap is fullbright in "Software" lightmode.
Weapon sprite is always fullbright in "Software" lightmode.
The constant to correct depth in the shader should be 232 instead of 192. I changed it to 232 in the newer versions of gzdoom-swlight but SVN has 192 so the lighting is too dark.
Dynamic lights make sprites fullbright in "Software" lightmode.
Also, I didn't report this back in the day but I think I should report it now: the lines on textured automap in OpenGL renderer are misaligned with the textured polygons.This bug was introduced with the textured automap. In swlight I hackfixed it by simply offseting all lines by one pixel (maybe it should be half...). (System: Core 2 Duo E6850; NVidia GeForce 8800 GTX; Windows 7; all games work; no OpenGL or Direct3D problems.)
Spoiler: Example screenshot (green arrows mark some of the rendering errors)
Now to palette discussion:
Woolie Wool wrote:
I think palettes can be a very powerful tool if you are conscious of your palette and preferably design it specifically for your mod. For Operation Serpent I made a new palette and every color was carefully chosen. A well-done palette that all your graphics adhere to is a great way to unify the art style of your project.
(my colormap kind of sucks though and it seems like it's not going to be possible to fix it without hand-tuning because the RGB algorithms that SLADE3 and XWE use are pretty dodgy and the CIE ones are worse).
Conclusion: palettes are good for art style but palettes suck when they become technical limitations.
Korshun wrote:A list of bugs you may already know about:
Textured automap is fullbright in "Software" lightmode.
Weapon sprite is always fullbright in "Software" lightmode.
The constant to correct depth in the shader should be 232 instead of 192. I changed it to 232 in the newer versions of gzdoom-swlight but SVN has 192 so the lighting is too dark.
Dynamic lights make sprites fullbright in "Software" lightmode.
The fullbright weapon does make things a bit odd when playing in a dark map. Overall, the effect is pretty good though and just comparing things by sight, it does seem to handle things pretty closely to the software renderer.
No, in SVN version the weapon is always fullbright regardless of light level and it is a bug. In software renderer (and my GZDoom version) weapon's light level is equal to the maximum possible on-screen light level of the sector you are standing on so the weapon is actually dark in darker sectors.
.
That's exciting news. And it's late here so I don't have time to build the recent commit. 
