What is causing BengtQuake and FitzQuake to render things so differently?

STARTMAP in BengtQuake: http://www.saunalahti.fi/dnaumov/qecomp/start-bengt.png
STARTMAP in FitzQuake: http://www.saunalahti.fi/dnaumov/qecomp/start-fitz.png

DM6 in BengtQuake: http://www.saunalahti.fi/dnaumov/qecomp/dm6-bengt.png
DM& in FitzQuake: http://www.saunalahti.fi/dnaumov/qecomp/dm6-fitz.png

The screenshots were taken with exact same video settings and config, a lossless image format was used to avoid compression artefacts. 

timedemo demo1 results

bengtquake: 127fps
fitzquake: 196fps

"-width 800 -height 600 -bpp 32 -heapsize 64000" used with both, same video settings/config. 

I vote for the fitzquake look and fps.

Aguirre can't you combine efforts with metlslime to produce some ultra FitzaguQuake or something? 

I agree. Fitzquake has the nicest renderer around. Of course, your engine handles big stuff nicely (I'm guessing that's part of the reason for better FPS in Fitzquake), which is about the only reason I use it at all - It's good for testing broken maps.

I agree, maybe you engine coders (you, Tyrann and Metl - the ones concerned with useability and not implementing fancy effects*) and produce an uberengine?

By the way, is it possible to support two protocols in the same engine? For example, when loading a map start with the regular protocol, then if the map seems to be too big, cancel and reload using the more hardcore protocol. This would benefit from a widemap console command to load a map straight into the hardcore protocol. Sorry if I keep saying "hardcore", I can't think of a better word right now.

I dunno if you or metl already have this in your engines, but how about a console command to execute triggers? "trigger targetname" and "killtarget targetname". If it's an easy thing to add, it would be quite handy on occasion.

*note: I am not against Darkplaces etc. There are people that want to use them, but I'm not one of them. 

First, fitzquake has 2x overbright lighting on both lightmapped polys and .mdl models. You can see that my zombies are brighter, and you can see brighter highlights on the white pillars and on the wall above the spikes. The default glquake lighting flattens out those hotspots.

Second, you ran fitzquake in 16bpp mode, and the bengt shots are in 32bpp. The sky texture is a giveaway becuase it's got an alpha channel, so instead of being 5-6-5 bits per channel like the other textures, it's 4-4-4-4. You can also see that the fitzquake shots are dithered, which some cards do when rendering in 16bpp.

Third, fitzquake has fullbrights (check out the red crosses on the health packs.)

Fourth, fitzquake doesn't mipmap the water textures, so the teleporters looks sharper.

Fifth, fitzquake doesn't do anything to make torches look brighter, instead it just lets the texture's fullbrights do the job, so the torch models look a bit different as a result.

Finally, the colors look a little more saturated in the fitzquake shots, but i can't explain that. Unless the gamma correction was done differently. I don't think it can be explained by the different bit depth. 

especially the lighting.

BUT, aguirre's engine is actually closer to how standard, default gl quake looks. 

i use joequake... but is always god to see clients to be upgraded!

good work ;) and yes i already use bengtquake :) in tronyn map i use it! 

well of course, but glquake is sort of an ugly approximation of winquake, which is the renderer i'm trying to emulate. 

Especially because my map only runs in bengtquake right now, but I'm sure it would look deliciouser in fitzquake. 

the maxed limits should be toggleable, though. 

Sorry to rant but:
I don't understand why anyone would specifically leave this feature out. It was planned in quake from the beginning, only id glquake and glqwcl until fuh-gl 2.2something didn't have it because of some old voodoo1 hw limitation / code oversight, and it was ugly as hell. Idbase lights in the dark were fucked, the red metal rune decors in dm2 were fucked, health boxes, whatever, you name it...

Plus nowadays it can be done with external textures too (lumas or something), and the external textures have been made accordingly. 

Although I'd like this thread to be less about "My engine is better than your engine" or "Why FitzQuake/DarkPlaces/Telejano rulez" and more about the actual new features of my tools/engines, I'd like to address a few things. I will use the term other engines, which basically means any other Q1 engine.

1. Speed: You should find that in most real scenarios, my engines are often faster than other engines and this means loading, playing, demos, etc. If you use similar settings (although this is not always possible) or a clean start (no autoexec/config, only the same simple cmd line), my engines are often faster.

This applies to both small and huge maps with few enemies or hordes. When other engines actually are faster, it's usually in certain special cases (e.g. unvised huge maps with no monsters). I can't of course speak for any graphic card/driver combination, but on both my systems (ancient Voodoo2 and more recent GeForce3) this is true. Especially since many engines don't even run on older systems - mine do and run well.

2. Rendering: As this is usually extremely opinionated, I'll first state that I don't think software renderers (like pixellated DOS/WinQuake) are interesting to imitate in any way and this includes the ancient fullbright pixel handling. It was how Quake originally looked in the very beginning, when nothing else was possible. The palette and memory was limited, speed was at a premium (486 computers with only VGA) and players weren't really used to anything better.

id probably tried to spice it up as it otherwise would've been just different shades of green/brown as many critics also complained about. Today, I don't think it is relevant at all to compare with an engine that's seriously slow, pixellated and has horrible banding in any lit area. Also, having brightly lit (or even always fullbright) models may be useful in DM, but looks terrible in SP and other engines render models way too bright.

The fullbright pixel handling on models/textures can actually look nice (or at least interesting) sometimes, when it's used for making self-lit objects like flames/torches/plasma brighter, but it's awful when the overall result is garish day-glo. Especially in the Quake world, where except in the base style, most things are supposed to be old stuff and not self-illuminated wall panels that are taken from some Sci-Fi setting. Even in the base style, the plastic red/green/blue details look toy-like and out of place. Not to mention the awful fullbright spots on textures that haven't been "prepared" to work in engines with fullbright pixel amplification ...

3. Playability: This is maybe the most important aspect of engines; if you can't play the map, it really doesn't matter how it looks or how fast it crashes. Compatibility, capacity and robustness are the key words here and those are the exact goals for all my tools/engines. Any standard Q1 map should be loadable and playable and while I can't guarantee that for obvious reasons, I can safely say that all my engines are regularly verified to work with about 5000 Q1 maps; DM/SP/TF/CTF and singles as well as PC/TC paks. And even if I'm not a DM player, bot play has been extensively verified in high energy situations using most of the known bot paks.

Other engines just keep on crashing; if they can actually load a map, they'll usually fail later either by misbehaving (e.g. not displaying or even including! all entities) or die stuttering by choking when the heat turns up. Again, all my engines are verified to work in the most extreme nightmare scenarios, with huge maps and hordes of active monsters. Like everything else there are still limits, but they're all tuned to work together and with reasonable results on today's (and yesterday's) computers.

Since my engines are actually used for playing (as opposed to some technical ecstasy showcases), they have also encountered and been fixed for numerous gameplay issues that in other engines will just throw the player out of the game, disrupting the experience.

4. Reliability: This is of course closely related to playability, but this also applies to using the engines for developing and troubleshooting maps or QC. As most development is error-prone at one time or another, it's vital that you can rely on the engine to help you locate the cause of the problem and not just crash without any message. This has also been a major design goal in my engines and while I'm sure they still have many bugs, they're far more reliable than all other engines.

Hopefully, this explains some of my motivation and stance regarding the tools and engines. But again, I'd really like this thread to offer feedback or opinions on the actual new features of my tools/engines update, not just another pointless trench-trudging engine flame war. 

I'm surprised that you don't like fullbrights. I respect your opinion, but I think some of your reasons are not right.

It's not a trick. Their whole idea that the surface is emitting it's own light, hence it's always the same brightness regardless of the light falling on it. Besides being realistic, it often looks good to have these faintly glowing things in a dark setting. When I mentioned tech textures, I was mostly thinking about the yellowish-white light panels. And if a mapper thinks the fb looks bad, he can always use other textures which don't have fullbright places, or use more light in the area, which damps them.

I don't want to flame, but I wonder: if id / Carmack had bothered to put the correct fullbright feature into glquake, I believe we wouldn't be having this discussion...

I appreciate your efforts of doing a robust and solid client, I use it often too, especially when other clients fail. I'm not after modern eye candy addons etc.. 

i built a map... it had about 3.5k monsters in it with a special progs so that they would start fighting any monster not of the same class...

was quite fun watching that without stuttering or sound cut off. :P~~

maybe i'll record a .avi of it. ^_^; 

which monsters would these be? Do we have another candidate for the assault on Olos Khommor? You know I like it when you do the avi thing :P

Actually, there's some other things I wanted to discuss; get on the hotdog if you have time. 

i started playing WoW again. :(

that game never truly lets you go. :P 

I hope you didn't take my post as a criticism of your work; i was just trying answer the question of why the engines looked different in those screenshots. I do think your engine provides a valuable service for loading problem levels and mods. Keep up the good work. 

I wasn't saying your engine was bad/worse than fitzquake either. I think you engine guys are doing great work. I'm just sad that I can't have the best of both worlds - the appearance of software quake at high resolution (seriously, what crack are you smoking when you think GLQuake looks better? Sorry, that is flamebait, ignore it :) and the behind the scenes power of your engine.

Just a quick pointer about GLQuake vs WinQuake. I am no coder, so I don't know if this is true, but I suspect that if adding overbrights and fullbrights was a trivial thing and didn't require a second pass and severe performance hit on the early 3d cards (i.e. Voodoo) then Carmack would have implemented those features. There are tons of other reasons that I and many others dislike the look of GLQuake (aside from the washed out lighting), such as sparklies (more or less fixable with some cvar changing I think),broken waterwarp, dodgy particle blending (from what I rememeber), slow ass sky rendering, messy fluid texture rendering... There were also useability problems that have all been eliminated with most of the custom engines.

Also, some maps look shit with fullbright because the textures were not converted correctly (i.e. they were converted for glquake, which didn't support fullbrights, so the fullbrights were used as standard colours). Most modern maps have non-fucked textures with either no fullbrights, or fullbrights in the proper places. The id maps obviously were designed with fullbrights in mind, and thus there are runes glowing in the shadows (dm2 is a good example of this) and it looks good.

Btw, model interpolation is cool, although it's something I am happy without in Fitz. I find it looks weird when everything moves smoothly after 10 years of 10frame per second anims :)

Couldn't post this in Opera :( I hope the recent func problems can be fixed easily - it's been a bit annoying lately. 

I'm not going to argue Fitz vs Aguire - they're both excellent engines, but I do wish that they'd both get around to fixing the GLQuake 'console flickering' bug that makes GlQuake unplayable on my Intel GMA 900 integrated vid card.

(Well, almost unplayable, unless I use inferior engines like ToChris or Darkplaces that actually fix this bug.) 

While I appreciate FitzQuake immensely and agree with most of metl's choices in terms of visuals, aguirRe's engines are an invaluable tool for anyone developing a large Q1SP map. He just keeps pushing the limits and from a mapper's perspective that's a beautiful thing. 

...is an absolute must have in my Quake folder since the increased limits make almost any bsp run. It also can dump out handy information that I can use to bring down limits in my maps such as clipnodes, bmodels, lightmaps, etc. It has great debugging features. I rely on it for my mapping project since I horribly abuse standard map limits but I am making sure all my projects run in FitzQuake before calling them done.

It is very stable and reliable and it replaces GLQuake for me. 

fitz is my general engine of choice, whilst aguires engine is the one I go crying to if I have any serious problems :) 

The -nehahra support for the winquake.exe and glquake.exe is very interesting. That's the first time I've seen Nehahra in software in a very loooong time... it brought me back to some old very good days... early days... Of course, the stuff that is supposed to be transparent looks awful.. but a version that simply removes transparent brushes (and does a few other little things).. not to mention doesn't call a lot of cvars not present (which gives those UNKNOWN COMMANDS). Watching the demos in software... weird! I presume you could watch The Seal of Nehahra on the thing. To see that in software would be freaky for sure :)

I do enjoy software.. when I'm in the mood for software and some nostalgia...

However... heh... I don't dig GL engines that attempt to emulate software *much* (to offer the dissenting opinion which has just as much presence as the former but is too seldom voiced.. we're like the quiet Democrats while the Republicans run their mouths and sometimes even grab bullhorns).

A monkey that acts like a man may be impressive, but a man that acts like a monkey is a degenerate (not to mention embarassing).

I don't dig the lighting on models that makes them brighter than the surroundings, causing them to stand out more, whereas in Bengt engines it is smooth and visually correct.

I am of the same opinion as Bengt on Fullbrights and I needn't echo.

I'm likely inviting great harassment with what I'll next say, but overbrights fall under the trivial category as far as I'm concerned. I can take 'em or leave 'em. I've gone back and forth with RPG on the subject. He demonstrated with two screenshots showing the difference between overbrights and no overbrights. Yes, I did see the difference between the two, vaguely, more so when I looked at the two shots side by side, but I failed to see what was so earth-shattering. It is not as if while playing a map I would stop and say, "Wow, look at that overbright lighting." A mapper would do that. Mappers obsess about these things (often I believe *gulp* unnecessarily). A player who happens to be a mapper might. I cannot claim to think like a mapper. Though I've tried my hand at mapping on a number of occasion, I cannot call myself a mapper either. But I sometimes consider this an asset as it offers a degree of impartiality. I can look at things from different angles and compartmentalize each filter I run my perception through). I play like a player and think like a player. What do I not really notice or give much attention to as a player? Overbright lighting. Hence: I consider it trivial (though I prefer no overbrights and I admit that I shut them off in Fitz... because there's a thin line between emphasis in lighting and contrast which distracts from the game... which is what most players are there for... the game.. killing stuff...)

Big maps: yeah baby.

Speed: One of the most important ingredients. The Bengt engines, even the original nehahra engine and perhaps the dpnehahra.exe, practically laugh off high r_speeds and huge epoly counts. One significant factor in Nehahra not quite agreeing with a lot of other engines, ESPECIALLY now with the new monsters in, is the engines just can't handle it. It can't handle the high polys of some of the more detailed models.. at least.. when they're in bulk. Once those epolys fly up into the stratosphere and you've got heavy action going on, most engines bog down. Some die. Some crash hard (send some Get Well letters, boys and girls, but you'd best put a lot of postage on them, because it's a long journey down to Hell where those engines tend to land.)

Transparency: This is only implemented in Nehahra and DP as far as I know.. maybe someone else squeezed it in... But the potential for its use is fantastic. I am absolutely surprised that more people do not rally for it in engines. What excuse might one have not to?

Lastly.. model interpolation... what can I say on that other than it's impossible for me to step back. You become accustomed to everything so smooth. Loading up an engine without it where the models seem to blink in and out of existence with every move is very near to offensive. Unsightly to my eyes. In software, I expect it (and somehow doesn't bother me.. I expect because it isn't in anachronistic contrast to the GL environment around it as is the case with GL engines without interpolation, IMO).

Just an opinion. Grain of salt all around.

Keep up the good work, Bengt. 

The -nehahra support for the winquake.exe and glquake.exe is very interesting. That's the first time I've seen Nehahra in software in a very loooong time... it brought me back to some old very good days... early days... Of course, the stuff that is supposed to be transparent looks awful.. but a version that simply removes transparent brushes (and does a few other little things).. not to mention doesn't call a lot of cvars not present (which gives those UNKNOWN COMMANDS). Watching the demos in software... weird! I presume you could watch The Seal of Nehahra on the thing. To see that in software would be freaky for sure :)

I do enjoy software.. when I'm in the mood for software and some nostalgia...

However... heh... I don't dig GL engines that attempt to emulate software *much* (to offer the dissenting opinion which has just as much presence as the former but is too seldom voiced.. we're like the quiet Democrats while the Republicans run their mouths and sometimes even grab bullhorns).

A monkey that acts like a man may be impressive, but a man that acts like a monkey is a degenerate (not to mention embarassing).

I don't dig the lighting on models that makes them brighter than the surroundings, causing them to stand out more, whereas in Bengt engines it is smooth and visually correct.

I am of the same opinion as Bengt on Fullbrights and I needn't echo.

I'm likely inviting great harassment with what I'll next say, but overbrights fall under the trivial category as far as I'm concerned. I can take 'em or leave 'em. I've gone back and forth with RPG on the subject. He demonstrated with two screenshots showing the difference between overbrights and no overbrights. Yes, I did see the difference between the two, vaguely, more so when I looked at the two shots side by side, but I failed to see what was so earth-shattering. It is not as if while playing a map I would stop and say, "Wow, look at that overbright lighting." A mapper would do that. Mappers obsess about these things (often I believe *gulp* unnecessarily). A player who happens to be a mapper might. I cannot claim to think like a mapper. Though I've tried my hand at mapping on a number of occasion, I cannot call myself a mapper either. But I sometimes consider this an asset as it offers a degree of impartiality. I can look at things from different angles and compartmentalize each filter I run my perception through). I play like a player and think like a player. What do I not really notice or give much attention to as a player? Overbright lighting. Hence: I consider it trivial (though I prefer no overbrights and I admit that I shut them off in Fitz... because there's a thin line between emphasis in lighting and contrast which distracts from the game... which is what most players are there for... the game.. killing stuff...)

Big maps: yeah baby.

Speed: One of the most important ingredients. The Bengt engines, even the original nehahra engine and perhaps the dpnehahra.exe, practically laugh off high r_speeds and huge epoly counts. One significant factor in Nehahra not quite agreeing with a lot of other engines, ESPECIALLY now with the new monsters in, is the engines just can't handle it. It can't handle the high polys of some of the more detailed models.. at least.. when they're in bulk. Once those epolys fly up into the stratosphere and you've got heavy action going on, most engines bog down. Some die. Some crash hard (send some Get Well letters, boys and girls, but you'd best put a lot of postage on them, because it's a long journey down to Hell where those engines tend to land.)

Transparency: This is only implemented in Nehahra and DP as far as I know.. maybe someone else squeezed it in... But the potential for its use is fantastic. I am absolutely surprised that more people do not rally for it in engines. What excuse might one have not to?

Lastly.. model interpolation... what can I say on that other than it's impossible for me to step back. You become accustomed to everything so smooth. Loading up an engine without it where the models seem to blink in and out of existence with every move is very near to offensive. Unsightly to my eyes. In software, I expect it (and somehow doesn't bother me.. I expect because it isn't in anachronistic contrast to the GL environment around it as is the case with GL engines without interpolation, IMO).

Just an opinion. Grain of salt all around.

Keep up the good work, Bengt. 

hm, seems like everyone�s arguing about how many angels can dance on the head of a pin.

True, some engines do other things better but at the moment the previous engine from Aguire is my engine of choice and the one I use most often. This is because I know maps will run on it, no matter how complex / spacious. My other favourite is darkplaces (the blood! and game speed - 1.25 my preference) but the sad fact is that some maps will not run or else experience problems.

As to the fullbrights - useful, yes, and it takes a mapper who wants to remove thier effect for whatever reason about two minutes (granted PS (or image editor of choice) is needed as well but it�s not difficult)to change it. I for one like fullbrights as certain effects are highlighted by them, though they do have thier (limited) place it�s true, 99% of the �normal� players out there will never notice the difference - only the people (such as myself) who take a game this old extremely seriously and still allow it to eat huge quantities of thier real life (tm) . . .

Now I tend to prefer building a level than playing it (ok, and playtesting it) and so whenever I try an engine I think ok, it does this (insert cool_feature); how can I use it?

Granted Aguire�s engine doesn�t have the bells and whistles of some of the others but it seems like "running reliably, any conceivable type of map" has been discounted by most as not a special feature. It�s a feature because most other engine�s can�t do it, just because you don�t notice it as a feature doesn�t make it less valuable.

>rant finished<