Ugh... my bad. Should've launched Quake without mods at least once to create config.cfg in the ID1 folder... 

Who can I get in touch with for a one on one discussion of a rather big problem with Quakespasm, and how it affects an upcoming map of mine, and possibly other maps? 

You can find mail addresses in the readme. 

 

I just noticed that Quakespasm (and I guess quite a few engines) seem to ignore the colormap.lmp completely. What if someone wanted to make a TC with a new colormap to have new (maybe more, maybe less) fullbrights for example? 

As stupid as it is but files inside pak files have precedence over files outside. Try making a new mod directory and putting the colormap there, that should work. 

FTE peeks at the colormap to see how many fullbright palette indexes there should be, although it only works if they're contiguous from the end of the palette.
the rest of the file is really only useful to software rendered engines, and even then its often regenerated weirdly for transparencies. 

That is not that case with the original Quake afaik. That's pretty weird. /me tries 

Tried, not working. Quakespasm does not seem to read colormap.lmp files. Works in Winquake, so the file is not corrupt or anything. 

Am I then correct that QS and the like have some hardcoded stuff or something so that the lighting gradiates like in the software renderer? If there is something like that would it not be possible to allow for values to be read into that algo from the colormap? 

Am I then correct that QS and the like have some hardcoded stuff or something so that the lighting gradiates like in the software renderer?

Yes. It's important to know that historically, GLQuake didn't support fullbrights at all, so support for them in pretty much all custom engines has been added after-the-fact. 

What I am wondering is if you could not do it via reading out the colormap.lmp is all. 

Yeah, Quakespasm/Fitzquake hardcode the palette indices 224-255 as fullbright.

GLQuake/Fitz/QS use the opengl fixed function pipeline to combine textures with the lightmaps to produce the final image. This predates modern programmable GPUs, all it allows is telling the GPU to multiply the texture color by the lightmap to produce the final color, so there's no way to make use of the colormap.lmp lookup table. Nowadays, I think you could write something with fragment shaders that uses colormap.lmp. Not sure if anyone has done that though. 

Override the hard coded indices if a colormap.lmp is detected? 

Well, a colormap outside the one in id1/pak0.pak 

modifying Fitz/QS to read the number of fullbrights from the colormap.lmp (and not using it for anything else) is probably possible. I saw it discussed here: http://forums.inside3d.com/viewtopic.php?f=12&t=4247 

The standard quake colormap accomplishes 3 things:

1. force last 32 colors to be fullbright (but it could be different with a different colormap)

2. force the other colors to have 2x overbright lighting (but it could be different with a different colormap)

3. create a lookup table to find the correct palette index for the texture color + lighting value.

#1 and #2 are hard-coded into fitzquake based on the setup of the standard colormap. This means fitzquake assumes 2x overbrightening and the standard 32 fullbright colors.

#3 is irrelevant in a 32bpp renderer.

Of course there are all sorts of crazy effects you could do with a colormap, so no matter what assumptions the glquake-based engine makes, those assumptions could be wrong. For example, you could have colors that have an inverted lighting model (shadows would make them brighter) and you could have colors that change hue based on brightness (like orange highlights, blue shadows) And many other things. The only way to truly support those things is to write the equivalent of a pixel shader that uses the colormap as a lookup table. 

Then that would be the way to go, imo, just speaking as an artist here.

And I for one do not like to play with 32bpp because it makes stuff look washed out and bland. Keeping the original stepping of the colours used in the colormap makes things more contrasty as well as grittier and more surreal. It just is part of the feeling of Quake for me. With a pixel shader you could also have the added benefit of 32bit smoothness while still keeping the stepping of the colormap. So it't a win win I would say.

But I guess there would have to be some command for it that would deactivate the colormap, just to make sure, or of people want to use truecolour textures or something like that. 

New prerelease builds uploaded at http://quakespasm.sf.net/devel/

win32:
http://quakespasm.sf.net/devel/quakespasm-0.85.10-r980_windows.zip

win64:
http://quakespasm.sf.net/devel/quakespasm-0.85.10-r980_win64.zip

macosx:
http://quakespasm.sf.net/devel/QuakeSpasm-0.85.10-macosx-r980.zip

Linux users can checkout the svn and build for themselves.

Changes since the previous r958 test builds from Aug. 08 include:
FSAA support, fence textures support, brush model drawing speedup,
better cross-map demo playback support, and increased limits for
MAX_ENT_LEAFS (32), MAX_EFRAGS (4096) and MAX_CHANNELS (1024).
For more detailed list of changes see the READE file (or browse the
svn history.) 

Orl's test map is playable now :). Nice one.

Any likely/possible regressions with the new brush model code ? 

I tried the OS X version, and I don't see any FSAA option.
Where is it ? 

RTFM 

Though what bothers me a little is that the readmes are called README.* instead of quakespasm.* - with all the stuff in my Quake dir, I prefer it all easily recognizable (without having to rename the files with every new version I install). </Spirit> 

WTF!?

You shouldn't have to read a manual for a graphical option . It needs to be shown with any other graphical option in the interface.

This is nonsense ! 

I support negke's cause at least for "extract and go" packages. All files should have unique names.</honk>