Spring RTS Engine

What do these errors mean?
What should we do with them? Should we mantis them with replay+infolog?

A very naive talking-out-of-ass guess would be that this is related to the massive array of timer-related asserts that were added during hunt for #3845.

If so, then this just might be related to what Flozi reported in other thread:

I seem to get a really bad stutter when middle-click scrolling around, even though fps counter shows constant, again 1250 was fine.

It means something in the timekeeping is 'slightly wrong' enough to fail an assert, but DT=49.000000ms, is small enough that likely you won't have spotted it in practice.

edit: kloot said it better

CTO is the current time offset (graphical interpolation factor) between two consecutive simframes.

Normally (if the system timer can be trusted) this should increase monotonically from 0 to 1* and reset when a new simframe rolls around (every 33 millisecs at standard game speed, the DT value should be in this neighborhood).

Values significantly greater than 1 will manifest themselves as stutter in various ways (through camera movement, positions where units are rendered, etc) but those should never occur under normal conditions except during peak loads (like issuing /give all).

During the 94-->95 development cycle Spring's timing routines were changed to take advantage of high-resolution clocks available on modern systems for smoother interpolation, which turned out to be broken on Windows <= 7 (long story) and we added asserts to track down the problem and alert us of future regressions.

You can try setting UseHighResTimer=1 (Windows-only) in springsettings to see if it helps, but on XP/Vista/7 I wouldn't bother.

* not exactly 1

We seem to be getting quite a few people with this assert and noticable stutter with windows 7 64 bit in 95.0.

How big are the CTOs? I'm on win7 64 and in some (but not all) intense games I start getting CTOs of up to 2.0 and rare ones of up to 5.0/6.0 at absolute worst - resulting jumpiness is only just noticeable for me if I'm trying to see it.

@devs: Would be good to know what level of CTO we should report?

I guess we all have some gadgets that mostly do nothing but then once every, say, 60 frames do something expensive; is it possible it's these causing some unusually long simframes?

I got that error, too. Win7 64, CTO mostly from 2-4.5.

got same errors on two different computes
i7 920, i7 k4770 nvidia 680, nvidia 780

getting micro timing hiccups in fps like i can show u in the videos i made from screen - the stuttering is not the smartphone video - its the game what does not run smooth (see the CTO = > 5 times when it happens)

vsync on off, workerthread count 0 / 5, luaui off isnt fixing the assert(CTO <= 1.0f) errors

but on pausing all works smooth xD no errors then

running W7 x64 on both machines

https://www.youtube.com/watch?v=pJrzb55eLP8
https://www.youtube.com/watch?v=zoCi7HttKYQ

added one more video with dpc latency checker and taskmanager open
i play there on my DAW and its optimised for NO DROP OUTS (if u know what it means)

https://www.youtube.com/watch?v=YExiWVmeobE

please help me to get rid of that hiccups
i like smooth gaming like in the previous spring version (there it was absolutely nice)

i will check out settings and stuff if some of u devs will assist me

That is a freaking monster setup with 200+ fps on late game DSD!

Ive been getting these quite frequently lately, even on non peak conditions. It happens far more often if I have debug view on.

Engine devs, what kind of test cases should we perform to help reduce this microstutter? Is thwre any special build we should be running? Any config options?

next release contains extended debug info

So should we start testing with the latest develop builds? In the mean time, should we examine our gadgets and widgets to ensure even frame by frame loads?

These micro-stutters probably have the same cause as the macro-stuttering reported in #4138 and aren't new to 95.0 or even to Spring (check http://www.sleipnirstuff.com/forum/view ... hp?t=16146, note the date) itself.

Most likely it is a driver degeneracy activated by some OpenGL operation, the challenge would be finding out which. If you have an OGL debugger handy you can try to look at functions that soak up disproportionate amounts of gpu time.

Any config options?

For CTO's not much larger than 1 under light / moderate load, UseHighResTimer=1 (as I said earlier there is a 99.99% chance this won't help at all, but it will eliminate the timing changes in 95.0 as a factor). Safemode would also be useful to rule out the settings disabled by it.

In the mean time, should we examine our gadgets and widgets to ensure even frame by frame loads?

That never hurts but I don't think gadget auditing should be a priority (unless /luarules disable magically gets rid of the asserts...), except for plugging the memleak which showed up here.

Ok, trying gDEBugger. Ill play around with it as it looks overwhelmingly complex at start.

i hope its fixed in next version
thanks behe,kloot for the research and fix

new version 96 does not seems to be better in first try

did a quick smartphone vid in hd

http://www.youtube.com/watch?v=EMyyakxujPM

Muckl, Could you try two things: 1. run the replay to see if that jitters as well.
2. Restart your computer and play a game to see if the jitters are lessened. I definitely know that when I havent restarted in a few days I get way worse jitters.

i never run over night
and it was first game

i make some new videos when i have time
do it with pc + laptop as spec
then replay from that game with pc and laptop