PinkDot on 30/8/2013 at 15:50
I just came across this article today and thought it might be an interesting to some of you guys here. It's written by Sean Barrett - a programmer of the first - software (!) - renderer for Thief: The Dark Project and covers a number of technical aspects of the rendering engine. This is now pretty much historical stuff, but may be useful for those of you who are into a technical side of the game engines. There might be a few useful optimizing infos for level designers as well, for example why it's better to place torch completely inside a niche in the wall, rather than sticking out into a corridor and things like that. And you'll also find out why Dromed is such a nightmare to work with and why all these crashes happen at the portalizing stage... :)
(
http://nothings.org/gamedev/thief_rendering.html)
LarryG on 30/8/2013 at 17:49
I had run across that a year or so back and forgotten about it. Thanks for reminding me to reread it. It makes more sense the more experience I have with DromEd.
kdau on 31/8/2013 at 02:45
Unique, sometimes ahead of its time, sometimes behind, and always held together with a bit of duct tape. Yep, sounds like our engine alright. :)
I'm inspired to edit my optimise.cmd:
Code:
compress_br_ids
clear_surface_cache
play_schema m02creaks
optimize
halt_schemas
play_schema gar9910
;)
EmperorSteele on 31/8/2013 at 14:44
Heh, a lot of that is over my head. Not quite sure what part relates to "why it's better to place torch completely inside a niche in the wall", though. Still an interesting read, thanks for sharing!
PinkDot on 1/9/2013 at 20:55
Quote Posted by "EmperorSteele"
Not quite sure what part relates to "why it's better to place torch completely inside a niche in the wall", though.
It's in the 'Object Sorting' section.
Quote:
(...) However, sometimes objects would lie in multiple cells. (...)
Instead Thief had an entirely different, extremely expensive mechanism that it fell back on to solve difficult sorting problems. Each object could be "split" into multiple pieces, one per cell. In each cell, only the part of the object which was contained in that cell was rendered. This wasn't done by actually splitting the object, but rather by rendering it multiple times, once for each "piece", and for each piece dynamically clipping the object with a "user clip plane", (...) However, although it didn't increase the per-pixel costs, it required transforming and clipping the object multiple times, so it was rather expensive. (I encouraged designers to place their torches fully inside the niches instead
So, basically, every object that extends over a number of cells, gets rendered multiple times, in pieces.
----
Quote Posted by "kdau"
Unique, sometimes ahead of its time, sometimes behind, and always held together with a bit of duct tape. Yep, sounds like our engine alright.
Speaking of 'uniqness' and possible quirkiness of some of this engine's concepts - I still can't get a grasp of the 'bounding octagon' thing (as opposed to commonly used 'bounding boxes'). How does that look and what are the advantages? Pity there's not even a single image to ilustrate all the concepts in this article! To be honest, entire website is just ugly. Oldschool HTML style fro nineties... :) But the content is unique nonethless... :)
Ricebug on 1/9/2013 at 22:52
I'm always surprised at how game developers use horrible tools to create their magic. Robert Duffy was impressed with iD Software's Quake II, but its editor was a bare-bones POS. So he re-built Radiant's code. John Carmack was impressed sufficiently enough to being Duffy on board as their tools guy, writing programs to make life easier for the company's artists.
The programmers were using homemade scripts to get stuff done, all the while intending to incorporate them into the editor "when we get around to it." But since the money is in the game and not in the editor, they never found time and rolled with the paradigm.
If not for Le Corbeau and others, Dromed would still be cranky, broken and hard to live with.
