Engine Testing - 97.0.1-20-gcd4602b (10. Jun 2014)

[abma]

release candidate #2 for 98.0!

looks like the last release candidate for 98.0, as ZK already uses it as default engine it should be quiet stable. Note: Due to reverts 97.0.1-18-gf1dd749 and 97.0.1-20-gcd4602b are technically the same version.

Changes

changes since RC1:

• fix #4407 (SetUnitRotation broken for buildings)
• fix #3677 (bounceExplosionGenerator tag does not work for bouncing aircraftbomb weapon types)
• fix #4413 (widget:GameProgress() was no longer called for rejoining player)

To make the next release post more interesting i need your help. i want to add screenshots & maybe a video to the release post, current screenshots/text snippets are:
http://springrts.com/wiki/ReleaseNotes:97.0


Changes in Detail:
changelog.txt (is currently the same as for rc1)
git diff last rc to HEAD

no breaking changes known atm since 96.0


Download
See the download page for how to get it.


Bugs

If you find a bugs, please report to Mantis.

Please attach infolog.txt as file, if you crash!

current release (known) blocking bugs no major bug.

[Anarchid]

current release (known) blocking bugs no major bug.

4419 is filed as major, and while assigned, it still exists!

(just nitpicking)

[abma]

current release (known) blocking bugs no major bug.

4419 is filed as major, and while assigned, it still exists!

(just nitpicking)

sadly without more details its currently unfixable. with a broader usage (=released 98.0) hopefully reveals some more info if we can't fix it soon.

[Anarchid]

Are we discussing the same bug? 4419 perfectly reproducible with zk on fissure, so information can be generated on a whim.

I assume that's why it's also assigned, it's actionable.

[abma]

oops, nope, added to the roadmap for 98.0. kloot seems to already investigate...

[Google_Frog]

4414 and 4427 are pretty important. I don't know if we can keep Licho from demanding we go back to 91.0 without those fixed soon.

[varikonniemi]

Same performance regressions still apply as what i reported in last thread. Somaybe the performance issues in 4414 is perhaps not only related to roster changes, but across the board, and only compounded there?

http://i.imgur.com/wTpTNxE.png

I would call that severe performance regression. Notice bloated lua memory that is fixed by disabling luaui but performance is not fixed. Something in drawframe is taking very long.

edit: again crash at start: http://pastebin.com/Wvd0prfB second time from maybe 30 runs.
edit2: catalyst 13.35

[Anarchid]

4414 and 4427 should have their severity increased in tracker.

I should not use default severity values.

[aiphee]

"ZK already uses it as default engine it should be quiet stable"

It is by default, but big teamgames run too slow on Windows so they still run on 91 (!setengine)

[jK]

Notice bloated lua memory

wtf u call 23MB bloated?! It's not 1998 with PIII 450MHz and 64MB DDR Ram.

Something in drawframe is taking very long.

You can't compare shown drawframe times across runs & builds, cause the debugview itself is a very time intensive draw call.

And please, don't shrink the window width, your corrupted the most important numbers! YES the number grid/table is the _really_ important thing, not frame times etc. those give just hints where to search for it, but it doesn't tell _what_ is eating it.

[Silentwings]

I guess its impossible to absolutely accurately record & mark (in some new colour/line) the time thats being devoting to profiling + drawing the profiler, but (I don't know) maybe there is a reasonably good but not completely accurate way to record it?

Also, as far as I can see varikonniemi only looked at a situation where the limiting factors on draw/simframe times are totally different to what they are towards the end of a game.

[varikonniemi]

jk: if memory usage doubles with no apparent reason, it is called bloat. From your response i deduct there was some significant improvements under the hood that justifies double memory consumption?

I did a proper test this time with only one spring instance running at a time, 1000 moving flash, and let it run until first profiler reached 100s.

http://i.imgur.com/aTHQKnJ.png
http://i.imgur.com/FeDK7Xl.png

[Silentwings]

That is also not a good represenation of what happens in a real game (e.g. afaics in sim you are essentially only testing the pathfinder and ally-ally collisions there, probably not even in realistic proportions, nor are you putting your system under any strain whatsoever. Also, as you can see in the pictures, the units are taking quite different routes so it is maybe not the best test of even that - plus the fact that you have no queued pf updates in either case.). The point jK made above about the effect of the new profiler on drawframe length while profiling also still applies.

I would guess the reason for lua mem change is related to the split into different lua states, don't know details.

[varikonniemi]

The same test without /debug gives these fps:
96: ~50
develop: ~35

This would indicate it has nothing to do with profiler? I will next try and install latest catalyst and see if it changes anything (the testing was done with latest catalyst that is provided by os)

[abma]

96: ~50
develop: ~35

did you check if config is the same? (check infolog.txt for which springsettings.cfg are used)

[Silentwings]

This would indicate it has nothing to do with profiler?

To me, yes, providing you kept all else equal, although your test still does not capture the mix of factors that actually limit game speed. My attempts at comparing 96<->97 (which involve a lot of complicated gadgetry to simulate ingame conditions, but which don't capture anything network related, any particularly small effects, or anything that doesn't reproduce on my two laptops) don't show any change in performance.

[Jools]

Related to this and to mantis http://springrts.com/mantis/view.php?id=4434:

I don't expect it to be true that 97+ and 91.0 are comparable in terms of load placed on cpu, I'd expect 97 to ask more from cpu.

Why is this?

I have noticed more lag recently, it may or may not be related to spring, but I think maybe not as spring 96 has been out for a a very long time and I think it just appeared recently. But people do report high cpu loads, I would be interested in knowing what would cause higher cpu loads as compared to 91.0. Pathfinding?

[Silentwings]

Why is this?

Empircal observation + memory + testing incremental version changes over the years + circumstantial evidence on the mantis ticket you're quoting. I haven't actually run 91 for years but its also what you'd naively expect since 97 has a tonne of extra features over 91. If you want something accurate for comparing 91<->97, don't ask me, I'm not even interested in finding out.

[varikonniemi]

Catalyst 14.10 did not affect the FPS noticeably, but i have not seen a single assert error since upgrading. Only bw & packet limit reached.

[Google_Frog]

Silentwings the real question is whether it is reasonable that dev seems to be slower than 91.0. The past few releases seemed to be more focused on performance and bugfixing (eg multithreading) than new features. You should care whether 91.0 runs better than dev because if 91.0 runs better then there has been a regression somewhere or some new features is not worth the cost.