openDarkEngine - TTLG Forums

Domarius on 9/12/2005 at 00:55

I think it's premature to say that whole missions would break entirely if you don't replicate every single last quirk.

Maybe a conversation won't start at the right time, maybe some event won't be triggered - but they might be easy to fix anyway.

There isn't really any way to know what will happen till he tries it.

Personally I dont think the content of the original missions are very complex at all. Just simple concepts like zone triggers (walk into some place, trigger some converation script or sound effect, etc), conversation scripts, which are really just a sequence of "at this time, frob this, at this time, play this anim" etc.

In my experience it's only the very ambitious FMs that get into the buggy zone where they exploit features of the DarkEngine in ways they shouldn't to get some unique effect that wasn't in the OMs. Most FMs aren't like this.

Jonesy on 9/12/2005 at 01:18

Quote Posted by Mortal Monkey

It won't be done. Not because it can't be done, but because the creator will get stuck and/or bored somewhere along the way.

That's probably the biggest part of any mod/conversion/program, having the willpower to actually finish it.

It's not impossible to create an engine that runs Thief levels and resources, but it would be a helluva lot of work. Having the source would, of course, make the process easier. The Sith 2 engine team illustrates that with a dedicated fan base that actually does something, you can do it.

ZylonBane on 9/12/2005 at 01:57

Quote Posted by Assidragon

And that proves Thief has many multiple threads how...?

I don't know why you people keep blathering about multithreading. I certainly mentioned no such thing.

ascottk on 9/12/2005 at 02:09

Yeesh, if it's possible let them try it. If it isn't possible then it'll be a learning experience :rolleyes:

Volca on 9/12/2005 at 09:11

The engine is not, and can't even be, made that way, so it acts unpredictably.
This would disable the ability to debug. If there is a difference running on different CPU, this is caused mainly (if not only) by timing issues - e.g. what time does it take to render a frame. I can't imagine a reason a proffesional engine would be programmed in a way that it can't be easily debugged.

Also the systems in the game do interact, but in a way it is easily recognisable. There is no "great chaotic" behavior.

sparhawk on 9/12/2005 at 13:06

Quote Posted by ZylonBane

Uhhh... of course there are. There's the player input system, the AI system, the animation system, the lighting system, the physics system, the sound propagation system, the object management system, and lord-only-knows what other little things, all running effectively simultaneously.

These are all logical boundaries from the game engine design theory, but they are not reflected one to one on the physical implementation level. And I STRONGLY doubt that Thief uses multithreading for it's internal implementation for various reasons.

*) It doesn't make sense from the effeciency, because these threads would have to be synchronised. This means the whole system becomes less deterministic which is a VERY bad thing for ANY game engine.
*) It goes against everything I know of game engine designs. Even modern games don't really use multithreading, unless they support SMP, in which case it would make more sense. Most games still have their own kind of threads implemented within the game engine itself, and these are usually not concurrent threads.
*) Thief was designed to run on a rather low end system 233MHz at that time. This would add another complexity to a software that needs every bit of CPU speed it can muster.

I guess there are more, but I think these would be the most important aspects why I dont think you are right.

jay pettitt on 9/12/2005 at 13:45

Quote Posted by ZylonBane

I don't know why you people keep blathering about multithreading. I certainly mentioned no such thing.

Quote Posted by Spars

I STRONGLY doubt that Thief uses multithreading...
...I dont think you are right.

ZB is not arguing that dark engine multi threads or has been engineered to be unpredictable. ZB is arguing that Dark engine is a complex system where lots of little systems interact with each other. Not knowing the order or priority or timing of those little interactions may lead to some additional functionality. It's not hard, I'm a gardener and I seem to get it. Even you got it on the previous page. What happened?

--edit--
Anyhow, good show volca. Unfortunately my coding skills stop somewhere in the middle of javascript...

Assidragon on 9/12/2005 at 14:51

Quote Posted by ZylonBane

I don't know why you people keep blathering about multithreading. I certainly mentioned no such thing.

You did.

Quote Posted by ZylonBane

Then you should know that's it's virtually impossible to reverse-engineer the precise behavior of multiple systems that run simultaneously and interact in upredictable ways

Quote Posted by ZylonBane

all running effectively simultaneously

Simultaneous processes/systems is multithreading (for the simple reason one thread can not run more than one action at once, and to process more actions in the same time you need more threads, which is multithreading). But now I see you have absolutely no idea about programming and probably didn't notice you are talking about it.

Quote Posted by jay pettitt

Then ZB shouldn't say idiotic things like "simulatenous processes", which is more threads - there's no other way to understand that.

Complicated level of interactions can be found in any application; that's what makes reverse engineering without the source a long work. That does not change the fact that a non-multithreaded application (which I believe Thief to be) is nothing more than series of commands. No matter how many systems you have or how they interact, the basic fact is: you will have commands that call commands, in a set order. "All" that needs to be done is decoding the actual commands from x86 ASM to actual source, which needs (a good) understanding of the x86 ASM in Windows environment and a hell lot of time+determination.

ZylonBane on 9/12/2005 at 15:44

Quote Posted by Assidragon

Simultaneous processes/systems is multithreading

You are wrong.

Multithreading is a SUBSET of the available techniques for distributing CPU power. On a single-core system, as you should be well aware, only one "thing" is happening at any given moment in time (ignoring for the sake of the argument FPUs and the various pipeline optimizations on modern CPUs).

So the closest a single-core system can come to simultaneity is to do things so quickly that they APPEAR to be happening simultaneously. Multithreading is only one way to do this. Another way, a way that's as old as gaming itself, is to just call a whole bunch of subroutines (each subroutine handling a particular game SYSTEM) from a main loop.

This appears to be what Thief does. However, Thief also appears to implement a huge amount of self-adjusting optimization code to keep itself playable even on low-spec systems. This results in non-deterministic engine behavior based on CPU speed, graphics card speed, and the position of the Moon. For the canonical example of this, see Komag's (http://www.ttlg.com/forums/showthread.php?t=55335&highlight=mind+master) Mind Master.

jay pettitt on 9/12/2005 at 17:16

Quote Posted by Assidragon

Then ZB shouldn't say idiotic things like "simulatenous processes", which is more threads - there's no other way to understand that.

Yes there is. You can look up the word 'effectively' in the dictionary. You can try and understand context by reading the preceeding posts. You can also put the words in the right order. That would help.