Page 1 of 1

Any chance of brightmaps becoming compatible with SW mode?

Posted: Tue Apr 30, 2019 5:10 pm
by Da Spadger
I had this thought when trying to replicate brightmaps in a software-compatible way using A_Overlay. Is it as unlikely as it's always been or could it happen in the future? I figured it'd be worth asking in case the answer was "Oh that might actually happen", as implementing them properly would be much easier than my current method and unlikely to have unintended consequences. (Which has happened a few times during this little project)

Re: Any chance of brightmaps becoming compatible with SW mod

Posted: Tue Apr 30, 2019 7:54 pm
by Rachael
Never say never.

It's just that there have been much more interesting projects taking higher priority (i.e. Vulkan and the whole translation thing) and there will be others, too.

Re: Any chance of brightmaps becoming compatible with SW mod

Posted: Sun May 05, 2019 1:31 am
by Graf Zahl
Technically this is doable - the problem is more economical: In order to do this, the rasterizer has to read from two buffers, not one - making things quite a bit slower - and let's not forget - will require complete duplication of all software drawers to support the feature in all render styles. So far nobody has come forward to invest all that work for the software renderer.

Re: Any chance of brightmaps becoming compatible with SW mod

Posted: Sun May 05, 2019 5:19 am
by Marisa the Magician
Could one look into how crispy doom does it for reference?

Re: Any chance of brightmaps becoming compatible with SW mod

Posted: Sun May 05, 2019 5:52 am
by Graf Zahl
Sure, but that's not really the problem. I know precisely what needs to be done but to outline the task:

- the drawers need to be able to read from two textures
- they somehow need to blend the color from the retrieved info
- this needs to be done twice, once for brightmaps at the same size as the texture and one for different sizes (which will be VERY inefficient due to the high number of counters needed.
- all the above needs to be added to EVERY drawer routine - minus the sky - being used by both variants of the software renderer, i.e. softpoly and Carmack - and for both true color and paletted,

So the main problem is to find someone willing to DO it, not to find out HOW to do it.
Crispy won't really help here because its drawers are probably too different.

Re: Any chance of brightmaps becoming compatible with SW mod

Posted: Sun May 05, 2019 7:22 am
by Gez
Graf Zahl wrote:- this needs to be done twice, once for brightmaps at the same size as the texture and one for different sizes (which will be VERY inefficient due to the high number of counters needed.
It would be okay if the software renderer was restricted to brightmaps of exact same size.

Re: Any chance of brightmaps becoming compatible with SW mod

Posted: Sun May 05, 2019 7:43 am
by dpJudas
Honestly, at this point I'd personally rather spend time improving the hardware renderer with support for using palette textures and colormaps than add more drawers to the software renderer.

Right now the situation with software rendering is that Vulkan actually seems to perform worse than OpenGL. I have no idea how to improve this situation as it seems transfering data this large every frame isn't something anything after approx year 2000 was built for.

Even if this situation could be resolved the fact of the matter is that there's nobody left who can maintain the high level part of that renderer. Doom's modding history consists of 10 years of nasty early hacks of all kinds. Unless Randi returns nobody can fix those. At least I certainly cannot - I can't even figure out how to make skies fade correctly in all cases. The mess early Doom port writers left behind is too great. I'm sorry, nobody wants to hear this, but that's the situation today.

Re: Any chance of brightmaps becoming compatible with SW mod

Posted: Sun May 05, 2019 8:16 am
by Graf Zahl
And with that...


(moving to on-hold suggestions)