Sorry. People who're wrong yet supremely confident about it just push me over the edge.
Man, people really need some lessons in diplomacy and manners before posting in here.
Sorry. People who're wrong yet supremely confident about it just push me over the edge.
THIS is your original quote. There was no talk of 'effectively simoultanous' because the 'effectively' was later slipped in to cover the tracks.Originally Posted by ZylonBane
Multiple systems running simultanously on one machine definitely means multithreaded, because there is no other way of having running multiple systems simultanously on one machine. If you make arbitrary disctinctions within the game code, is usefull for development purposes, but technically there are no multiple systems as it is one big application all calling into each other. Each loopstep calls all the various modules and they are updated according to their current state and requirements.
Without analyzing the code, it would be even questionable if you could really call this parts seperate modules or systems, because they all need to interface with each other, and depending how this is acutally implemented, they might indeed be seperate moduls, or they might not.
If they have well defined interfaces, then you might call them modules or systems, but that is just speculation as long as you haven't seen the actual design.
There is allways human intuition, and trial->error method
You can build radically different application, which can act pretty the same as the original does. The finetuning will be difficult, but not impossible. If ZylonBane says that original DarkEngine acts differently on different CPUs, then there is tolerance in the players too. I mean: There are certain things which can't be only 90% the same - the feeling you have when you play for example, but for some internal application systems, this does not make a big difference - this is finetuning. (Which will take place quite some time from now). Anyway, with the dromed in hand, you can simulate pretty anything you like, and test what the original system does. This is how I found the inner structure of the map.
In past two days, I nearly finished adding lightmaps to testing viewer (for now only static ones - e.g. not for the switchable lights), will upload the updated code to SF site soon. There allready is a screenshot with lightmaps on SF.
I've got a question: I know there is a converter for in-game objects, so the structure of those must be known. Does someone have a clue where to get this info?
After the time I will be able to load the level with objects and switch light on and off, this will be the time to start the real coding.
Also, please, if someone of you does have a time and knows a bit C++, enough to understand that messy code of mine and find a bug in the code of texturemapping, please do so - 80-90% of faces have textures that fit (this is a problem of data interpretation, took some time to get even to this stage).
Sorry for the long text (and for my horrilble english).
Am I going to have to beat you with the cluestick too, and point out that on a single-core system, NOTHING is happening simultaneously? Multithreading is just a convenience provided by the operating system.Originally Posted by sparhawk
Please point me to a definitive source which says the word "system" must only refer to a threaded module. I very much doubt you'll be able to find one. In ENGLISH, "system" is normally used to refer to any chunk of code dedicated to a specific purpose. It doesn't have a damn thing to do with threading.If you make arbitrary disctinctions within the game code, is usefull for development purposes, but technically there are no multiple systems as it is one big application all calling into each other.
Which is what Assidragon and sparhawk have been saying all along, whereas you started out with "multiple systems that run simultaneously". We all know now that you meant "virtually simultaneously", but that was not what you first said. So stop digging.Originally Posted by ZylonBane
Or maybe the use of effectively was used to clear up confusion after YOU mistakenly interpreted the previous post as meaning multi threading.Originally Posted by Spars
Sparhawk, I know there is a language barrier, but you really are being a great big pedantic cock. Even if you originally interpreted it that way, ZB did not infer the use of multi threading or intend to infer the use of multi threading; as has been repeatedly stated over and over. Show a bit of respect to the thread and stop arguing the point.
Volca - those light maps are looking sweet.
No it's isn't. They've been squawking over and over that "multithreading" is the only way to get a computer to do more than one thing at once, which is wrong no matter how you slice it.Originally Posted by hopper
This thread is retarded.
My friends, 'tis the first time I see people nitpicking on words MORE than ZylonBane. If you are unable to clearly understand that ZB's first post was in no way discussing the manner the CPU executes code, well...
Anyway, OF COURSE no "OpenDarkEngine" will ever run Thief Missions perfectly like Thief. I'd gladly see anyone's Open Source "interpretation" of the Dark Engine though. It can take multiple forms, the most important being at the time The Dark Mod. But some community engine, able to run original Thief missions using Thief Material such as textures would be great. It could anyway be very useful as post-DromEd pre-Thief tool.
Last edited by Briareos H; 10th Dec 2005 at 15:12.
Well I'm no expert on compiling stuff, but this time my g++ compiler only gives me one type of error: "ISO C++ forbids cast to non-reference type used as lvalue". Occurs on lines 116-118, 150, 315, 319, 322, 325, 328, 329, 335, 338, 347, 352 and 353 in main.cpp (v 0.0.1). Any ideas?
This is really cool:
I say keep up the good work! Would dynamic lighting eventually be possible with your engine?
Shadowspawn might know better than anyone else:Originally Posted by Volca
He's been slaving away with t3 object conversions lately but there's several tools for t1&2 mesh/AI conversions.
I'm on the track of the error, and will make a fix in the next version. It is caused by the construction (char *)ptr += in MAP macro, which your compiler doesn't like. Sorry for the messy code, this was written only as a proof-of-concept. I will rewrite the whole thing from the ground when the time comes. You can try switching to non ISO C++ compiling (which seems to be the default for me, as I don't get any errors - gcc 3.3.6 on Gentoo Linux).
It seems Irrlicht knows to make dynamic shadows and enviromental maps, as well as render-to-texture, so water could be made reflective, and lights could cast shadows. Do not know for sure if Irrlicht will be used as a target engine, maybe I will try to use ogre, as it is more komplex and robust.
Yeah. I know it's hard to back down now, after being proven wrong. Multithreading is NOT just a convenience by the operating system. In fact if you plug in a second CPU, a multithreaded application would be able take advantage of the second CPU without any changes to the binary or any other part of the code. If that application is NOT multithreaded it would NOT take advatnage of it. It's as easy as that. Therefore this can be seen indeed as a seperate system in one case but not in the other case. You limiting the discussion to single core systems while still talking about simultanesouly is an arbitrary distinction to avoid that you have to admit your error.Originally Posted by ZylonBane
I have many years of experience in programin on all kind of levels in a computer system. From lowest hardware level to abstract high level programming. I also have talked to a LOT of people in all this time, ranging from noobs to computer science people working also for a long time in the field, but I don't recall anybody using that term in the sense that you do. So sorry for not taking you seriously on that one, but I guess I can trust my experience more then yours. You can make up all kind of terms to sidestep that you don't know that much about computer programming, but that doesn't change the facts. If you call a table a stool just because you also can sit on it, doesn't make it a stool.Please point me to a definitive source which says the word "system" must only refer to a threaded module. I very much doubt you'll be able to find one. In ENGLISH, "system" is normally used to refer to any chunk of code dedicated to a specific purpose. It doesn't have a damn thing to do with threading.
I guess ZB doesn't need a bootlicker to to talk for him.Originally Posted by jay pettitt
It's almost funny, isn't it folks? He says one thing, then proves himself wrong in the very next sentence.Originally Posted by sparhawk
For fuck's sake, knock it off. If only because Christmas is around the corner.
Pipe down, you. Some of us find this interesting.
The interesting posts in this thread have all been made by other people than ZB. If ZB had cared to explain why he thinks sparhawk is wrong (referring to his last post here), it might have been interesting, too. As it stands, it's just a deliberately provocative cheap shot. But of course, this is ZB's usual habit of contributing to "interesting" discussions.
I agree with this 100% and perhaps this thread might not have derailed had he mentioned this in his earlier posts.Originally Posted by ZylonBane
As you have pointed out to me more than once, we're not mind readers.
I did't explain because it was so screamingly self-evident. But okay, for the slow kids--Originally Posted by hopper
Sparhawk denied that multithreading is a convenience provided by the operating system, then says that multithreaded apps can automatically take advantage of a second CPU.
And how is this possible? Because those applications use the operating system's threading functions.
If anyone else really cares about this whole multithreading thing, there is an excellent primer on the subject HERE. Note that "process" is the word Sparkhawk and Ass seem to keep confusing with "system".
Hmmm, how about this threads gets back on topic?
Nah, it's more interesting this way.
Apparenlty you don't know much about multithreading beyond what you read in the last few hours to make an appearance of knowing about it. an application that is REALLY multithreaded can do multiple things at the same time. If the hardware has one CPU then oif course this is not true, and the instruction flow of the application is pretty similar as if it were not multithreaded at all. However, at the moment you add at least one additional CPU to that system, an application that is really multithreaded will start to do real simultanous processing, while an application that is not written for multithreadedness will run the same as before.Originally Posted by ZylonBane
You don't need operating system support. I can easily write my own multithreading myself, and I have done so when there was no Windows around and programs run under DOS, where not multithreading was built into the oparting system. That now the operating system supports it is a convenience, but no requirement to make an application do multithreading.And how is this possible? Because those applications use the operating system's threading functions.
The article doesn't tell anything new to me, and I'm well aware what a process is and what a thread is. Are you?If anyone else really cares about this whole multithreading thing, there is an excellent primer on the subject HERE. Note that "process" is the word Sparkhawk and Ass seem to keep confusing with "system".