Assidragon on 9/12/2005 at 17:52

---

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.

Assidragon on 9/12/2005 at 17:58

---

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?

Assidragon on 9/12/2005 at 18:22

---

Newsflash: ZB categorizes every program ever written as effectively simultaneous!

:rolleyes:

sparhawk on 9/12/2005 at 19:12

---

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.

ZylonBane on 9/12/2005 at 19:47

---

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.