Additional infos for OpenGL

Hi!

As freedoom will most likely be able to set some new standards, we could add some kind of OpenGL info lump. The most problematic thing for OpenGL currently are the colormaps. In my latest PrBoom OpenGL renderer colormaps are supported, but only the first row. If the colormap doesn't fade to black, then I can't reproduce it. I'm currently thinking about analysing the colormap, to find the color to which it fades, but it would be cool if the color would already be saved somewhere. Maybe level authors can think of more problems which might arise, which are similar to this.

Florian

i have been thoughting of this. most boom 242 colormap implementations in gl ports (i think this applies to legacy, zdoomgl, jdoom) are exclusive to the standard boom 242 colormap implementation. meaning, for example, in my level in progress, i could replace all instances of FOGMAP with 7F7F7FFF and it would look great in gl ports. but then it would be broken in boom and other software boom-compatible renderers. very poor foresight by the gl port creators.

then there's colormaps that use other things; prboomgl would be alright with the freedoom WATERMAP, REDMAP, BLUEMAP, and NUKEMAP or whatever theyre exactly called because all they are is different first colormaps but then they just fade that to black. (i'm not sure exactly what LAVAMAP does =D =D )

so i'm designing my level (singular but i'll probably make more freedoom levels, i like to do one at a time) to be 100% BOOM compatible per the word of the lord. if gl ports give me a way to implement their colormaps without breaking the lord's decree of 100% BOOM compatibility, i'll do it.

believe it or not i was also going to put this in my "random comments" just forgot about it too :)

What about an OpenGL colormap->color lump that would have a list of colormap lumps and their corresponding map colors? This could be useful to indicate to the port what color is wanted.

Yeah colormaps are a problem for GL ports, I worked on the EDGE implementation, and it was only simple : look up the row based on the lightlevel and figure out an overall color. Plus some colormaps can do things that GL ports have no way of emulating.

IMHO FreeDOOM should find/create some colormaps that work well in both software and GL ports, and limit levels to those particular colormaps.

Another thing is: should FreeDOOM include GL nodes ? Being the author of glBSP, I'm a bit biased :), but the only downside is that it makes the final wad bigger (roughly 15% IIRC). At least JDoom, PrBoom, Vavoom and EDGE can use the GL nodes.

Ajapted said:

IMHO FreeDOOM should find/create some colormaps that work well in both software and GL ports, and limit levels to those particular colormaps.

that would restrict us to only using COLORMAP. the various implementations vary and in general suck.

Hm well I've seen the colormap used for three different purposes

a) fog (or similar effect) - changing fade to colour
b) light-independant change - e.g. BLUEMAP, blue at all light levels
c) multiple fades at different light levels

c) I have only seen used once, in an inkworks demonstration, and I don't think its important to support since you can achieve the same effect now using two colormaps in the same level.

So some kind of lump that defined a fog-fade to, colour additive, and maybe a few other things like light strength or something for GL ports? It would have to be taken up by all boom supporting GL ports to be worth persuing. How many is that?

Jon said:

Hm well I've seen the colormap used for three different purposes

a) fog (or similar effect) - changing fade to colour
b) light-independant change - e.g. BLUEMAP, blue at all light levels
c) multiple fades at different light levels

c) I have only seen used once, in an inkworks demonstration, and I don't think its important to support since you can achieve the same effect now using two colormaps in the same level.

So some kind of lump that defined a fog-fade to, colour additive, and maybe a few other things like light strength or something for GL ports? It would have to be taken up by all boom supporting GL ports to be worth persuing. How many is that?

yeah c) is an oddball. prboomgl (according to proff) already supports the colormaps currently in freedoom as watermap, bluemap, redmap, and nukemap, because all they do is modify the 0th entry and then fade it all to black. other implementations already support fogmap, but in a way that makes it impossible to have software boom compatibility at the same time. so it's not like these features can't be supported by gl ports, a standard method just needs to be established.