this follows on from the thread in the help section
I dont understand (altho i dont understand much about the engine and code) why springs fps is bad generally
for example in TA3d i get over 100 fps even with the shiny water at all times
in Spring i start with 50-60 (on medium settings no shadows but reflective texts on LOD distant low and everything else pretty much on low) all this on a ati 1950 xt 512 meg card at 1280 * 1000 reso
and my fps always ends up below 20 in a normal game with an avg amount of units in screen
Heck i get better fps on every other game i own even supreme commander
i also have 2 gigs of ram and a 2.8 ghz processor so i shud expect better fps shudnt i ?
i dont want to whine but i think its a pressing issue i dont see why our fps has to be so bad even with good spec pc's
and infact get worse with newer cards O_o ( i had better fps on my 5 series nvidia card)
please if theres any way to improve fps and there must be because theres nuthing in spring atm that should drain fps like that..
fix it now especially with new ceg effects that will kill fps more so we need all that extra fps!!
That's weird. With my awful 3 year old computer with a poor graphics card, I get 40-50 fps at the start of the game that very rarely drops below 10 even in very big battles. On my other newer computer (but still a bad graphics card) I get 100+ FPS with 1024x768 that never really drops below 30.
If you've got a pentium 4, well, that's just a bad processor, and I guess you do. TA3D does a lot less than Spring (or at least should, because it's that much younger), and graphic cards are not the bottleneck in both cases.
It's the pathfinder in spring's case. Shadows, on the other hand (if set to pretty high resolutions), can be the reason for a major drop in FPS as well as refractive water.
then why do i get under 20 frames in spring and higher frames in supreme com with my 2.8 ghz processor even if its a p4 and had better fps on a 5 series nvidia card O_o
there does need to be an investigation into what is eating spring's performance. I can play all the current games just fine and I have a pretty good setup over here.
My Guesses:
Spring's path finding engine takes into account a much higher resolution height map and the possibility of deformable terrain. Planes in spring must check vertical collision whereas with TA it just ignored pathing for planes and let them fly through each other. Same thing can be said for pretty much all ballistic collisions, the model is much simpler for classic TA. my assumption is that TA3D follows the pathing and collision models of classic TA.
TA3D developers actually understand how their pathfinder works and have made attempts at optimizing it, whereas once kman left spring that was it, very little was known about the pathfinder and how it worked and its remained relatively identical to that released in v0.4.
Even k-man admitted our pathfinder is a horrific mess that should be deleted and rewritten over at the command engine forums.
That file isn't too bad AFAICS (after a quick glance over it, nothing more, nothing less )
If the pathfinder is horrific, and the developers know it, why haven't they remade it/attempted to fix it yet?
There's more stuff that needs fixing then there's time.
The pathfinding fulfills it's job, which is pathfinding. I can't help the groundmovetype steering code can't deal with some of the paths it comes up with
Also pathfinding will be CPU intensive always, and I assume K-man already did quite a lot of optimizing. Why would we have 2 path estimators and one detailed path finder after all.. that's most probably not because K-man thought, "oh, let's add some estimators, that sounds cool".
Has anybody looked at the real CPU load for pathfinding for ground units in TA3D, with a similar set of circumstances, and tested the theory that they've written something better?
Since we have a very-near clone of Ashap Plateau, I'd strongly recommend running that map in TA3D with 500 Flashes, and see what transpires.
My guess is that it'll be a very similar load. However, if they've made a really significant stride forwards, we should learn from it- isn't their project GPL'd? Aren't they using a 2D grayscale, just like we are? So if it's really better... meh, we just need to change some relatively minor stuff to use it.
Seriously, what I'd like is to see K-Man come back and finish what he was working on for CE- I have a feeling that the main reason it didn't get done was because he wasn't quite sure he wanted it available under LGPL, it sounded like he was convinced he'd written something a lot better. I simply don't know enough about this subject to judge, other than by results.
Lastly, as I've pointed out, again and again, the main problems aren't with the PATHFINDER, they're with the STEERING CODE, that handles per-Unit collisions. That's where most of the suck is occuring- Units collide with one another far too often, because they don't "see" each other. There has to be a way to prevent them from doing this as much- maybe a check, every few frames, to see if there are more than one Unit near them, and if so, to steer a few degrees to one side or another for the next few frames...
One area where Spring could probably noticeably improve pathfinding performance, though, is with aircraft. The current code tries to keep everything flying at the same height, with results that often aren't optimal. I'm going to do a test with PURE, putting everything very deliberately into different heights, so that fighters, bombers, etc. are in different height "slots", and won't normally collide. I'll bet that that change will really help, and it'd be very simple to assign any Unit that's using a CAirMoveType to a random range of heights, reading a TDF variable "airHeightRange" and picking from that value, adding it to CruiseAlt (by default, make it 0, for backwards compatibility). That'd be even more optimal, in most cases, because even like objects would have different starting heights, reducing the amount of over / under-correction during avoidance maneuvers...
Last edited by Argh on 21 Nov 2007, 16:05, edited 1 time in total.
Making planes fly at different altitudes
won't stop their collision checks from
running, but it might (depending on the
height differences) speed up each check
marginally, since there'd be less units
within collision-range of each other on
average. Note that this isn't so much a
pathfinding as a pathfollowing problem,
pathfinding for aircraft obviously requires
very little CPU.
How do the collision checks work, for aircraft, then? Aren't they culling out anything that's more than a certain radius away? They shouldn't calculate collisions with every other flying thing, just on the off chance that somebody decides to put in a flying thing that moves at insane speeds...
The same applies to ground units, but even moreso. How does the collision checker work? I'd have thought it would get a raw list of everybody's locations and sizes, black out some dots on a binary grid, and then do a search only within a few hundred squares... but the way it seems to work, it only "sees" true collisions when origins intersect- the only things keeping units from constantly clipping into one another is the pathfollowing code...
(Aircraft) shouldn't calculate collisions with every other flying thing...
They don't, the checks make use of Spring's
quad-field (a spatial partioning system that
maintains a list of quads on top of the map
which track where units roughly are) to keep
the cost down.
Last edited by Kloot on 21 Nov 2007, 17:08, edited 1 time in total.
The direction and speed it takes is dependant on its altitude and proximity to other units, aswell as the variables specified by the mdoder for thigns like yaw etc.
This is one reason why when 1000 aircraft are in a small compact area some of them crash into the ground avoiding other aircraft. Its highly innefficient, and doesnt scale well at all.
Could the ghz collum in TAS be replaced? GHZ means nothing! CPU core brand does... An overclocked 3ghz celeron wouldn't be better than a Sempron socket M2 for instance.
Could there be an option to disabled texture filtering? In some games disabling it, or if it gets disabled due a bug (like Need for speed undreground), does help run better, much smoother. Everything looks pixelated and texture blending can't be done without filtering, but that doesn't really bother me.
Another option, quite stupid, is disabling audio. In games like MMORPGs, PCs with old CPUs and no fancy Audigy / Live cards run games much better this way. I have played lineage 2 and by disabling texture filtering and sound the game runs 200% faster in the high level areas, but not that much better in the starting cities as those zones are ligtht to CPUs.
According to the perf graph, pathfiding, AI, collision, draw world and draw interface (really???) are the cpu cycles demanders.
Sound is little load, especially if you limit it to 8 at once, and you can disable it.
Texture filtering? Hmm, good idea, but I suspect it wouldn't help much if at all on the newer cards, since they seem to have some odd interaction issue...
especially with new ceg effects that will kill fps more so we need all that extra fps!!
)
