Also, I'd love to see any hardware, ever, where you can run at 2500 FPS. Optimizing is good; obsessing over it is not. 

Nice writeup, it all seems to make sense even though I don't have much to do with rendering stuff. For reference, it was fitzquake085 on the last map of The Five Rivers Land. Big wide arena mostly covered with torchlight and often a half-dozen dynamic-lit projectiles crossing it. Stuttering went away just by facing outwards, so I thought it must be a rendering thing. Quakespasm copes with it without the adverse reaction. 

Sometimes some newbie shows up and asks why "the Quake community" doesn't do X, Y, or Z like [insert other game, for example "like the Doom community" or "Quake 3"].

But there is no such thing as "the Quake community". Just different individuals of different interests doing stuff they want to do for free.

Its not like someone is demanding Barnak do this or that some Steam user must do this.

No --- because no one makes demands of free loaders and newbies and insists they must do things. 

Ah, I clicked submit instead of preview.

What I was trying to say that even a well-intentioned highly skilled engine coder diatribe about how things should work is still basically saying that someone else has to spend their time a certain way for free.

That point of view has merit.

And it is Tragedy of the Commons because such demands are only directed at the "top producers".

No one makes demands of noobs. 

In a commercial project that would be sold and generates sales, you'd be absolutely right.

In a free project that is a pastime, I don't know if you are right.

And one of the most important rules for a pastime is knowing it is a pastime.

And The Tradegy of the Common very much applies, you made an exit back in 2013 for this reason and I was already making an exit and once I saw you declare your exit, I left too. It was too much of an out-of-control zoo. 18 months later I'd come back -- sort of --- with firm boundaries in my head and communicate clearly the limitation of what I was willing to (not) do and when I was willing to (not) do it. 

MH's now dead engine, DirectQ, could easily clock 5000+ fps on an id1 map. 

I'm pretty sure that's true, no doubt about it.
Do we have, however, some kind of display who can actually show those 5K FPS?
That was really kind of my point. :) 

Here is a partial list of "blockbuster" map releases in the last few years:

a) A Roman Wilderness of Pain [aka ARWOP]
b) The Alter of Storms [aka ne_ruins]
c) Rubicon Rumble
d) Remake Quake

that will grind down to single digit frames per second in a traditional GLQuake style engines. But a DirectQ or FTEQW can instead of getting 12 fps will get 150 fps or 300 fps.

And these kind of mega-maps have been "the norm" in the last 5-6 years. There are plenty more where those came from. 

Whoa. Can they run on vanilla? I'd love to test them on a iPhone ;) 

a) requires enhanced network protocol (FitzQuake 666 or similar)
b) requires enhanced network protocol (FitzQuake 666 or similar)
c) requires BSP2 support, enhanced network protocol (FitzQuake 666 or similar) and should have alpha masked texture support.
d) requires the Remake Quake engine bundled in the download (BSP2, alpha masked texture support, Remake Quake's protocol 999, hurt blurs, other 2D effects) 

What kind of hardware is actually limited to low FPS in those maps? Laptops with Intel GPUs? No system I've played them on with Nvidia GPUs has had issues. 

With what engine? Quakespasm since late 2014 or thereabout has used vertex arrays so the performance is about triple the norm on maps with tons and tons of monsters. 

Usually Quakespasm. 

try them. fix stuff that doesn't work. job done.
its not like engines that support this stuff are closed source, so it shouldn't be that hard considering the stuff you've previously managed. 

Sample source code implementing protocol 666 download source

Every single protocol 666 change is marked with:

#ifdef FITZQUAKE_PROTOCOL

Yeah, every last change is marked. 

Do we have, however, some kind of display who can actually show those 5K FPS?

That's kinda not the part that's important; it's a bit of a strawman, in fact. As some of us have hinted, running DM3 at 5k FPS is actually not an interesting problem. Take 200 FPS: say someone has a 144Hz display and bump the target framerate to 200 to allow headroom for transient peaks. Running DM3 at 200 FPS isn't an interesting problem either. I'm pretty sure that even a low-end phone can do that nowadays.

Running a big, complex map with big, complex scenes at 200 FPS - now that's an interesting problem. You can solve anything if you throw enough brute force at it; but solving it on lower-end hardware too: even more interesting.

Historically the Quake engine was viewed as "can't do big scenes" or "unsuitable for open areas" but it turned out that none of that was actually true. It's obviously not the best engine for this kind of thing, but a primary cause of it's historical problems was in the implementation of it's renderer, and it wasn't too difficult to make the necessary changes to solve those problems.

So do that and what will happen is that running DM3 at thousands of FPS will also happen, but as a side-effect, not as the primary goal. 

1. per-texel lightmap blending?

How does quake's software renderer achieve per-texel blending? example

2. how and where in the rendering pipeline does "palettization" occur?

I assume that illegal colors are produced after a lightmap is blended with the diffuse texture? If so, my best guess is that palettizing is the last step before being drawn, though I have a feeling this is probably certainly wrong.

3. a practical way to achieve this look for a modern game?

Software render? GL render? GL render + GLSL shaders or some other form of post processing?

here is a screenshot palettized in photoshop. I'm currently using these janky mockups to help inform art direction. Obviously, this method is sub-optimal and I suspect this is not close to what an actual game renderer would output. It's a pain in the ass because this rendering style depends on an appropriate art style else it all turns to shit... hence the previous questions.

After spending months testing color palettes, I have a whole new level of respect for the id art team. Cramming quake in to essentially 240-ish colors is an art form in itself. 

I apologize that can't comment on any of your questions but I do have to say that screenshot is extremely fucking killer. 

I concur. Love the light design on the door and the left & middle monsters. Would be thrilled to see them in Quake. 

 

You're welcome. Are these for a Quake mod or a standalone project? 

unless the project dies, in which case the assets would probably be handed over to the quake community. 

You have a ModDB page or something for this project? I'd like to know more and keep myself informed. Perhaps send a PM or post in General Abuse? I don't want to clutter the thread with OT. 

for the first and second questions:

1. the lighting is blended with the textures in a "surface cache" which is in texture space so it's always 1 pixel per texel (rather than in screen space where one texel covers many pixels.) That's why you don't see banding that crosses over the middle of texels.

2. the entire renderer is 8-bit so it never has to be "palettized" at run time. 8-bit texture data is combined with light map data in a lookup table called colormap.lmp, where the resulting value is also 8-bit. So i guess it's the creation of this lookup table (shipped with the game) where the palettization takes place.

#3 is complicated an other people probably have better answers than me.