Doom Marine
Register | User Profile | Member List | F.A.Q | Privacy Policy | New Blog | Search Forums | Forums Home
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > Doom General > Gain/loss pattern in some idtech engines
 
Author
All times are GMT. The time now is 20:36. Post New Thread    Post A Reply
GoatLord
I really should think before I post.


Posts: 2774
Registered: 07-02


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.

Old Post 03-24-13 20:19 #
GoatLord is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit || Quote
Gez
Why don't I have a custom title by now?!


Posts: 11558
Registered: 07-07


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.

Old Post 03-24-13 22:42 #
Gez is online now Profile || Blog || PM || Search || Add Buddy IP || Edit || Quote
GoatLord
I really should think before I post.


Posts: 2774
Registered: 07-02


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

Old Post 03-25-13 00:31 #
GoatLord is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit || Quote
Maes
I like big butts!


Posts: 12877
Registered: 07-06


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?

Old Post 03-25-13 01:47 #
Maes is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit || Quote
Dragonsbrethren
Forum Staple


Posts: 2507
Registered: 03-09


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

Old Post 03-25-13 02:26 #
Dragonsbrethren is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit || Quote
zinkai
Mini-Member


Posts: 98
Registered: 05-09


There is glass textures in q2 if that counts?

Old Post 03-25-13 07:54 #
zinkai is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit || Quote
esselfortium
A Major Doomworld Concern


Posts: 6667
Registered: 01-02



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.

Old Post 03-25-13 07:58 #
esselfortium is online now Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit || Quote
traversd
Forum Regular


Posts: 671
Registered: 01-09


GL versions of quake1 supported translucent textures/entities IIRC.

Old Post 03-25-13 08:37 #
traversd is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit || Quote
MrrCaliber
Warming Up


Posts: 12
Registered: 04-10


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.

Old Post 03-25-13 09:22 #
MrrCaliber is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit || Quote
Vermil
Senior Member


Posts: 1746
Registered: 03-04



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.

Last edited by Vermil on 03-25-13 at 11:33

Old Post 03-25-13 11:26 #
Vermil is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit || Quote
traversd
Forum Regular


Posts: 671
Registered: 01-09


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?

Old Post 03-25-13 11:41 #
traversd is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit || Quote
Maes
I like big butts!


Posts: 12877
Registered: 07-06


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.

Old Post 03-25-13 13:13 #
Maes is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit || Quote
traversd
Forum Regular


Posts: 671
Registered: 01-09



Maes said:
though I can't see why it has to be any different than texture scrolling).


https://dl.dropbox.com/u/56320770/td-wolfdoor1.zip (boom side-scrolling door)

You jogged my memory of this - although I cant recall what the reason for creating/testing it was.

Old Post 03-25-13 13:45 #
traversd is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit || Quote
Maes
I like big butts!


Posts: 12877
Registered: 07-06



traversd said:
https://dl.dropbox.com/u/56320770/td-wolfdoor1.zip (boom side-scrolling door)


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.

Old Post 03-25-13 13:58 #
Maes is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit || Quote
traversd
Forum Regular


Posts: 671
Registered: 01-09


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.

Old Post 03-25-13 14:09 #
traversd is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit || Quote
Maes
I like big butts!


Posts: 12877
Registered: 07-06


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.

Old Post 03-25-13 14:25 #
Maes is offline Profile || Blog || PM || Homepage || Search || Add Buddy IP || Edit || Quote
Dragonsbrethren
Forum Staple


Posts: 2507
Registered: 03-09



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.

Old Post 03-25-13 19:46 #
Dragonsbrethren is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit || Quote
Blzut3
Member


Posts: 531
Registered: 06-04



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.

Old Post 03-25-13 21:00 #
Blzut3 is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit || Quote
Quasar
Moderator


Posts: 6175
Registered: 08-00


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.

Old Post 03-25-13 21:06 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit || Quote
fraggle
Filled with the code of Doom


Posts: 7830
Registered: 07-00


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

Old Post 03-25-13 21:59 #
fraggle is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit || Quote
pablogener
Mini-Member


Posts: 87
Registered: 11-12


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.

Old Post 03-25-13 22:02 #
pablogener is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit || Quote
traversd
Forum Regular


Posts: 671
Registered: 01-09


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

Old Post 03-25-13 22:09 #
traversd is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit || Quote
GoatLord
I really should think before I post.


Posts: 2774
Registered: 07-02


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.

Old Post 03-25-13 23:16 #
GoatLord is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit || Quote
Quasar
Moderator


Posts: 6175
Registered: 08-00



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!

Old Post 03-27-13 16:30 #
Quasar is offline Profile || Blog || PM || Email || Homepage || Search || Add Buddy IP || Edit || Quote
Graf Zahl
Why don't I have a custom title by now?!


Posts: 7793
Registered: 01-03


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.

Old Post 03-30-13 20:25 #
Graf Zahl is offline Profile || Blog || PM || Email || Search || Add Buddy IP || Edit || Quote
DaniJ
Senior Member


Posts: 2148
Registered: 08-03


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.

Old Post 03-30-13 20:57 #
DaniJ is offline Profile || Blog || PM || Search || Add Buddy IP || Edit || Quote
All times are GMT. The time now is 20:36. Post New Thread    Post A Reply
 
Doomworld Forums : Powered by vBulletin version 2.2.5 Doomworld Forums > Classic Doom > Doom General > Gain/loss pattern in some idtech engines

Show Printable Version | Email this Page | Subscribe to this Thread

 

Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is OFF
vB code is ON
Smilies are OFF
[IMG] code is ON
 

< Contact Us - Doomworld >

Powered by: vBulletin Version 2.2.5
Copyright ©2000, 2001, Jelsoft Enterprises Limited.