Some observations about performance

[Ark]

Concerning the FPS and stutters I just want to testify some observations that I had.

My configuration is a Core 2 duo processor at 2.4Ghz with 2GBs of Ram and winXP sp2

Video cards
With my original video card Nvidia Gforce 7600Gt I had the maximum of 66fps.At the same system with both a Gforce 8600Gt and a 9600Gt (latest drivers) I have also 66fps. The only benefit that I had from that upgrade is that now I can increase the antialiasing and anisotrofic filtering settings for oolite in my Nvidia control panel. The v-sync setting also seems to be irrelevant. Also a better video card seems not to decrease the stutter problem (with the exception of being near a heavy textured object – black monk monastery for excable)
That leads me to the conclusion that the power of your video card is irrelevant (at least from a point and above) to the maximum fps that you can have in the PC version of oolite

Monitors
With my old 19” CRT monitor at 1024 x 768 with 86Hz I had the maximum of 66fps
Recently I have changed it with a 22” wide screen one that operates at 1680 x 1050 with 60Hz I also have the maximum of 66fps when running oolite
That also means that the speed, resolution and frequency of the monitor is also irrelevant to the maximum fps that you can get from oolite. Also this change did not affect the stutter problem.

Memory
When I upgraded my system from 1Gb to 2Gbs I did not see any improvement to the maximum fps but the stutters that I had are less painful now. This is an upgrade that I strongly recommend to all ollite players that have a lot of oxps loaded. You may not increase the maximum fps of oolite but with more memory you can have more oxps and the most important of all PC memory is cheap.

CPU
Unfortunately I have the same processor for 1,5 years now and it is not easy just to borrow a better CPU from a friend of mine in order to test oolite but I think a 2,4 core 2 due CPU is far from enough for running oolite.

Is there anybody with a PC that has more that 66fps and with what configuration? I am very curious.

Stutter problem
After a thorough observation I end up believing that the main reason for stutters is purely the numbers of objects and collisions in the system. When entering a system with more than 100 or 110 objects means that I will definitely have the stutter problem.

Eric says that oolite checks every some seconds the conditions of the scripts (and I have not a reason not to believe that) but this seems not to affect the performance (at least in my system). On the other hand loaded oolite with oxps that populate a system via scripts (Galactic Navy, black monks etch) and icrease the objects have a major impact in the performance.

Moreover I have seen that with 1.71 I have the average of 25 to 30% of processor speed occupied. In a multi processor system (given the fact that oolite only uses the second core for a very specific reason) all the hard work is done by the first core. In other words a 30% in a dual core system means almost 60% of the processor speed. In 1.70 with the same oxps I have 10% to 20% of the processor speed (instead of 25% to 30% that I have with 1.71). Just mention it. (Nothing is running in the background)

I know that Ahruman is planning to give oolite the ability of frustum culling and I want to believe that this will be a major improvement for oolite but after all I have seen I do not know if this would be enough.

I am writing the post not as a criticism to the dev team but in order to help them improve oolite. Also i want to help the members of the comunity that want to make an upgrade in there hadware.
After all how many crazy people out there will change 3 video cards in less than a month in order to test the performance of oolite?

[davcefai]

I think you have to also consider that it is not just a case of checking the script conditions every few seconds but also acting on the scripts.

Probably the CPU needs to work harder with the big, multi-entity generating OXPs. After all the CPU first needs to work out what is happening to each and every object before the graphics subsystem can display it.

[Svengali]

On my system the stuttering seems to be related to wormholes. It doesn't matter how much objects are there, but by opening a wormhole (even far away) the FPS drops to 12. It even runs quite smooth with a lot of collisions.

[Ark]

On my system the stuttering seems to be related to wormholes. It doesn't matter how much objects are there, but by opening a wormhole (even far away) the FPS drops to 12. It even runs quite smooth with a lot of collisions.

Yes I can confirm that. But only the big stutters that are less frequent.
But the vast majority of them (the ones that last for 1-2 seconds but sometimes repeated every 20 or 30 seconds) have to do with the number of objects and the processing power oolite needs in order to support them

[Ark]

In a multi processor system (given the fact that oolite only uses the second core for a very specific reason) all the hard work is done by the first core.

I was wrong that applies only in windowed mode.
In full screen mode it is the second core that reaches its limits. Frustum culling may be the answer to a lot of performance problems.

[JensAyton]

You are correct in that Oolite is essentially single-threaded. This is unlike to change; we can offload relatively minor tasks like audio and texture loading to secondary threads, but making full use of a multiprocessor system would require a complete redesign of the game.

However, Oolite should not be anywhere close to CPU-bound on a 2.4 GHz system, or for that matter any consumer multiprocessor system. I’m using a 2.4 GHz Core 2 Duo myself, and usually see 100 FPS in the “test release” build of Oolite with about 35%–50% CPU consumption (that’s 50% of one core; OS X uses a scale of 0%–200% for dual-core systems). I also see good performance on my much slower 1.6 GHz PowerPC G5.

The steady 66 FPS number, and the fact that it’s stable across different resolutions and graphics cards, suggests that the game is not GPU-bound either. Rather, it’s trying to run at 100 FPS – Oolite always does, without taking the screen refresh rate into account, a flaw I’ve been ignoring because it doesn’t cause practical problems on my test systems – and skipping every third frame. This is almost certainly because vsync is active. If you’re turning it off using the NVidia control panel and still seeing 66 FPS, it seems likely that the setting is being ignored, or overridden by Oolite (or rather, by SDL). I’m not certain what to do about this; it’s always hard to fix problems on a platform you’re not using.

[ovvldc]

There might also be a gain in simply not rendering any object that is further away than a specified size/distance factor, even if it is inside the viewing frustrum. Anything that is smaller than one pixel at current range should be safely ignored when rendering...

Which reminds me, is there any way that objects the gallery that comes up when you start a fresh Jameson can be made to not completely appear from infinity? It takes relatively long to go through them all this way, especially if you want to check the ships contained in another OXP you have just installed.

Best wishes,
Oscar

[Ark]

This is almost certainly because vsync is active. If you’re turning it off using the NVidia control panel and still seeing 66 FPS, it seems likely that the setting is being ignored, or overridden by Oolite (or rather, by SDL).

Thank Ahruman
I have already done this with not effect.
The default setting for Nvidia cards is application controlled. It seems that in full screen mode the vsync is on but in windowed mode is off.
Nevertheless when I switch vsync off I have the same maximum fps (66) with the negative side effect that I have also the tearing effect (that is awful in my TFT monitor).
So I prefer to leave vsync as it is (application controlled aka on in full screen mode)
What is really puzzled me is the latest observation that I had about the performance of the second core in full screen.
Usually when I open the task manager I run oolite in windowed mode and that is the reason why I did not noticed that until today.

[another_commander]

Nevertheless when I switch vsync off I have the same maximum fps (66) with the negative side effect that I have also the tearing effect (that is awful in my TFT monitor).

Now that I think of it, if you have tearing with Vsync off, it means that the graphics processor is rendering more frames per second than your monitor can refresh. I don't know why it still reports 66 fps, but something looks wrong there.

Also, I run a small test, just a few seconds of full screen with Task Manager on the background. viewing a textured planet. I am running on an Intel Core 2 Duo 1.8GHz CPU, 2GB RAM. The results are here (sorry for not posting the actual screen, the image hosting site I use is acting up): http://terrastorage.ath.cx/Marmagka/urz ... rmance.png. The graph indicates no major performance problems. Mind you, that at the same time as Oolite, I have Internet Explorer (a well known system hog) and UltraEdit32 running as well. So, I am not really sure why your system is using fully the 2nd core, it normally shouldn't have to.

[Star Gazer]

I have been observing the CPU performance since reading this thread, and I am fascinated by the way that the game is passed from core to core very regularly, making it appear at first that all 8 cores are in use. (MacPro 2x quad-core Xeon)

Obviously this cannot be the case, but the computer seems to be sharing out the work by itself! This is in windowed mode, in order to observe the CPU monitor; I'm getting 99-100fps with 80-90 objects.

[JensAyton]

There might also be a gain in simply not rendering any object that is further away than a specified size/distance factor, even if it is inside the viewing frustrum. Anything that is smaller than one pixel at current range should be safely ignored when rendering...

Always been done.

Which reminds me, is there any way that objects the gallery that comes up when you start a fresh Jameson can be made to not completely appear from infinity? It takes relatively long to go through them all this way, especially if you want to check the ships contained in another OXP you have just installed.

Nope.

[LittleBear]

You can use the left and right arrows though on the Ship Parade to quickly flip through the ships.

[JensAyton]

I have been observing the CPU performance since reading this thread, and I am fascinated by the way that the game is passed from core to core very regularly, making it appear at first that all 8 cores are in use. (MacPro 2x quad-core Xeon)

This is normal. Programs do not assign their tasks to specific processors, they just create threads which are assigned to processors by the operating system. The OS X kernel does not provide any form of “processor affinity”; threads are simply doled out among the processors in an effectively random way.

[Star Gazer]

This is normal. Programs do not assign their tasks to specific processors, they just create threads which are assigned to processors by the operationg system. The OS X kernel does not provide any form of “processor affinity”; threads are simply doled out among the processors in an effectively random way.

...well, well, well, thanks Ahruman, I hadn't realised that was an intrinsic property of the operating system. It does make sense in terms of loading, and thermal constraints.