Please continue to optimize PA

Oh? Alright then! Would be happy to see the game multi-threaded, one of the devs did tell you that it'd be very difficult, and that other optimizations are easier and so of higher priority.

But seriously, if this could get multi-threaded it'd be like going from Supcom to FA. (If I remember correctly Supcom 1 still isn't multi-threaded, FA is, I got this idea because FA doesn't have sim problems like Supcom 1 when I play huge ai games.)

FA has no multithreaded sim either.
Multithreading the simulation is NOT EASY even without OpenGL (OpenGL is involved in the client when rendering the image) but has nothing to do with opengl. Though PA sure at least has some room for "naive" improvements like one thread per planet and probably also something like parallel work on at least a few different parts of the sim for each planet.

Really? Then I guess that shows how far optimizations might hopefully get us, as FA's sim doesn't lag with 1000 units like Supcom 1's does on a large ai game.

This is based on pretty old memories but I think that was mostly about AI optimizations, not about sim optimizations. And I think the AI in FA still ate CPU for breakfast even after that.

Well even that FA engine runs at 32 bits ,now 80% FA players cpu´s are bether and has you now ,now we have a benchmark tool to see everyone cpu thats on host games.

To give you an ex: we play 20x20 maps 12 players and runs fantastic iff all got the cpu benchmark -280....

So that means a game from 2007 runing smooth with 12 players in huge maps ,with 32 bit engine make us think isnt it...

I want to see you play that size of game when it came out. -.-

You must not have played FA in 2007 it slowed down in any decent sized game. Also 32 or 64 bit does not matter for this discussion
Also if I remember correctly FA before FAF did not allow for more than 8 players.

I play TA then SC then FA now FAF.
Yes true not alowed on FA 2007 more then 8 players.
And true the 32/64 bits really not matter for this discussion..

But also matter say that i run i7 4790k on maximus board with corsair water cooling at 5.0 ghz ,and on PA only 3 cores are being used and never go more then 21% and game lag a lot ,wy is that?
Inow wy developers also now wy?

+1, the multi-threaded sim is an absolute must have for really smooth games.

This was proven very clearly by Zerver on TA:Spring. He has managed somehow to split the sim into multiple threads. Many have stated they didn't think it would work, however Zervers' method *does* and the results were frankly staggering.

I played BA for years using solely the Multi-threaded Sim version before it was removed. It could handle *more units* than *any* other game I have played including SupCom FA, Ta and so on. We are talking no slow down at all with thousands of units all moving where the standard sim dies at about 1k on the same hardware (Core i5 laptop, 2 cores 4 threads). This proves it *can be done*. If anyone is interested in testing this I can probably get a link through to zervers' fork, as this system is no longer available in the main Spring build due to some concerns over rights / use in relation to the GPL public license.

*note to spring guys, I still love spring and play it, I'm not trying to bring into question anything to do with the removal of the MT-Sim, my point is solely related to the performance benefit it provided- something very important to PA due to the larger number of units involved in comparison to the majority of Spring Games*

Well Kal, if your playing multiplayer your *only* using the client- which is threaded for 3 threads (due to limitation of OpenGL). If you play *offline* or *host a LAN server* then PA can use much more of your CPU (probably most of it) as it requires 1 full thread for the SIM, + 1 thread per connected client + a few other bits.

Also in my experience PA isn't far behind FAF in terms of in game units, and is ahead of the Spring engine (unless we're talking Zervers fork)...

Is there info about that stuff? Like how it was done and why it was removed exactly? Did they copy the concept of some company?

I think main reason it was removed was Zerver wouldn't release the source code he used, so it was 'against rules of GPL' or something. I could probably put you in touch with him to find out *how* it worked (I honestly don't know).

lol

Now that surely wouldn't be a hindrance for PA. Colour me intrigued.

Another long time Spring player arrives...

What happened to the multithreaded version was sad. The guys who ran the project refused to distribute it because of incompatibility with the singlethreaded version, and I guess they also considered it an unwanted competitor because it was real complex and Zerver alone maintained it. With the distribution channels closed, he most likely got pissed off and left.

Nevertheless, it appears that something good came out of it, because it became a lot faster (several times faster) shortly thereafter. Not sure why, maybe less fighting and more focus on the important part (writing fast code)...

Indeed, multithreading is difficulty.
As in "it introduces several new types of bugs" difficulty. Like the Race Condition (does not even exist in single threaded programming).
As in "if you have not designed it from the beginning or have really small code don't even think about retorfitting it" difficulty.
As in "you could even screw up just trying to increment/decrement a value" difficulty.
Anything is easier then changing singlethreading to multithreading.

It is about as rewarding and usefull as using pointers. It is also as dangerous and hard to debug as using those.
And there is little to no help for it either. In the current age you do not use Pointers/Direct memory management unless you *really* need to (automatic memory management is so much easier and bug-resistant).
There are no automatics for multithreading. Nothing you can just use a framework for. Nothing that takes the work (and the human capacity for mistakes) from you. It has to be designed by the programmer.
Also it is practically a nessesity in the current age. Ever since home CPU's started having more cores (rather then stronger cores).

The game design itself lends itself towards using at least one thread per planet + 1 or more for the interplanetary space (just split it into "sectors" at the axes).
None of them interact in a unsafe way (IP space and planets and different planets cannot interact directly; A unit has to leave one to affect the other).
However one of the goals are mega-planets. One big planet could easily have the sim-complexity of a current game, so a single core could not handle the planets entire sim. "1 thread per planet" would scale with number of planets, but not with the size of planets.

1TPP could still be a near goal, because it is relatively easy (for being multithreading). But longterm they have to do "1 Thread per Navigation Sector" or something like that. That would scale with planet sizes (bigger planet = more sectors rather then larger ones) and number of planets. Until we run out of adressable memory or cores in x64 systems.

Sadly I've never seen anyone besides Zerver on his server though his engine is *vastly* superior to vanilla Spring though

Doesn't 32bit max out at 4Gb RAM, 3Gb on Windows? Or did FA never really push the memory limit?

Yep it does max out on 3gb and yep you can break 3gb if you just build enough stuff. Though in normal games that was not an issue usually.

I've never tried his server, but judging from the demos available for download there are a handful of people who play. Yes, the demos are impressive because they pack way more action than any Spring game I've seen.