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

I have recently, and will be for several months, been switching to a Pentium 4 Toshiba laptop with Windows XP Home SP3.

The problem is that, no custom engine i have tried (Aguirre's Enhanced GLquake, Quakespasm, ReQuiem, Fitz, Fitz Mark V ...) runs at all or runs even close to a decently speed in this computer, even before loading a map, i don't know if because of the age of the computer, compability reasons, or bugs (this last case probably not as i have tested in several engines). In case of Fitz and Aguirre's the video fails but the rest works, in the first engine the screen is black and in the second the console doesn't drop and everything is in a low color mode. Fitz Mark V won't even load. DirectQ gives me the same error as in almost any computer till now.

So far only WinQuake that comes with Aguirre's GL engine works (haven't tested the original one to see if its different). And thanks to this i am noticing how much we are depending on the added engines features, as my maps look so different now without them.

All the info i get from the engines besides Fitz, Fitz MArk V and AGuirre's is several warning messages about non-supporting several features or not finding certain things, the newer the version engine the more the warnings.

So the question is, which engine would be able to run well besides WinQuake, or what can i turn down in any engine (i use mostly Quakespasm)so it works good enough to play? 

Because of my work I use the NumPad a lot. So far only QuakeSpasm seems to allow typing in the console with it. An engine that has individual transparency for each liquid would also be welcome. 

More than likely the laptop's hardware is lacking, the video in particular. I ran Fitzquake on XP for years, but that computer had a pretty decent Nvidia video card. 

I remember Aguirre's engine and old versions of Fitz ran perfectly on much older rigs back then. 

What's your gpu? Got drivers installed? Try r_dynamic 0. 

Is a sure sign of windows software rendering, caused by missing or not-working graphics drivers.

gl_info in the quake console will print info on the driver being used, to confirm this

If you dont know the exact gpu model in that laptop, try the utility "GPUZ" which should tell you