1 |
[quote]To my knowledge, C++ supports multithreading. [/quote]
|
1 |
[quote]To my knowledge, C++ supports multithreading. [/quote]
|
2 |
\n
|
2 |
\n
|
3 |
Yes. Here's a few things to consider though:
|
3 |
Yes. Here's a few things to consider though:
|
4 |
\n
|
4 |
\n
|
5 |
If you ever get in touch with parallel programming, you'll notice that [i]every single guide/advice/documentation[/i] will tell you that things can and [i]will[/i] go horribly wrong unless you know very well what you're doing. Multithreading is [i]difficult[/i] to get right, especially in a low-level language like C++. [color=2f2f2f](High level languages have simplified the involved work a lot, but you still need to have a very good understanding not only about what you want to do, how things will work but generally also what is happening under the hood (render threads, thread/object ownership etc.)).[/color]
|
5 |
If you ever get in touch with parallel programming, you'll notice that [i]every single guide/advice/documentation[/i] will tell you that things can and [i]will[/i] go horribly wrong unless you know very well what you're doing. Multithreading is [i]difficult[/i] to get right, especially in a low-level language like C++. [color=2f2f2f](High level languages have simplified the involved work a lot, but you still need to have a very good understanding not only about what you want to do, how things will work but generally also what is happening under the hood (render threads, thread/object ownership etc.)).[/color]
|
6 |
\n
|
6 |
\n
|
7 |
As it so happens (and as said before), the spring engine is basically older than the concept of multithreading for home computers. It's very helpful to build a program in a certain way in order to make it easier to parallelize. spring was not built that way, and while it naturally has been structured into certain components (like any engine) that can be somewhat treated individually, it's certainly not been made with multithreading in mind.
|
7 |
As it so happens (and as said before), the spring engine is basically older than the concept of multithreading for home computers. It's very helpful to build a program in a certain way in order to make it easier to parallelize. spring was not built that way, and while it naturally has been structured into certain components (like any engine) that can be somewhat treated individually, it's certainly not been made with multithreading in mind.
|
|
|
8 |
\n
|
|
|
9 |
As we saw though, it's still possible somehow. Unfortunately, the person who managed to do this refused to share the source code (didn't he also have to change some code inside the executable itself?) for (what I remember being) pretty inane reasons.
|
|
|
10 |
\n
|
|
|
11 |
Another thing you need to understand is that for multiplayer to function properly, every single copy of the engine has to work identically, down to the order in which units die, in which plasma shots hit a target, in which routes units take, collision physics, all that stuff. This is because every client runs its own simulation and only receives the commands players give from the other players (relayed through the host), there's no "master" server to arbitrate any inconsistencies: If the same action has two different results for two clients, they are "desynced" and the game spirals out of synchronisation. A unit that you're giving an order to might already be long dead for the other player, because that one rocket missed another unit that moved in a slightly different path for you than for him.
|
|
|
12 |
\n
|
|
|
13 |
Desync issues are already a (very painful to find, but luckily only very infrequent to be introduced) issue in the single-threaded version. With the added complexity of multithreading, it won't get better.
|