twitchy graphics

[Zieman]

This little thing has been bothering me as long as I have been playing Oolite, from 1.72 onwards:
Graphics are not smooth all the time, some twitching happens all the time. I first thought that my PC wasn't up to the task, but now I'm sure that's not the case.
Twitching is easy to verify, just launch from a station, stop and watch the station rotating - you should see a twitch at least once per rotation.
So far I've seen this behaviour on:
Core2Duo E6600 & Ati 3870HD (Windows XP pro 32 bit)
Core2Duo E7600 & Ati 3870HD (Windows XP pro 32 bit)
Core2Duo E7600 & Geforce GTS450 (Windows XP pro 32 bit)
Core2Duo E7600 & Geforce GTS450 (Ubuntu 12.04 64 bit)
Core i7 2670EM & Nvidia Quadro 1000M (Windows 7 pro 64 bit)
Core i7 4770K & GTX 780 (Windows 7 ultimate 64 bit - 1.77.1 32bit & 64bit builds, both test & deployment)

[Cody]

... just launch from a station, stop and watch the station rotating - you should see a twitch at least once per rotation.

Not always - the 'twitch' is unpredictable. At times over the past year or two, it has been really bad (I no doubt bored the Admiralty with my moaning) - at other times, I hardly notice it. For example, I just sat and watched a station rotating (something I spend a fair bit of time doing in normal game-play), and there was no twitch at all.

[Smivs]

Is this the same thing I'm getting? This has bugged me for ages - take a look at the buoy video I posted on 'Screenshots' if you want to see it. That stuttering is not a problem with the video but happens in-game.
Intel quad-core CPU/4GB RAM
nvidia GTX550ti graphics card with 4GB on-board RAM
Ubuntu 10.10
Oolite v1.77.1

[Cody]

Is this the same thing I'm getting?

<nods> I reckon so... it can be apparent in other circumstances too (but it does come and go).

[Diziet Sma]

I'm inclined to think that a lot of it (though probably not all) is due to background processes briefly pre-empting the game.

I find it helps to kill unnecessary background processes. Not the simplest thing in Linux, to be sure, unless you know your way around the process list fairly well, but I always at least disable ethernet and WiFi while playing, and find that it helps.. Running a lightweight desktop environment helps too (I'm looking forward to trying Enlightenment E18 as soon as the Arch devs release it!). I'm also experimenting with a low-latency kernel, with results that look promising. I suspect playing with process priorities and 'nice' might pay dividends also.

For Windows users, I used to use, and highly recommend Game Booster. It shuts down all unnecessary processes while your game is running (and restores them after you exit the game!), and helps a lot with performance.

[CaptSolo]

I'm with Diz on background processes causing stuttering. Oolite 1.79 runs very smoothly on my old hardware except when the OS butt's in with updates of one kind or another. But then, the game restricts me to minimum graphics detail. I rather liked the flaring suns and nebulae of previous versions of 1.79, but they did impact frame rate.

[Zieman]

I'm inclined to think that a lot of it (though probably not all) is due to background processes briefly pre-empting the game.

I find it helps to kill unnecessary background processes. Not the simplest thing in Linux, to be sure, unless you know your way around the process list fairly well, but I always at least disable ethernet and WiFi while playing, and find that it helps.. Running a lightweight desktop environment helps too (I'm looking forward to trying Enlightenment E18 as soon as the Arch devs release it!). I'm also experimenting with a low-latency kernel, with results that look promising. I suspect playing with process priorities and 'nice' might pay dividends also.

For Windows users, I used to use, and highly recommend Game Booster. It shuts down all unnecessary processes while your game is running (and restores them after you exit the game!), and helps a lot with performance.

I'm not too keen on having some 3rd party program fiddling with my OS, but I guess giving that Game Booster a try won't hurt.

Feels just weird that a killer rig like my new PC should notice such things at all - as much more resource demanding games do not have this issue. Maybe it is OpenGL thing?

Funny thing is that when I tried to record the phenomenom on video with FRAPS, the jittering ceased immediately as I started the recording and resumed once I stopped the recording.

Another funny thing is that both FRAPS & in-game FPS counter shows constantly fluctuating 56-63 FPS, not matter which build I run, no matter if I run it with or without OXPs and no matter if I enable or disable vertical sync in NVidia Control Panel.

On my Old PC the fluctuation was between 59 & 61 FPS, dropping to 55 for a second for every new or destroyed NPC ship, and to 45-55 with more than 150 entities with lots of stuff on screen.

[cim]

One thing you can try is turning on the universe.profile log group in your logcontrol.plist.

Then, run the game (start by running in strict mode, to rule out OXPs as a cause, but if that doesn't work maybe it can be narrowed to a particular OXP?), do whatever it takes to get a stutter, and as soon as you see the stutter, hit the screenshot button (because this is the easiest way to put a marker in the log file). Then close the game as quickly as possible. Try to do this quickly, because you'll get a very large log file.

Code: Select all

11:48:41.730 [universe.profile.update]: Begin update
11:48:41.730 [universe.profile.update]: update:entity
11:48:41.731 [universe.profile.update]: updating linked lists
11:48:41.731 [universe.profile.update]: collision and shadow detection
11:48:41.731 [universe.profile.update]: clean up
11:48:41.731 [universe.profile.update]: Update complete
11:48:41.731 [universe.profile.draw]: Begin draw
11:48:41.732 [universe.profile.draw]: Begin opaque pass
11:48:41.735 [universe.profile.draw]: Begin translucent pass
11:48:41.738 [universe.profile.draw]: Begin HUD
11:48:41.741 [universe.profile.draw]: End drawing

You'll get a very long list of these sets of log lines, which describe the top-level parts of each frame. A typical frame might look like this: total time between "Begin update" and "End drawing" is 11ms. There probably won't be a lot of variation, either.

Then, search for the screenshot log line. Assuming you were reasonably quick with the button, somewhere not far above it will be a group where the time between "Begin update" and "End drawing" is much higher. If you post that group and a typical group here, we might be able to start locating the problem. (Anyone else with stutter can do the same: there may or may not be a common cause)

[Smivs]

Interesting. I've been doing a bit of testing/experimenting and it does seem to be system load causing this, but only up to a point. One thing I hadn't considered was that I always have at least one BOINC task running and suspending that certainly helps. BOINC does use the graphics processor as well as the main CPU so this is not totally surprising.
Also, actually recording the video does impact on performance, but not too much. I use ffmpeg started and stopped via command line.
Playing youTube videos also loads the system a bit, as does music playback to a lesser extent. Normally I leave the browser open (with 5-10 tabs open) and this does not seem to make any difference.
As an extreme case I started Oolite with BOINC running, then started a youTube video and played some archived music (mp3s). I then started recording Oolite. The stutter was noticeable, but oddly not as bad as the other day when I made the buoy video. fps was steady around 59 throughout.
I then repeated this a couple of times, and the degree of stutter was variable. On one occassion it was absent, and at no time was it as noticeable as when I did the buoy video.
Conclusion:-
This is a system resource issue, and can therefore be limited by the user. However the problem is variable in the sense that the degree of stutter varies even when the load on the computer is constant, and therefore sometimes it is fine when the computer seems to be quite busy, but it can also occur when the computer is under very little load. I don't know how helpful knowing this actually is!

[another_commander]

OK, here we go. In between the dashed lines is the moment the stutter occurred. Normal frame refresh to that moment was around 14-16ms, then all of the sudden a whopping 313ms (!). Main culprits seem to be entity update and opaque drawing pass.

Code: Select all

10:31:54.623 [universe.profile.update]: Begin update
10:31:54.623 [universe.profile.update]: update:entity
10:31:54.624 [universe.profile.update]: updating linked lists
10:31:54.624 [universe.profile.update]: collision and shadow detection
10:31:54.624 [universe.profile.update]: clean up
10:31:54.624 [universe.profile.update]: JS Garbage Collection
10:31:54.624 [universe.profile.update]: Update complete
10:31:54.624 [universe.profile.draw]: Begin draw
10:31:54.624 [universe.profile.draw]: Begin opaque pass
10:31:54.636 [universe.profile.draw]: Begin translucent pass
10:31:54.637 [universe.profile.draw]: Begin HUD
10:31:54.638 [universe.profile.draw]: End drawing
	--------------------------------------------------------
10:31:54.638 [universe.profile.update]: Begin update
10:31:54.638 [universe.profile.update]: update:entity
10:31:54.834 [universe.profile.update]: updating linked lists
10:31:54.834 [universe.profile.update]: collision and shadow detection
10:31:54.834 [universe.profile.update]: clean up
10:31:54.834 [universe.profile.update]: JS Garbage Collection
10:31:54.834 [universe.profile.update]: Update complete
10:31:54.834 [universe.profile.draw]: Begin draw
10:31:54.835 [universe.profile.draw]: Begin opaque pass
10:31:54.949 [universe.profile.draw]: Begin translucent pass
10:31:54.950 [universe.profile.draw]: Begin HUD
10:31:54.951 [universe.profile.draw]: End drawing
	--------------------------------------------------------
10:31:54.952 [universe.profile.update]: Begin update
10:31:54.952 [universe.profile.update]: update:entity
10:31:54.953 [universe.profile.update]: updating linked lists
10:31:54.953 [universe.profile.update]: collision and shadow detection
10:31:54.953 [universe.profile.update]: clean up
10:31:54.953 [universe.profile.update]: JS Garbage Collection
10:31:54.953 [universe.profile.update]: Update complete
10:31:54.953 [universe.profile.draw]: Begin draw
10:31:54.954 [universe.profile.draw]: Begin opaque pass
10:31:54.966 [universe.profile.draw]: Begin translucent pass
10:31:54.967 [universe.profile.draw]: Begin HUD
10:31:54.968 [universe.profile.draw]: End drawing

[Diziet Sma]

I'm not too keen on having some 3rd party program fiddling with my OS, but I guess giving that Game Booster a try won't hurt.

All I can say is that it never gave me a moments trouble, and is highly configurable.. if you want, you can fine-tune it on a process-by-process basis to disable only what you want, and it will warn you if you try to do something dumb.. back when it was a 100% Iobit product, I used a series of versions of GB, and while the benefit gained was better with some versions than others, all did just what they claimed, and nothing more. Having all the processes automatically re-start after a gaming session was always painless as well. On the lower-spec systems I was using at the time, it made the difference between Oolite being unplayable (5-8 FPS), and an enjoyable experience (25-30 FPS).

Now that development of GB has been taken over by Razer ("High-performance gaming hardware, software and systems. For Gamers. By Gamers.") I would expect it to get even better, although I haven't tried a Razer version myself yet.. something I must do, now I have a Win7-64bit install again..

[Cody]

Main culprits seem to be entity update and opaque drawing pass.

A clue/progress at last?

@Diz: I'd previously tried all manner of things, but nothing improved it for me.

[Zieman]

Does Oolite impose some kind of V-sync of its own?
If that's the case, I'm leaning towards the conclusion that the culprit lies there.

As I wrote previously, starting a recording with FRAPS completely removed the jitter for as long as the recording phase took.

And, this twitchiness/jittery is a bit different than those occasional stutters you get from entities (ships?) being added (and removed?).
The stutters are apparent also in the recorded videos, but since the recording process itself causes the jitters to disappear, they cannot be seen in the videos.

[another_commander]

Does Oolite impose some kind of V-sync of its own?
If that's the case, I'm leaning towards the conclusion that the culprit lies there.

Yes it does (at least on Windows and Linux), provided that your drivers implement the WGL_EXT_swap_control extension. But I doubt that this would be the root cause of the problem. On my laptop I do not have this extension but I still get the occasional stutter.

A clue/progress at last?

I can't really tell. My theory is that the stutters are related to numbers of entities being added or removed at once in the universe. What I noticed is that sometimes the number of entities in the FPS display starts fluctuating very quickly around the value that is current at the time, most of the times together with the number of collision checks indicator. When this happens, usually stutters occur. Entities being added or removed like that, with the accompanying collision checks, is normally associated with wreckage and alloys generation during explosions. Looking at the code, it seems that this wreckage gets generated when the universe is not close to full and, unless I have missed something, they seem to be generated regardless of where the player is at the time. If this is correct, then I believe we could reduce somewhat the stutter by not generating wreckage (or generate no more than one piece maybe) if the player is not close enough to witness it, e.g. more than 1.5x scanner range.

[Cody]

My theory is that the...

<refrains from quoting Monty Python - nods thoughtfully>