the effort to rewrite a complete engine is unrealistic high. quote:
Spring risks to be "left in the dust" once the new generation of large-scale fully-(or at least well-)parallelized RTS makes its appearence. |
sadly agree. a better fitting solution would be to carefully select and use existing modern rts engine, maybe with miniml adaptive effort, to replace the game simulation. is the LUA part really a significat performance factor compared to the c++ part? else, the target engine should be possibli flavoured with the existing LUA.
+0 / -0
|
60fps, with according everything with a central server each frame, would assume no more than 17ms latency / roundrip to the server between frames?
+0 / -0
|
quote:
Assuming this does work out (I'm not sure it will, but these Oxide guys seem competent enough, and I think I've heard of rumors of Chris Taylor planning a SupCom3, can anyone confirm?), Spring risks to be "left in the dust" once the new generation of large-scale fully-(or at least well-)parallelized RTS makes its appearence.
|
How much improvement do you think is possible with MT? Everyone who expects to see the FPS fly through the roof clearly has absolutely no idea what they're talking about. This is not a university programming exercise. This is not a repetitive mathematical calculation. Combining the sequentiality of so many factors with the overhead of multi-threading (which will almost definitely be pretty severe, since lua code can touch almost anything) and you reach the conclusion it's somewhere between irrelevant and inconsequential. As long as RTSMP violates GPL it is bollocks as far as I'm concerned.
+5 / -0
|
quote:
is the LUA part really a significat performance factor compared to the c++ part? else, the target engine should be possibli flavoured with the existing LUA.
|
Currently for me (after the heavy optimising in 100.0) the Lua takes as much as 50% of the perf (used to be around 33%).
+3 / -0
|
[ ] People know Amdahl's law. ( https://en.wikipedia.org/wiki/Amdahl's_law )
+0 / -0
|
quote:
is the LUA part really a significat performance factor compared to the c++ part? |
When 5+ minutes into a 10v10+ on a non-tiny map enter the following command: /fps now look at the number and notice the difference after typing /luaui disable My FPS jump from 25-30 to 55-65 (vsync disabled). That's without disabling gadgets (lua too), without hiding the engine UI (F5) and without disabling LoS view (L).
+3 / -0
|
/luiaui enable
+8 / -0
|
quote:
I think I've heard of rumors of Chris Taylor planning a SupCom3 |
SupCom 3 is impossible since Chris Taylor doesn't hold the rights for ip at the current time. However Wargaming, the current Chris Taylor employer and developer of Word of Tanks (and word of other crap) has acquired rights for Total Annihilation about 2 years ago. Then Chris during some interview was asked about Total Annihilation sequel and neither has confirmed nor denied the possibility of it which has sprung a lot of speculation. Of course there is absolutely nothing confirming that it is being developed but lets just assume it was/is being considered. quote:
Spring risks to be "left in the dust" once the new generation of large-scale fully-(or at least well-)parallelized RTS makes its appearence. |
Such games would have better performance and look better but would they be more enjoyable though? Let's not forget that Spring games are also free and open source which is heavily approved by Linux junkies so here is one demographic that wont be taken for sure. Besides it is already 'left in the dust' tech wise anyway. But isn't that obvious since the engine has 2-4 active developers at most?
+5 / -0
|
This post has been downvoted below -5 and collapsed, click here to expand
LOL guys, with all of our brains put together, we could definitely find a solution to this multi-threading issue.
As I was reading the development guildlines, I discovered that (graphic, input, sound etc) are unsynced.
So perhaps we could move the graphics stuff to a second thread...
************************************************************************
Stupid Intel, Oracle, Google and etc, making everyone work, and wait more!
Intel Core i7s and (some) i5s claim that they have 4 cores, but .... they have 8 threads!!! Soo stupid, and compiling usually takes sooo long!
Oracle java is sooooooo slow!!!
Google using Java for android development and furthermore GRADLE!!!
Making my life slower!!! Gradle is so slow!!! wait for 5 minues to do anything
*****************************************************************************
Multithreading will only become more popular.
If spring doesn't go to multithreading soon.... then it will most likely become obsolete within the next 10 years
+0 / -6
|
quote:
If spring doesn't go to multithreading soon.... then it will most likely become obsolete within the next 10 years |
Obsolete? Fine by me, as that would imply there's gonna be a better open source RTS engine with powerful controls and awesome games. Chances are some of the current Spring devs would migrate.
+1 / -0
|
|
|
quote:
LOL guys, with all of our brains put together, we could definitely find a solution to this multi-threading issue. |
For the love of HONK and all that is HONKY I will say again: Multi-threading is not an issue, it's software behaviour. Examples of issues: 1) Graphic glitches 2) Bad performance Examples of possible solutions (respectively): 1) A dev with an AMD card who knows what they're doing 2) Reducing cache misses (responsible for a significant portion of the speedup in 100.0) Examples of sexy terms which sound like solutions but are probably more trouble than gain (in most cases): 1) Multi-threading From now on I'd recommend refraining from saying: quote:
Spring should be more multithreaded |
As this is not only wrong but useless and annoying. Instead you can say things like: quote:
Spring is slow for me and I'd like it to be faster |
Which may or may not make a difference, but it will definitely make you look less foolish. (Feel free to link to this post whenever someone mentions this again)
+4 / -0
|
   hokomoko I have a super awesome serious fix for the multithreading problem. Simply spawn threads on all the other CPUs and just fill them with junk calcuations which are completely unrelated to the main Spring sim/UI/everything. Then players will open up their performance look-at-er, notice that all their CPUs are wizzing while Spring is running and conclude that Spring is awesome. Btw, the multithreading problem is that player feel they need to request it because it is a backend feature which has been hyped in many places as a frontend feature. Also, from a basic maths point of view, it sounds reasonable. quote:
8 cores but only using 1??? I could have 8x the FPS, evil devs are keeping it from me!!!! |
+18 / -0
|
|
|
To summarize. How noobs see the multithreading: quote:
Just flip a switch to use all 4 cores and it will be 300% faster! |
How devs see the multithreading: (and how it often is) quote:
Needs tons of work for a total rewrite, will introduce million bugs and desyncs, will become unmaintainable, but MAY give 10% more fps IF DONE PROPERLY, although it is more likely it won't work at all. |
+14 / -0
|
quote:
Such games would have better performance and look better but would they be more enjoyable though? Let's not forget that Spring games are also free and open source which is heavily approved by Linux junkies so here is one demographic that wont be taken for sure.
Besides it is already 'left in the dust' tech wise anyway. But isn't that obvious since the engine has 2-4 active developers at most?
|
Good points. I guess I just wish Spring to be at the forefront of innovation, like it was in the past (and it still has very advanced gameplay features), but there are more important things to consider... Maybe in this case it's better to wait and see whether there's anoter multiplayer RTS that will be able to pull it off.
+0 / -0
|
GoogleFrog, We almost had your wanted feature when WorkerThreadSpinTime was 5 by default (it is 1 now), spring looked much more MT optimized then :).
+1 / -0
|
Google Frog said "I have a super awesome serious fix for the multithreading problem. Simply spawn threads on all the other CPUs and just fill them with junk calcuations which are completely unrelated to the main Spring sim/UI/everything. Then players will open up their performance look-at-er, notice that all their CPUs are wizzing while Spring is running and conclude that Spring is awesome." LOL, thats probably the best idea ever!!! My previous computer had overheat protection! It hibernates when all cores run at 100%. Imagin that I open up the new zero-k and ... pufff as in the sound of fans going at max rpm ... ... cpu 100% ... ... Hybernate ... ... restart ... ... cpu100% ... ... repeat ...
+0 / -0
|
Why let software developers solve the problem when hardware developers can do it: Buy Intel Skylake with inverse hyperthreading :)
+5 / -1
|
|
|
