EmperorSteele on 17/9/2008 at 09:04
I wanted to do a bump and ask a question:
Since you're writing a new engine, does that mean you're going to bypass/not bother with some of the original Dark Engine's flimsy limitations?
Like could someone make a scene with well over 2000 polys and not worry about graphic errors (which currently occur at exactly 1024 polys)? Could Dromeders make even more rooms, more lights, more everything? Now I don't imagine that resources would be infinite, but given how the average gaming PC has evolved over the last 10 years, isn't it about time that we should be able to stop worrying about whether a players field of view might contain (still) less polys than the average NPC in FarCry?!
Volca on 17/9/2008 at 09:45
Quote Posted by EmperorSteele
I wanted to do a bump and ask a question:
Since you're writing a new engine, does that mean you're going to bypass/not bother with some of the original Dark Engine's flimsy limitations?
Like could someone make a scene with well over 2000 polys and not worry about graphic errors (which currently occur at exactly 1024 polys)? Could Dromeders make even more rooms, more lights, more everything? Now I don't imagine that resources would be infinite, but given how the average gaming PC has evolved over the last 10 years, isn't it about time that we should be able to stop worrying about whether a players field of view might contain (still) less polys than the average NPC in FarCry?!
Yes, some, maybe nearly all limits, will be bypassable. You should be able to use shaders instead of plain textures even now. A plan exists to introduce resource override system so that any object/texture can be replaced by a highpoly version, etc. There is no 1024 polygon limit in openDarkEngine.
There are some limitations not likely to be easy to break, however: The portal visibility set calculations take some amount of time per frame, so more complex static geometry (terrain) is likely to induce the same performace hits as in original Dark, since the calculations done are nearly the same, for example.
New Horizon on 17/9/2008 at 12:22
Great work. :)
sparhawk on 17/9/2008 at 13:35
Quote Posted by EmperorSteele
Since you're writing a new engine, does that mean you're going to bypass/not bother with some of the original Dark Engine's flimsy limitations?
Like could someone make a scene with well over 2000 polys and not worry about graphic errors (which currently occur at exactly 1024 polys)? Could Dromeders make even more rooms, more lights, more everything?
The problem is that he is writing the new engine, not the editor. So if Dromed has the same limitations as the game (which I would think is the case, but doesn't have to) there is not really a way to create those extra rooms, even though the engine could handle it.
I don't know enough about Dromed, so it might be that Dromed has different limitations than the game itself. Depends on how it was written.
EmperorSteele on 17/9/2008 at 19:57
Eeehh, that's a good point =(
sNeaksieGarrett on 20/9/2008 at 01:57
well said, sparhawk.:) And for someone who doesn't know anything really about programming, that was a good way to explain it for us folks who don't know the technobabble....
Yandros on 20/9/2008 at 03:15
I'm not entirely sure that's true, although I'm far from an expert. Perhaps Telliamed or NV can drop in and speak to it. But my understanding has always been that Dromed uses Dark itself to render, so you should be able to, for example, exceed the poly limit and no longer blow up if you're using the new engine. So it may be possible to make use of some of the updates (poly limit) but not others (object or light limits) which could be hardcoded in Dromed. Although if we're doing this now, how long will it be before someone releases a patched dromed.exe with those limits removed? Never say never.
Volca on 20/9/2008 at 10:53
I think the truth is somewhere in the middle.
Tere is a different cause for every limitation. It could be:
1. Data format related
2. Run-time (speed optimization/limitation)
3. Fixed size of an array or a different structure
4. any other cause
The example could be the renderer, which has the polygon limit (runtime), light count limit (data format - WR has fixed count of records for lights), dynamic light limit (probably runtime). There also is the palette limit, which I don't know yet how much we'll be able to overcome, but till now we only needed to load palette for fonts.
Here: The light count is practically impossible to overcome with default engine. It is stored as a fixed-size array (bigger in T2/SS2, smaller in T1) of lights, somewhere after BSP in WR/WRRGB. Even though the definitions of object lights are also stored in the object tree, brush-based lights are only stored in WR (or so I believe, for stripped missions). What we could do is patch both Dromed and thief to store the array bigger, probably, but that would mean unpatched thief would most probably crash. Storing a copy of the light list in mission files would allow us to load greater amount of lights for OPDE, for example (if this is practical is another thing).
We'll have to look at every one of these limits, one by one, to see what we can do with them.
sparhawk on 21/9/2008 at 18:41
Quote Posted by Yandros
But my understanding has always been that Dromed uses Dark itself to render,
That's right.
Quote:
so you should be able to, for example, exceed the poly limit and no longer blow up if you're using the new engine.
Yes. *IF* you are using the engine. But Dromed is not using the executeable AFAIK. Even so, this new engine will be a new standalone application that can run original Thief missions, but it doesn't replace the original engine as in "swap the original". It's just a different executable that does similar things.
