that assumes the mips in the bsp aren't "shoddy" -- do we know what method was used to create them? (obviously might differ between id textures and user-made textures) 

that assumes the mips in the bsp aren't "shoddy" -- do we know what method was used to create them? (obviously might differ between id textures and user-made textures)

qlumpy source code again; the GrabMip and AveragePixels functions (in quakegrb.c) show that it's just a simple averaging, followed by a nearest colour match, with some error diffusion mixed in at the end for non-fullbright texels.

An obvious risk with user-made textures is that the creator may have never bothered with making miplevels beyond 0. That's something that wouldn't show up in GLQuake and we all know that a lot of content was never even tested in software Quake back in the day (hence stray fullbright texels, bad overbrighting, etc). 

Software Quake lighting doesn't step down the palette indexes though.

Right, it uses the colormap ericw posted, which defines lighting per intensity and palette index as a lookup. And, in almost every case, the values present in that lookup are from the same palette row. That's all I meant.

Either way, shadows gain saturation because the darker values in the palette are more saturated.


Anybody know how Texmex generates mips? Since that's prooobably what everyone's using ... 

>> Either way, shadows gain saturation because the darker values in the palette are more saturated.

Not really.

But sometimes they have different hue (compared to the brighter colors of the same row). 

And, in almost every case, the values present in that lookup are from the same palette row.

Actually in most cases they're not.

Each palette row has 16 colours, whereas each palette entry in the colormap has 64, so straight away you can see that there's a huge amount that must come from other rows.

The darkest entries in each palette row also each have 64 lighting gradations, and because there's nothing darker in that entry's row the gradations absolutely must come from other rows.

By way of an example, here's a copy of the colormap with the 6th palette row entirely replaced with bright pink: http://imgur.com/5abrpMu

We can see that entries from this row are used in regions of the colormap that correspond to other rows, and we can also see how much of the region of the colormap corresponding to this row actaully comes from elsewhere in the palette.

As ericw has demonstrated above, the colormap is pretty much a straight line as it steps down, which is expected as the code that generates it uses "frac = 1.0 - (float)l/(levels-1);" to calculate the fraction of the base colour for a given light intensity.

What I suspect you're really seeing is that eventually each column in the colormap goes to palette row 0, i.e the greyscale row, so as shadows in software Quake darken they lose their colour too. 

i remember distinctly that the darkest non-black color is a deep red. You see it a lot on the edges of pitch black shadows in software mode. 

>> Each palette row has 16 colours, whereas each palette entry in the colormap has 64, so straight away you can see that there's a huge amount that must come from other rows.

Not necessarily from other rows. "Duplicates" (if you could call it that) are very common in colormaps. 

Not necessarily from other rows. "Duplicates" (if you could call it that) are very common in colormaps.

That falls down on two counts.

First of all, each palette row corresponds to (16*64 =) 1024 colormap entries, which would necessitate far too many duplicates.

Secondly, if you actually look at the colormap data itself you'll see that they mostly do come from other rows.

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. The same example can be repeated for every other row if necessary.

I'm not sure what part of this you're not understanding. Some of us have actually looked at the colormap, we've analyzed the data in it, we've read the code that generates it. We know what we're talking about and we're not talking theoretically. 

>> 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).