Things that are wrong with GLQuake

[mh]

Let's have a central clearing house for things that are wrong with GLQuake. By keeping all of this info in the one place we can get a good resource for anyone working on an engine project, and may even uncover a few things that are not common knowledge.

I don't mean the visual aesthetic part. We all know about fullbrights and overbrights, and has already covered those. It could even be argued that they're a matter of personal preference. Let's get a bit more under the bonnet here.

We shouldn't assume that "because Carmack did it, it must be Good and Right". It was his first commercial and publicly released OpenGL app after all, and he was still learning at the time.

I'll start. R_DrawSequentialPoly - it's evil. A bunch of state changes, texture changes and enabling/disabling TMUs for every surface that is drawn. Far better to make a multitextured equivalent of DrawTextureChains, or even to disable multitexturing.

[Spike]

modern gfx cards support npot textures properly. glquake naturally couldn't use it at the time, resulting in alwardly resampled images.
another thing wrong with glquake - it uses too many globals. but then so does sw rendering.
The meshing code sucks too.
Skingroups are foobared.
Lots of software code completely duplicated, even with no significant changes.
Not all sprite types are supported.

[leileilol]

Flashblends defaulting on, but that's understandable at the time in mid-1997, texture upload performance sucked for everyone

Console scroll speed when closing seems a lot slower than software

Texture mismatch crashes going from maps with different textures on same names is fatal.

White skins when there's no skin found out of range of available skins is bad for heads

[Ranger366]

[Sajt]

This is something which affects software engines too. It resulted in very hard to debug glitches when I was playing with a mod that used a lot of lightning. The fix:

[frag.machine]

Here my 0.02$ about this.

Let's stop trying to fix Quake. It's a 14-year old dog. Instead, let's create a new engine from scratch. It's the next logical step to take now.

We may support to read the older file formats and convert them, in memory, to more modern stuff. Or, better yet, we can write a bunch of tools that read a .pak file and convert its contents to more modern stuff, and forget forever about mdl or wad2.

With a new engine, we can learn from the mistakes in 3 engine generations and select the best solutions. No more global pointers, no more static arrays, highly modularized design with low coupling, etc.

With a new engine, we can finally consider possibilities like efficient outdoor rendering support, PHS, more than 32 players, Q3-style shaders, ability to switch between OpenGL and DirectX, etc.

[Ranger366]

[mh]

There are a few reasons, but the biggie is that nobody is ever going to agree on a way forward with a clean sheet of paper design. We've seen this before every other time, and there's no cause to suspect that things would be any different now.

So why Quake? For some of us the engine is a means to an end rather than an end in itself, and Quake-The-Game is what matters. A good engine serves to help them achieve that end better. For others it's like that beat-up Oldsmobile that you love tinkering under the bonnet of. Let them soup it up, add new sparkplugs, etc. For the more reactionary retro-junkies all time and history stopped in 1996, and anything more recent gets a rather firm "la la la can't hear you" back at it.

TBH unless you fall into one of those 3 categories (or something similar) you may well ask valid questions, but I don't think you're in the intended audience of this thread.

Me, I love my 14-year old doggie.

[frag.machine]

[Ranger366]

[Spike]

[Ranger366]

[Spike]

[Ranger366]

[leileilol]