I don't think there are multiple systems. This would only come into play if there were multiple threads running at the same time. I doubt that the darkengine was written this way. Games usually aren't exactly because of this indermination.
It could be a challenge to reproduce certain bugs, that may sometimes be relevant, though.Even though they are charming, I know that we wont reproduce them in TDM, but I guess people will find other exploits in our engine.
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.Originally Posted by sparhawk
Heh? All the systems you mention update one by one after each other, each time a bit before the rendering of a frame starts (unless Thief has a seperate thread for all the systems, which I find unlikely). The fact you are unable to tell that at a reasonable update rate doesn't mean they are actually running at once.
The only things that can run simultaneously or effectively simultaneously are multiple threads; and even newer games don't employ that so heavily - for physics sometimes, and for background loading.
Identical Thief missions can and will behave differently depending on the CPU speed of the system that's running them.
Undeniable, incontrovertible, end of debate.
And that proves Thief has many multiple threads how...? Sound/physics/particle/lighting systems will have to wait for the renderer to finish even if they are multithreaded anyway (particle and lightning ones for obvious reasons; sound/physics engines cannot access the world data while the renderer is working, so they have to wait until the renderer removes the locking mutex); also why would anyone in their sane minds making these systems for thief multithreaded is beyond me. The control system being multithreaded won't get bothered by different CPU speeds. The AI system could possibly freeroam, but given the fact everything else will have to wait for the renderer to finish means it'll also have to wait too. Sloppy programming/weird bugs != multithreading.
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.
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.
I don't know why you people keep blathering about multithreading. I certainly mentioned no such thing.
Yeesh, if it's possible let them try it. If it isn't possible then it'll be a learning experience
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.
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.
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...
Last edited by jay pettitt; 9th Dec 2005 at 09:01.
You did.
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.
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.
Last edited by Assidragon; 9th Dec 2005 at 10:00.
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 Mind Master.
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.
HEY LOOK MOM I PLAYED ZYLONBANE AT HIS OWN GAME
I BET HE REALLY GOT A TASTE OF HIS OWN MEDICINE
No, you are wrong. It's not only to distribute available CPU power; it's rather to make the program work efficient, letting different processes work asynchronous so they only have to wait for a few of each other instead of running in a rigid scheme, and also lets different processes use more parts of the computer at once. like in modern games, the networking interface runs in another thread so it's not tied into the generic main-loop update, so it can receive or send packets faster instead of having to wait for say the renderer to finish drawing the current frame. Or to have the loading process in another thread, so the loading itself won't delay the rendering of the next frame, resulting in a much smoother background loading.
Since you apparently don't quite have a guess what is for what, let me use a short example.
Say someone makes a program in two variants. One that will has major parts divided into systems, and the other that has not. The two programs work exactly the same way aside from that.
Program A will do:
procedure updateFrame : draws frame
procedure updateSound : makes new sounds, stops old ones
procedure updateInput : takes user input
procedure updateAI : updates AI
so the main loop of A would look like:
procedure mainLoop:
updateInput
updateAI
updateFrame
updateSound
Meanwhile, B would not have all those nice systems only a main loop, which would look like:
procedure mainLoop:
update input
update AI
draw new frame
update the sounds
The first program has those systems, while the other has none such. You claim the system based approach would suddenly make everything appear to update simulatenously. Now, tell me why on earth should the system based approach look updating anything more simultaneous than the non system based one.
It won't be any more simultaneous. In case you failed to notice, even in the system based case, your main loop won't do anything else than update the systems one by one, after each other, only launching one when the other has finished or was interrupted. If you at least spent a few seconds thinking about it, that's ABSOLUTELY not different than from having other sets of commands updating every little part of the game, apart from being a lot messy. And that is the point of the game having divided into systems: to make it easier to write, see through and debug. Not to make various parts run "effectively simulatenous".
As for where is that quote wrong. Two points. First, indeed, the single core CPU will process ASM commands one by one (not counting multiple pipelines and other optimizations). However one command can range from a dozen to hundreds of ASM commands, which means that in a multithreaded environment, while a command from a process is running, another from another could just as well be executed. So you can easily have two commands running on the same time. This of course does result in weird bugs and unexpected/random results if not programmed with needed caution.
Secondarily, various threads will access and use various peripherials (soundcard, graphics, HDD, memory) that might take a while (like rendering a frame, or loading in a big mesh takes a long time). One great pro of multithreading - and running more threads simultaneously - is letting the use of these peripherials not block each other. This again can result in messups, and complicates debugging/reverse engineering.
If you mean Thief is split into systems for easier debug/programming then yes. If you mean Thief is split into systems for "effectively simultaneous" running, no.
It's possible Thief would monitor how long each update function takes, and shut down/change them depending on the elapsed time. But this is again based on a command/function/macro inside the game, and as such, inside the source code, and as such, reverse engineerable (even if would be painsticking).
Oh please. Effectively every application appears to run updates at once, until one clogs up the common update pipe so much you can notice it yourself.
ZB, jay pettitt - instead of trying to prove me there are programs that run commands effectively simulatenously without multithreading, get your obviously top knotch programming skills together show me one. With source code, of course.
There. From the perspective of the user, A and B are, for all practical purposes, being incremented simultaneously.Code:while(1) { a++; b++; print("A = " + a); print("B = " + b); }
Idiot.
LOL.
You call THAT effectively simultaneous? What program is NOT effectively simultaneous then? How does Thief being such complicate the attempt to reverse engineer it?
And lo, on the seventh day, the 45-watt bulb did verily flicker into brightness.
Newsflash: ZB categorizes every program ever written as effectively simultaneous!
For operations which need to appear as such, yes.
Y'know, at first I thought it was just the language barrier, but I'm starting to believe that you're genuinely stupid.
LOL! Apparently you are confusing something here. What you define here as "incremental simultanously" (whatever that is supposed to mena) is simple a lack of speed in perception. If the same program would be executed by a 70 year old computer, you could see the individual characters being printed, and no one would ever confuse it with simultanously.
Just because the user perceives it as such, doesn't make it so. After all the discussion was about the Dark Engine, not about how users perceive it. Of course games are designed such that everything SEEMS to happen at the same time, unless they are round based.
oh god.
'effectively simultaneous.'
For all practical purposes appearing to the user as though the various systems (physics, sound, input etc) occour simultaneously in 'real time'.
In relation to this discussion the precise technical nature of how the processes interact is not and never has been an issue. What is significant is that by appearing to behave simultaneously rather than in an obvious sequence it may make the job of understanding the order, priority and timing of the various little interactions that bit harder.
Yes, that's what the discussion WAS about, until a certain idiot decided that any reference to "systems" or "simultaneously" must be a reference to multithreading.
Posting Permissions
Reply With Quote