I haven't had the opportunity to play the game as much as you all.
Why find it necessary to recode the entire serial of the game to use multiple cores when the scheduler could algorithmically/dynamically allocate processing resources? I know other programming languages can do that but this uses a work-stealing algorithm,alternatively you could use
OpenMP or any other parallel programming language.
type 'Cilk++' in google.
here are some links.
http://www.cilk.com/
http://www.cilk.com/multicore-products/ ... -overview/
http://www.cilk.com/multicore-products/why-cilk/
http://www.youtube.com/watch?v=FjGKLYINGsg
The steps in Cilk++ programming are generally quite simple.
1.It is up to the programmer to 'expose' the parallelism of the serial code (remove processor specific serial code,re-engineer the code to run serially on 1 processor(mainly to avoid race conditions),global variables(this is where hyperobjects come in),etc).
as stated on Wiki
http://en.wikipedia.org/wiki/Cilk
"The biggest principle behind the design of the Cilk language is that the programmer should be responsible for exposing the parallelism, identifying elements that can safely be executed in parallel; it should then be left to the run-time environment, particularly the scheduler, to decide during execution how to actually divide the work between processors. It is because these responsibilities are separated that a Cilk program can run without rewriting on any number of processors, including one."
2.Add the small Cilk code(Alot of the time you'll use just 3 words) to parts of the serial code that may need multiprocessing(when running this will tell the scheduler that it is SAFE to multiprocess,you dont need to specify like you do when serially coding a multicore application,the scheduler dynamically handles that)
eg.Loops are a prime candidate.
3.Run it through race detection (in this case cilkscreen)
And repeat the previous 2 or 3 steps until you are satisfied with the performance,this is as simple as I can describe it,the rest is on the website.
Even if you have 1 processor,the program will still run since the serial code is left intact,you can still assign 2 or more 'workers' on a single processor with Cilk++,this spawns 2 or more threads on the same processor and you can even declare this with a quadcore processor where it spawns 8 threads instead of the usual 4.
Cilk++ is a clean extension of C++,This is by no means a 'For The Win'/'Go Faster' button. Cilk++
DOES NOT compensate for bad code.
I'am by no means an expert programmer,since ive only started understanding C++ recently.
If this were presented to the computer games industry (like thru E3) then I wouldn't have to type this down.
I'm not entirely sure on what programming language X3TC was written in.
But if Egosoft or the community could convert X3TC's serial code into C++ and optimize from there with Cilk++ (assuming it's humanely possible) then that will be the end of ALL multicore arguments here in these forums,almost all.
If not then I think Egosoft should write their next project(including source code) in Cilk++,not that it's much different to C++ since it's a clean extension.
Now If you're going to start an argument I will not answer.
No more of this "It's impossible" S%$t,It IS possible to multicore a game/application without having to change much of the serial code.
Got it?
Good...
I understand this is particularly good news to gamers/modders/scripters and egosoft since having a dual/quad/octa core processor will actually mean something,plus no more lagging slideshows at least in the processors department. Assuming the recoding were to happen.
*Note that Cilk isn't supported anymore,only Cilk++.
Cilk is an extension of C,Cilk++ is an extension of C++
http://supertech.csail.mit.edu/cilk/ for Cilk
http://www.cilk.com/home/try-and-buy-ci ... load-cilk/ for Cilk++
What do you think?