Hi there, I finally had some time to look into the alpha of PA and it looks very nice already I'm wondering if people are seeing the same slow-down as me as soon as nano-spray particles are rendered? I tried it on Win7 and Linux, with a GTX260 and a I5-750. I get a bit more frames in Win7, but generally it's quite equal as far as I can tell. Depending on the world biom I'm getting about 75fps (according to ctrl+p). But as soon as there are any nano-spray particles shown I'm down to 10-20fps. It stays that low even until after the building has finished. I need to scroll the area which formerly had the nano-spray particles out of sight to make the FPS go up to ~75 again. Then I can scroll back and it'll stay at 75fps. Maybe my hardware is too slow to handle the amount of nano-spray particles? I don't have any noticeable slow-down on Spring RTS with nano-spray particles set to max (of 20000). Is there any secret parameter to reduce the amount of particles? Thanks!
Go to this thread, read the first post, do what it says within and maybe it will get fixed if its an issue with the game. (This is a performance thread from uber with information how to report such an issue so they can look into it.)
Hi smallcpu, thanks for your suggestion. I guess I will do it afterall. I was saw that thread but was hesitant to do it since it only takes a 500ms snapshot of the situation. I could do one before building, one during and one afterwards, maybe. From what you said I expect you do not have this problem, huh?
Check this topic: https://forums.uberent.com/threads/feature-request-turning-off-particle-effects-simple-particles.50948/ Everybody have such problem, but people with more powerful hardware less affected by those things. PS: Also want warn you that performance testing not working on Linux yet.
Oh cool! I reduced the particles and the emission rate heavily but unfortunately it takes me back to square one. Only 1-2 particles flying every second but still I'm getting heavy loss in FPS. Seems like the nano-spray was a wild-goose chase :-/ Also, my statement of having to scroll around was false: I just have to wait around for 10 to 15 seconds, then the better FPS is back. Something else seems to be hogging in the background: When I have acceptable FPS I can see (on my second screen) that one core is at 100%, rest mostly idle. Once I start building, the core usage goes wild, all showing usage between 30-70%. During that time i have those bad FPS values. This lasts for about 10 to 15 seconds after the building got finished. Once it's back to "one core at 100%, rest mostly idle" the FPS go back up. I'll guess I'll do the performance info upload mentioned earlier. May it's the CPU being the bottleneck. I could try to reproduce the FPS slow-down when joining the game of someone else. I guess I should rename the thread? Thanks for your help!
Have you tried seeing if it's this still prevalent issue http://pa.lennardf1989.com/Tracker/index.php?do=details&task_id=945. How fast the bars update if empty if far too quick and can cause a lot of lag. (coincidently, SupCom updates the bars an awful lot slower, wonder if they had a similar thing going on)
Oh wow, your hunch was correct, Artamentix! Or it's a big coincidence that whenever the resource storage is full, the FPS are back. I'll try the fix that masterdigital mentioned next. Unfortunately, I am not allowed to post a link to it but it's mentioned at the end of the bug report that Artamentix linked to. Thank you very much!
Well, unfortunately, it didn't help... I also uncommented the console.log command right above engine.call but can't see any output in form of "active regions count" on STDOUT. So maybe this function is not called anymore at all. Hoping masterdigital will continue to work on it. So long!
Could a moderator change the misleading thread topic to something more reasonable like "Status bar slow-down"? Thanks!
Ah so it is normal for the economy bar to cause ups lowering? Its hardly noticeable but i notice it. Did lowering how often the server calculates values reduce this issue? I noticed the difference between total annihilation and cc renegade where your economy updates every other second all at once accumulating the totals across those seconds of pause, like it was tick tick tick... while planetary annihilation appears to do it with the passage of miliseconds as if real time.
Your post made me try again and this time I was successful! The fix masterdigital is working on doesn't help with this issue but I have the impression it helps overall FPS - so I enabled it. It's linked to in the bug report that Artamentix linked to in his post here. Today I did the changes to live_game.js & html as yarmond suggests in the bug report - and that helped a lot! The economy bars looks like this now: It says "60%/800" instead of "480/800". This percentage is way less often updated by the engine it seems, which means that the number doesn't need to be redrawn all the time, which in turn seems to have been responsible for my big loss in FPS. In case someone is interested, these are the changes I did to the current version v.53072 (both files located in .steam/steam/SteamApps/common/Planetary Annihilation/media/ui/alpha/live_game): Code: --- live_game.js 2013-09-21 12:05:16.636638553 +0200 +++ live_game.js.modified 2013-09-21 12:10:16.123763983 +0200 @@ -231,8 +231,8 @@ regions_string = JSON.stringify(payload); if (regions_string !== prev_regions_string) { - //console.log('active regions count : ' + active_regions.length); - //engine.call('set_active_regions', regions_string); // disabled because its buggy. + console.log('active regions count : ' + active_regions.length); + engine.call('set_active_regions', regions_string); // disabled because its buggy. prev_regions_string = regions_string; } } @@ -434,7 +434,7 @@ return (self.maxEnergy()) ? self.currentEnergy() / self.maxEnergy() : 0.0; }); self.energyFractionString = ko.computed(function () { - return '' + (100 * self.energyFraction()) + '%'; + return '' + 5 * Math.floor(20 * self.energyFraction()) + '%'; }); self.energyGain = ko.observable(3.0); @@ -452,7 +452,7 @@ return (self.maxMetal()) ? self.currentMetal() / self.maxMetal() : 0.0; }); self.metalFractionString = ko.computed(function () { - return '' + (100 * self.metalFraction()) + '%'; + return '' + 5 * Math.floor(20 * self.metalFraction()) + '%'; }); self.metalGain = ko.observable(10.0); Code: --- live_game.html 2013-09-21 12:05:14.904666725 +0200 +++ live_game.html.modified 2013-09-21 12:10:55.587121260 +0200 @@ -150,7 +150,7 @@ </div> </div> <div class="status_stats"> - <span id="Span1" data-bind="text: currentMetal">8888</span>/<span id="Span2" data-bind="text: maxMetal">8888</span> + <span id="Span1" data-bind="text: metalFractionString">8888</span>/<span id="Span2" data-bind="text: maxMetal">8888</span> </div> </div> </td> @@ -187,7 +187,7 @@ </div> </div> <div class="status_stats"> - <span id="Span3" data-bind="text: currentEnergy">8888</span>/<span id="Span4" data-bind="text: maxEnergy">8888</span> + <span id="Span3" data-bind="text: energyFractionString">8888</span>/<span id="Span4" data-bind="text: maxEnergy">8888</span> </div> </div> </td> I'm surprised there is nothing like currentDisplayEnergy/Metal implemented yet. Anyways, thanks for everybody's help! Much better now
