1.0.1 Performance Drop with high speed

#1

Hi,

this is kinda related to the following thread: viewtopic.php?f=4&t=459

I noticed that since Gold version, the Performance with high speed (4x) and more than ~10 Defenders is pretty bad.
The game slows down (2x is actually faster than 4x -.-) and the controls get sluggish (have to click 10+ times to actually select a Unit, placing them is the same problem). Might be due to the new Graphics or the bugfix for the Memory Leak introduced a new bug…

mfg

Yinan

#2

Hey there, we’ve fixed the memory leak in version 1.0.27, that’s going up to the test server today. This should hopefully help a lot.

As for 4x speed, that setting is a bit more performance intensive than the others. The reason is that 1/4 through 2x speed work by adjusting the timestep, however when we get to the extreme time dilation on 4x, using a timestep change starts to break the game’s determinism and you get different results than you would at a slower speed. To fix this, 4x speed is really just 2x speed, but the update() function is run twice per update cycle.

This shouldn’t be too much a problem in and of itself - rendering is a far greater performance bottleneck than the update cycle, but combined with the memory leak it seems to have gotten out of hand.

This issue should be address in 1.0.27,hopefully.

#3

Lars, how about switching off some of the rendering altogether in 4speed mode, then? I mean, could the game mechanics function correctly without i.e. animating defenders at all?

#4

@coyot: It could in theory, but all the timings and everything are deeply intertwined with the animation system. So, that’s some non-trivial surgery. Besides, there’s already code in there to deal with performance drops in various ways:

  1. Flixel itself ratchets down the framerate to maintain a fixed amount of updates per second, before it resorts to slowdown
  2. Before we implemented manual particle settings, there was already code for AOE attacks that makes particles themselves appear less often in proportion to fps
  3. You can now manually set particles, of course

The real thing is just that the animation system itself isn’t the bottleneck, since changing animation frames is just more processing - the framebuffer still needs to be redrawn continuously. Of course, it is happening twice, but there’s not a lot of obvious gains to be had without the risk of substantial new bugs. I’ll post the latest benchmarks just to be sure, but the real bottleneck is still just “drawing a bunch of things to the screen over and over again.” Flixel can only do so much here, so although I can optimize and tweak here and there, there’s no real silver bullet until I move the whole engine to something that gives me real honest-to-God hardware acceleration. I’ve been looking into HaXe a lot lately, and I think that’s probably our ticket for any future development - HaXe devs tell me that it shouldn’t be too hard to port over, and then we can target C++ for the download version with hardware accelerated graphics.

That of course, won’t happen until/unless we do a sequel, but if/when we do a sequel, I’ll try to maintain compatibility with the original game’s dataset and features (this would also be a boon to porting it to consoles, iOS, etc, if/when that opportunity ever presents itself).

I’ll be interested to see if the latest memory leak fix in 1.0.27 does anything to mitigate the 4x slowdown problems.