Gain/loss pattern in some idtech engines

There has been an interesting loss/gain pattern in several id tech engines. Allow me to demonstrate. Keep in mind that the loss is small, but subtle.

"Catacombs 3D" to "Wolfenstein 3D"
Gain: VGA color, better quality audio
Loss: Higher resolution weapon sprites

"Wolfenstein 3D" to "Doom"
Gain: Angled walls and variable floor heights; overall higher level of interaction.
Loss: No movable sectors.

"Doom" to "Quake"
Gain: Fully 3D Engine and realistic lighting
Loss: Transparent textures (except for skies)

"Idtech 4" to "Idtech 5"
Gain: Megatextures
Loss: Dynamic shadows

I've thought about mapping for "Quake," and probably will regardless, but have been somewhat disappointed that potentially realistic but complex geometry such as trees could benefit from transparent textures, but will have to settle for solidity. The frequently static shadows in "Rage" will have to go if id is modifying idtech's code 4 extensively.

Share this post


Link to post

While they haven't used it themselves, you can insert the Shadowcaster engine between Wolf 3D and Doom.

Gain: varying light levels, varying wall heights, textured floors and ceilings, textured automap, destructible walls, floor effects, sloped ceilings...


(Also level scripting, hubs, flight, swimming, jumping, complex inventory system, simple RPG-like character progression, but I think those were sorely on Raven's side rather than already part of the engine Carmack gave them.)

Loss: No pushwalls, though it was probably not because of technical issues.

Share this post


Link to post

I think it was because of technical issues. I'm pretty sure variable height levels would cause some screw-ups in moving sectors.

Share this post


Link to post

Almost all examples you cite are a result of hacks applicable to older engines not really translating very well to completely different engines. The low Wolf 3D weapon resolution is perhaps the most inexplicable, but shoehorning yet another hack into an engine full of hacks was perhaps too much, even for the evil wizards at id...

Wolf3D's definition of a "sector" and the entire map data structure was simple enough to make them movable (did Wolf3D even use BSP trees?). And the movement was only horizonal anyway, more akin to Doom's object movement in increments of a blockmap unit.

Doom OTOH with its use of a strictly fixed BSP tree, couldn't afford to perform the equivalent function in real-time (there are ZDoom mods that feature moving sectors, but those insert a noticeable pause during gameplay to re-compute the BSP tree. This would plainly be unacceptable in 1993, and would add to the complexity of the executable, requiring the introduction of polyobject/scripting system. Not to mention save games...can you imagine the bugs this would cause?)

For Quake and above, I'm a bit surprised to hear that there isn't the equivalent of a masked (not truly transparent) texture. For that matter, Doom doesn't have proper transparent sprites or textures, either (not Alpha transparency, at least). Perhaps it's a technically feasible but not very used effect? Aren't there cage textures/walls in Quake already, even in official levels?

Share this post


Link to post

Valve definitely got masked textures working in Half-Life, but I don't think Quake or Quake 2's engines support them.

Share this post


Link to post
Maes said:

(there are ZDoom mods that feature moving sectors, but those insert a noticeable pause during gameplay to re-compute the BSP tree. This would plainly be unacceptable in 1993, and would add to the complexity of the executable, requiring the introduction of polyobject/scripting system. Not to mention save games...can you imagine the bugs this would cause?)

This is incorrect. ZDoom doesn't have moving sectors, just polyobjects, although they are more powerful than Hexen's original implementation.

Share this post


Link to post

GL versions of quake1 supported translucent textures/entities IIRC.

Share this post


Link to post

IIRC Quake sprites are masked and paletted pretty much like Doom ones. Air bubbles, explosions, sprite torches (optionally), and those weird balls in E4M6. I don't get how all you people haven't noticed any of those.
Also note that Quake's playsim code almost entirely resides outside of the engine binary in the form of precompiled QC library. A remarkable feature for those days, it made mod coding extremely easy, but in the end QC proved too slow for Carmack's standards and it was dropped in Q2.

Share this post


Link to post
traversd said:

GL versions of quake1 supported translucent textures/entities IIRC.


I assume the OP is talking about the original versions of the engines rather than what was added later or was added by third parties that used the engines.

For instance, Operation Body Count was built on the Wolf3D engine and featured higher resolution weapon sprites by making them out of two 64x64 (i.e making them 128x64) graphics instead of one like older games that used the engine.

Operation Body Count was in many ways ahead of it's time with a fully destructible environment (I suppose the tile based engine helped with that), controllable team mates etc.

Share this post


Link to post

I thought the original GL release was by id?

re: shadows in Rage. Is it that the engine cannot produce RT shadowing or just a decision to bake all shadows into the Rage content for performance purposes?

Share this post


Link to post

Speaking of Wolf3D's "moving sectors", I suppose they could be shoehorned into Doom in a similar way as sliding doors, had id wanted to, but their overall effect would not be too different than a normal rising wall-door, and would lack the smoothness of Wolf3D, due to the different way of obtaining the same effect (e.g. the sliding door code in Doom is not as smooth as Wolf3D...though I can't see why it has to be any different than texture scrolling).

Dunno, perhaps making a series of linedefs passable/impassable and walled/untextured, but without actually changing the BSP tree. This could even be emulated by a series of very rapidly dropping elevator sectors, or in the same way as the "swinging doors" mapping trick, giving the impression of a smoothly receding wall, at the expense of having a crapton of 1-px wide sectors...for that matter, they could've tried 1-px wide slopes, too. They didn't, and I'm glad for once.

Share this post


Link to post
traversd said:


Yeah, but Boom != Doom. Besides, the side-scrolling code in Doom (the vestigial one, that is) was nothing like this: it completed "sliding" in 4 frames, and the "door" was shoot through. That Boom example is much more refined.

Share this post


Link to post

Your point about the scrolling (versus the 4 frame animation) is what I was showing (albeit in boom yes). But I suppose in terms of making something work quickly that was probably going to be it - had they went ahead with it.

Share this post


Link to post

It's interesting how a moving vertical door (or height variations in general) do not affect BSP calculations at all -hence, this is why the first Doom edits, when BSP node builders were not available, had only sector height variations. They do affect REJECT map calculations, but that one is a totally different problem, an ill-posed one, at that.

But horizontal movement, even the slightest, is absolutely detrimental to the BSP tree, should the moving door be treated as an actual wall of the level.

Share this post


Link to post
MrrCaliber said:

IIRC Quake sprites are masked and paletted pretty much like Doom ones. Air bubbles, explosions, sprite torches (optionally), and those weird balls in E4M6. I don't get how all you people haven't noticed any of those.

I wasn't thinking of sprites myself, I was thinking of textures in the maps.

Share this post


Link to post
Maes said:

(did Wolf3D even use BSP trees?).

No, Wolf3D is strictly a ray casting renderer. Although I've heard that the SNES and derived ports (Jaguar, 3DO, and Mac) use a BSP to speed up calculations. I haven't poked through the Mac source to confirm though.

Share this post


Link to post

The pattern amongst idTech engines with regard to the implementation of scripting has been interesting to observe, as it reflects overall changing opinions in the industry about the relative advantages and disadvantages of dynamic code:

  • idTech 1 initial - NO scripting, so all game code is hardcoded.
  • idTech 1 later - Raven adds scripting to DOOM in a form that almost certainly later influenced QuakeC. Code is compiled to ad hoc bytecode that is interpreted at runtime.
  • idTech 2 (Quake 1) - Same type of system as ACS, but with significantly more power in the form of entity references.
  • idTech 2 (Quake 2) - Sudden reversal, with speed being stated as the overriding concern. Ability to script is replaced with native plugins (DLL/so) for game code, so it is still customizable, but not dynamic. Also a security concern, since native code can do anything.
  • idTech 3 - Loss of dynamism addressed with a sort-of trade-off - C code is compiled at runtime with a modified LCC compiler and the generated binary instructions are cleansed for security purposes.
  • idTech 4 - Suddenly another full scale reversal to a fully interpreted scripting system, now with a fully object-oriented language that marries state machine and model definitions with their implementing logic.
  • idTech 5 - ??? - dunno what it uses, but Carmack has made statements indicating that scripting has again fallen into disfavor with him, primarily because static analysis techniques and tools can't be applied to ad hoc scripting languages.

Share this post


Link to post

It's not really a "pattern". Different technologies just have different limitations.

Share this post


Link to post

I see you guys seriously kbnow what you're talking about, not like me, I don't know much about BSP trees and how the engine really works, but the way I figured out (only in my head, in my imaginary reality), that a BSP tree ends up performing showing the map represented on screen is that X and Y are actually how wide and 'deep into the screen' are the lines on the map, and then there's an additional bit of data that would be 'how tall' is the sector. that's it. you only draw straight lines forming poligons on the ground, and give them a height with that third bit of data, that's it. I see that's why moving sectors would cause so much trouble.

Share this post


Link to post

Re:scripting

I find it interesting how id has added/removed such a function overtime when the unreal engine has maintained it throughout (all?) iterations.

I know it is a hindsight thing, but the scripting could probably have stayed to some extent given the "performance" complaint was probably a non-issue by the time q2 etc was released (or shortly there after).

Share this post


Link to post

This has been a GREAT thread. I'm glad there are techies on the forum who can go into detail about this kind of thing.

Share this post


Link to post
fraggle said:

It's not really a "pattern". Different technologies just have different limitations.

Yeah it's too schizo to call it a pattern I guess :P The on-again off-again love affair with dynamic code - where it will end, nobody knows!

Share this post


Link to post

I think the problem with scripting is still the same: it's just not fast enough.

It may be fine the first time around when you try to make a game with a new engine. In this case the game will just be developed within the bounds of the new engine. Nobody will realize how the scripting imposes limitations. But the problems will inevitably show up if you want to make a 'better' game next time and the performance doesn't cut it. If you have to stay within the same limitations the new game won't show the needed improvement.

Then the scripted code gets reverted to native to gain the needed performance.

Of course dynamic scripting is better when it comes to flexibility so it'll probably make a re-entry sooner or later.

I think the best approach is to keep the core logic native and wrap a thin scripting layer around it. That way you won't lose too much performance. Doing the entire game logic in scripts like id did twice will probably yield the same results next time.

In Doom terms it'd mean that stuff like P_TryMove/P_CheckPosition is best kept native since that's among the most frequently called functions. No need to sacrifice performance here where the game spends >90% of its game logic time.

Share this post


Link to post

I wholeheartedly agree. The danger with any scripting language is defining its problem domain at such a low level that the script authors feel empowered to implement logic which has no right being implemented at that level.

The "pattern" evident in the id Tech N engines says to me that they've not yet found the boundaries of the problem domain.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now