>> Some of us have actually looked at the colormap, we've analyzed the data in it, we've read the code that generates it.

And I actually made a few. And not by running an algorithm.

>> I've posted an example from row 6 above that you can look at and check; over two-thirds of the colormap entries for row 6 come from other rows.

I'm sorry, but you got it backwards. Row 6 is not a "recipient" in your example, it's a "donor".

Note how you painted it pink even in the middle, between the shadow part and the overbright part. The colors are supposed to be "raw" there, they can't come from other rows (unless there's something very wrong).

So yes, the colors are often mixed between rows. But not nearly as much as you think. If you examine pixel columns very closely, you'll see that the colors are often repeated many times. The darker (or brighter) the original color is, the less precision there'll be. 

A minor super8 update is posted that fixes HUD aspect ratio. A config is included for more authentic colors/lighting/hud. This shot from Tronyn's Jam2 entry shows both:
http://super8.qbism.com/wp-content/uploads/2015/02/jam2_tronyn.gif

The config is just:
sbar 2
sbar_show_bg 1
sbar_scale 0.7
r_light_style 0
r_fog 0
r_coloredlights 0
r_palette palette
v_gunkick 0
cl_bobmodel 0
cl_nobob 1 

It's not the colors painted pink that were supposed to come from outside the row, it's all the others.

The example is one of the more extreme ones. A good complementary example would be the red row. It barely has any "foreign intrusions"; the overall amount of unique colors in its part of the colormap is 23, which means a lot of repetition, but it looks very smooth nevertheless.

The point being that using half of the palette to shade one row is unnecessary, and is usually unintended. The reasons for it to happen I can think of:

1. The row in question lacks sufficiently dark and/or bright colors. You still have to shade it somehow, so the only option is to borrow from other rows.

2. The common ways of producing darker and brighter shades tend to mess with hue and saturation. Row 9 is a good example. The brightest colors lose the most saturation when darkened, hence the grey pixels.

3. The math behind quantization may suddenly decide that a color from another row is closer to the shaded color in question than any of the current row's indexes. The grey row is a perfect example.

Quake palette has a lot of similar hues, which means that a lot of colors are interchangeable between rows, so 2 and 3 are rather common. Doom palette has a lot of horrible examples of 1. Many games that I've seen avoid using the colors outside of their rows as much as possible (Strife being a notable example), but that requires less straightforward methods. 

4. When the artists feel especially artsy, they produce rows with inconsistent hue. Row 7 starts with reddish brown and ends with bright yellow. 

It even barfs on red colored lighting like a sw engine:). The lighting looks blended with the textures, especially in dramatic contrast areas. In GL the lighting can look airbrushed or too smooth when the lightmap ramp is steep. sw engines can run into banding here but it can be solved with dithering. Which in normal conversation seems ironic. 

It cheats when it comes to coloured lighting. It still has a 24bit colour framebuffer, so it just does 3 colourmap lookups instead of 1. This can result in different colour channels banding at different points.

The actual glsl code is here:
the EIGHTBIT define is true for colourmapped surfaces.
http://sourceforge.net/p/fteqw/code/HEAD/tree/trunk/engine/shaders/glsl/defaultwall.glsl

once you already have glsl in your engine, its actually pretty trivial to do this. just the 8bit texture loading, colormap loading (no header!), and glsl tweaks.
This would actually have been possible even without any engine changes, but would have needed lots of external textures+shaders. 

The only alternative to cheating on colored lighting AFAIK is a dither function. Can glsl do this? Otherwise banding/blocking is extreme.
I posted earlier about a hypothetical SW engine cheat that would use a bigger palette to expand colored light range. Because, well, modern 8-bit engines are FAKE, the output must be upsampled to 32-bit for newer graphics cards.
Actually mixing in a little dither for its own sake (if possible) might obscure that glsl cheat and look even more softwarey. 

Is it possible, using QC, to check whether the engine running supports partially transparent brush textures, so I can disable certain objects on certain engines? 

I know a few have tried tackling this problem before with limited success.

The Qc is basically scripting, and isn't good at requesting things from the multiple standards of engines.

Whilst its admirable to try and make your stuff run on many engines I've never really bothered. Making something good for one engine takes all my energy during a project and if its good enough then the other engine owners will want to support it anyway.

The risk is that it isn't popular enough and gets lost to redundancy, but considering the track record of Quake mods in general that's a rare occurrence.

Quakespasm is the best engine now anyway ;D 

You could just add a parameter to turn off all objects marked as X. And then provide the player with a number of different configs.

It'd still be down to them to use _software or _tenebrae or _darkplaces though. 

In that case, I think I'll just design to my engine of choice (which happens to be QuakeSpasm), and just make it very clear in the readme that this is the case. Setting out with this philosophy at least has the advantage that I can use QS features to their full potential, not to mention simplifying the design. 

Another problem is that QC runs on the server, which may be a different machine to the client (which runs the renderer), e.g for multiplayer games (which includes co-op).

Because they may be running on different PCs they may also be running different engines.

The only reasonable workaround I can think of is for the client to tell the server what engine version (or better yet, engine features) it uses during signon, and have that standardised as part of the protocol. 

mankrip is doing a Patreon: https://www.patreon.com/mankrip 

Resurrecting this chat from last december...

It could be that using md3 makes more sense than a MDL + new 16bit refinement format.

I could have a look at how difficult a minimal md3 implementation for fitzquake/qs/glquake would be.

There seemed to be quite a lot of "thumbs ups" when this was suggested. Just wondering what the mood is regarding adopting md3 as a standard, now it seems everyone's pretty much either using quakespasm or darkplaces... 

iqm? 

iqm is skeletal tho which limits the sort of animation you can do. 

iqm is easier to animate programatically, that is you can do ragdoll and separate legs/torso stuff. of course, this requires lots of extra logic, most of it as part of the gamecode.
if you think of skeletal formats as more limited, then you're probably stuck trying to animate with qme or something, which is going to be nasty when you get a reasonable poly+anim count, otherwise there's not much difference as you're positioning it all the same anyway.
md3 is simpler, but that's pretty much the only reason you'd bother with it, tbh (that and its simplicity meaning its more likely to already be supported in the more limited engines). 

this is not 100% correct.

when people say skeletal is limited, what they mean is that it is limited because the engine is limited.

of course, we are all animating with skeletal systems in max or whatever, but the skeletal stuff is maybe 80% of the stuff. the rest is animated with scripted things and/or vertex deformations. when those skeletal + vertex animations are collapsed into pure vertex animations, we get all the power of the 3d program in quake.

if we instead relied on the engine to move the vertices, then all we have is bare bones (haha....) skeletal only animations.

or you are faced with the prospect of assigning one vertex per bone and then trying to run deformations on the bone objects which most 3d tools are not natively meant to do, so it's just needlessly harder. 

In the modelling app I'd be animating bones to do most of the movement, but I'd also be using blend shapes a lot. 

Does iqm suppose vertex assignment to multiple bones? Because soft selection on bones is remarkably helpful in creating convincing anmations when you've got a low poly count... 

preach, yeah, 4 influnces max, like most skeletal formats designed for hardware acceleration. 

I noticed ezquake you can aim down straight to the ground. Is there any netquake engine that supports FULL (180 degrees) freelook in the same way as ezquake, besides darkplaces? 

quakespasm 

Silly me, didn't check that one. Thank you. 

I tend to do most of my animation worth with bones regardless. Blendshape support would be nice though but I don't know of any other format that we could snag for the best of both worlds. MD3 would be a massive improvement but with IQM you can animate at 10FPS and then get bone rotation instead of linear interpolation for vertex positions... makes for nice big sweeping motions with proper arch. :)