Spring RTS Engine

Regarding spring its probably as easy as changing the above mentioned constants and recompiling, so I don't really see it it as 'limiting ourselves'. It just doesn't make sense to reserve memory for 4 million players if no one plays with so many anyway.

I'll update it to 16 teams in lobby too (I didn't consider it high priority so far so it didn't got changed since the change is not trivial at all :)
I guess 32 is there because you may have spectators in the game or multiple players on same team (sharing a comm) etc.

<3 awesome <3!

gaia equals to ?

16

So if a mod really needed 4 different Gaia sides, itw ould be as simple as recompling the source with appropriate #defines, right?

yes

What a mess! 32 Players on a small divide map! :)

Dr.InfernO wrote:What a mess! 32 Players on a small divide map! :)

Yeah and 16 players per one commander, now thats a lot of team-work haha!

Sorry, what's Gaia?

A currently unused feature.

Well unused... there is a reserved spot for it in the team list, but nothing actually supports inserting things in that gaia team.

I think 255 players would be a good number, since it's way more than anyone will likely ever do, wheras 16 still limits us somewhat. Then again, I have no idea how much memory is reserved per player.

It's about 5 Meg extra to increase MAX_TEAMS from 16 to 255 when 5000 units are in game (4 bytes per team per unit plus a bit of constant overhead for storing Player & Team info for 255 teams/players).

Still I don't think it's smart to increase it that much as it will basically be unused memory most of the time and it will just cause more page faults, cache misses, and other complex slow things.

hmm so why use static arrays of fixed length and not STL containers?

Because that would mean extra overhead in terms of:
* speed (an extra pointer-dereference whenever LOS is used, which is basically everywhere) &
* memory usage (more then three extra pointers per unit, 3 for the std::vector plus some pointers internal to the memory allocator. The overhead would be as big or bigger then the array size in many cases, in which case fixed size arrays are the right solution IMHO),

Plus the current way just was easier to code

And additionally, it compiles faster

why not just do it now and set it at 21 teams? I doubt anyone would need more than 4-5 anyway; it coudl save you some hassle down the road