First post - problem report - PC install

[Phoenix4]

Hello there!

This is my first post after finding Oolite by pure chance and installing it on Tuesday this week.

It's great to see someone making such a true remake of this classic - I always enjoyed Elite as a kid, and reached 'Deadly' if memory serves me right.

Anyway I installed it, and took a flight from Lave to the nearest other station (planet) - name escapes me - then it froze!

I couldn't return to Windows so had to just power the system off and reboot it. After several attempts it always locked-up after about 20-30 mins or so.

So unfortunately I haven't been able to play much of it. The system was AMD Athlon 1.4GHz, 512MB, GeForce3 card, Win XP Pro (SP2).

Are ther any files, crash logs, etc. I can send that may be of help?

Px4

[milinks]

Hi Phoenix welcome aboard. If you installed Nics installer without changing the installation directory, then aim for C:\Program Files\Oolite. Within there is a text file called stderr.txt - within this file is your crash reports, and should tell you all you need to know. It is strange that you are actually running it and then it crashes so quickly. Previously i had a problem with OpenGL drivers, check with DxDiag that they are all installed ok. Hope this is of some help. The windows version is the most unstable version thus far, due to exporting it from Mac, but the fantastic work put in by Dajt and Nic etc are making it extremely playable

[Phoenix4]

Hi -

I'll take a look at those files when I get home tonight, and post anything interesting.

On another note - it works with my USB Saitex x45 throttle and stick combo!

That WAS a surprise!

It's a shame it doesn't play longer than half-hour - but it's great this game is on it's way.

Px4

[Phoenix4]

OK, below are the contents of the stderr.txt file.

The game started OK, took off from Lave to the planet directly north (begins with R - I'm bad with names!!). Flying along - got into a few dogfights, beat them - approached the planet - no indication I was near the space station - altimiter was low due to planet.

No compass to advise of station heading - or 'S' appearing. Could not find the station anywhere.

After a few mins of flying around trying to locate it the screen just froze.

Here's the results of 22 mins gameplay, hope it helps - Px4:

2006-02-01 17:40:45.000 oolite.exe[2876] initialising SDL
2006-02-01 17:40:46.000 oolite.exe[2876] init: numSticks=1
2006-02-01 17:40:46.000 oolite.exe[2876] CREATING MODE LIST
2006-02-01 17:40:46.000 oolite.exe[2876] Unknown architecture, defaulting to 1024x768
2006-02-01 17:40:46.000 oolite.exe[2876] Added res 1920 x 1440
2006-02-01 17:40:46.000 oolite.exe[2876] Added res 1792 x 1344
2006-02-01 17:40:46.000 oolite.exe[2876] Added res 1600 x 1200
2006-02-01 17:40:46.000 oolite.exe[2876] Added res 1360 x 768
2006-02-01 17:40:46.000 oolite.exe[2876] Added res 1280 x 1024
2006-02-01 17:40:46.000 oolite.exe[2876] Added res 1152 x 864
2006-02-01 17:40:46.000 oolite.exe[2876] Added res 1024 x 768
2006-02-01 17:40:46.000 oolite.exe[2876] Added res 848 x 480
2006-02-01 17:40:46.000 oolite.exe[2876] Added res 800 x 600
2006-02-01 17:40:46.000 oolite.exe[2876] Added res 720 x 576
2006-02-01 17:40:46.000 oolite.exe[2876] Added res 640 x 480
2006-02-01 17:40:46.000 oolite.exe[2876] Added res 512 x 384
2006-02-01 17:40:46.000 oolite.exe[2876] Added res 480 x 360
2006-02-01 17:40:46.000 oolite.exe[2876] Added res 400 x 300
2006-02-01 17:40:46.000 oolite.exe[2876] Added res 320 x 240
2006-02-01 17:40:46.000 oolite.exe[2876] Found mode {Height = 1344; RefreshRate = 0; Width = 1792; }
2006-02-01 17:40:47.000 oolite.exe[2876] drawRect calling initialiseGLWithSize
2006-02-01 17:40:47.000 oolite.exe[2876] Creating a new surface of 1792 x 1344
2006-02-01 17:40:47.000 oolite.exe[2876] no universe, clearning surface
2006-02-01 17:40:47.000 oolite.exe[2876] ---> searching paths:
(oolite.app/Contents/Resources, AddOns)
2006-02-01 17:40:48.000 oolite.exe[2876] Vertex Array Range optimisation - not supported
2006-02-01 17:40:50.000 oolite.exe[2876] Populating a system with economy 5, and government 3
2006-02-01 17:40:50.000 oolite.exe[2876] ... adding 8 trading vessels
2006-02-01 17:40:50.000 oolite.exe[2876] ... adding 1 sun skimming vessels
2006-02-01 17:40:50.000 oolite.exe[2876] ... adding 7 pirate vessels
2006-02-01 17:40:50.000 oolite.exe[2876] ... adding 1 sun skim pirates
2006-02-01 17:40:50.000 oolite.exe[2876] ... adding 2 law/bounty-hunter vessels
2006-02-01 17:40:50.000 oolite.exe[2876] ... adding 1 sun skim law/bounty hunter vessels
2006-02-01 17:40:50.000 oolite.exe[2876] ... adding 0 Thargoid warships
2006-02-01 17:40:50.000 oolite.exe[2876] ... adding 4 asteroid clusters
2006-02-01 17:40:50.000 oolite.exe[2876] ... for a total of 24 ships
2006-02-01 17:40:52.000 oolite.exe[2876] OPENGL_DEBUG GL_ERROR (1280) 'invalid enumerant' in: Universe before doing anything
2006-02-01 17:42:03.000 oolite.exe[2876] Populating a system with economy 7, and government 3
2006-02-01 17:42:03.000 oolite.exe[2876] ... adding 3 trading vessels
2006-02-01 17:42:03.000 oolite.exe[2876] ... adding 1 sun skimming vessels
2006-02-01 17:42:03.000 oolite.exe[2876] ... adding 6 pirate vessels
2006-02-01 17:42:03.000 oolite.exe[2876] ... adding 1 sun skim pirates
2006-02-01 17:42:03.000 oolite.exe[2876] ... adding 1 law/bounty-hunter vessels
2006-02-01 17:42:03.000 oolite.exe[2876] ... adding 1 sun skim law/bounty hunter vessels
2006-02-01 17:42:03.000 oolite.exe[2876] ... adding 0 Thargoid warships
2006-02-01 17:42:03.000 oolite.exe[2876] ... adding 0 asteroid clusters
2006-02-01 17:42:03.000 oolite.exe[2876] ... for a total of 13 ships
2006-02-01 18:00:59.000 oolite.exe[2876] Creating a new surface of 1792 x 1344
2006-02-01 18:01:04.000 oolite.exe[2876] OPENGL_DEBUG GL_ERROR (1280) 'invalid enumerant' in: Universe before doing anything
2006-02-01 18:01:08.000 oolite.exe[2876] Creating a new surface of 1280 x 998
2006-02-01 18:01:08.000 oolite.exe[2876] OPENGL_DEBUG GL_ERROR (1280) 'invalid enumerant' in: Universe before doing anything
2006-02-01 18:02:06.000 oolite.exe[2876] Creating a new surface of 1284 x 1002
2006-02-01 18:02:06.000 oolite.exe[2876] OPENGL_DEBUG GL_ERROR (1280) 'invalid enumerant' in: Universe before doing anything
2006-02-01 18:02:11.000 oolite.exe[2876] Creating a new surface of 1280 x 998
2006-02-01 18:02:11.000 oolite.exe[2876] OPENGL_DEBUG GL_ERROR (1280) 'invalid enumerant' in: Universe before doing anything

[Phoenix4]

Forgot to add:

The PC is running DirectX version 9.0c (4.09.0000.0904) - info from DxDiag.

I did all the display tests in DxDiag, and they all passed - DirectDraw, Direct3D etc.

Hope that's helpful - anything else that can be of benefit?

Px4

[winston]

The game uses OpenGL rather than Direct3D (or whatever Microsoft's proprietary knock-off of OpenGL is called).

You can actually see the space station from as far away as the witch point beacon if it's lit by the sun. It will appear very small at those ranges, of course. As you get closer in, it should be more visible. Get the Advanced Space Compass as an early upgrade, you can set it to the navigation buoy and fly straight to that.

However, if you fly straight at the planet you should at some point get in the S zone (and the normal space compass will then indicate the station). If you don't you'll have to just orbit the planet till you find it - although once you know what you're looking for, you'll find you can almost always find it from the witch point beacon.

[Phoenix4]

OK, I tried it again, 5 mins into play it froze - after several minutes I was able to bring up the Windows Task Manager - Oolite.exe was using over 198MB of memory!!

It brought the system to an entire stop.

Oh well, guess I'll have to wait for the next build.

Apart from that the game looks and plays great.

Px4

[TGHC]

Get the Advanced Space Compass as an early upgrade, you can set it to the navigation buoy and fly straight to that.

However, if you fly straight at the planet you should at some point get in the S zone (and the normal space compass will then indicate the station). If you don't you'll have to just orbit the planet till you find it - although once you know what you're looking for, you'll find you can almost always find it from the witch point beacon.

The latest windows build doesn't have any compass at all, so at the moment the enhanced compass is no help.

Locating the planet after straying from the direct line is a bit hit and miss but doable if you are systematic. Also ships with escorts will point you in the right direction.

Finding the space station is tricky when it's in shadow, it's best to stop a bit short of the planet and hunt around it's circumference, but you have to be alert. Another way is to follow a ship with escorts, they head for the planet and then break off towards the space station, but it's a very slow process.

[TGHC]

OK, I tried it again, 5 mins into play it froze - after several minutes I was able to bring up the Windows Task Manager - Oolite.exe was using over 198MB of memory!!

It brought the system to an entire stop.

It's intermittent, I sometimes get a whole hours play and sometimes only 5 mins. Shift Q and start again, and don't forget to save at every planet.

[winston]

It's quite usual for Oolite to have an image size of 200MB or so once you have encountered a number of ships. When it loads textures, they are stored in memory as bitmaps and kept cached. When it loads sounds, they are kept as uncompressed WAVs and cached.

There are some known issues (crashes) with the release that the latest Windows build was built again - the crashes at least were fixed for 1.62 on OS X and Linux. One of the crashes was random in nature - you could either see it in 5 minutes or 5 hours of play (and it could be triggered by the AI, if an AI ship shot another AI ship in the right way).

[Phoenix4]

Hi, quick question -

If it leaves a footprint of approx 200MB to run, how do less powerful systems cope with this game?

I have another system I here I use purely for testing apps (part of my job) - it's a similar spec, but only with 256mb memory.

Will it run, or will this lock-up more frequently, or will the game throttle the performance to cope with the power decrease?

Also, is there anything I can change within the game to make it run faster? - graphics, resolution etc. etc.

Thanks all - Px4

[JensAyton]

A decent virtual memory system will page out textures and sounds that aren’t actively being used. This ought to be roughly as efficient as on-the-fly loading and unloading – and would be much more so if it weren’t for the fact that texture files are compressed. I’m not in a position to comment on the decency of Windows in this regard.

[winston]

Disclaimer: I don't currently have a Windows machine, so I can't say for the Windows build. I'm not entirely sure how the Windows task manager is showing you the process size; on modern operating systems, quite a lot of the memory can be shared - for example, Oolite on Linux (using 1.62-2, the current stable version) shows a total size of 170MB, but the actual unique memory being used by the process is only 70MB (so 100MB of the process's size is also being used by other processes on the system, and would be in use whether Oolite was running or not - this will be things like code and data from various system libraries, pieces of the X Window system etc.)

In any case, Oolite wasn't really designed for 'low end' systems (i.e. things more than about 5 or 6 years old). To be decently playable it does at least require something better than the typical onboard Intel Integrated Graphics - although nothing outrageous : my old GeForce 4200ti is fine for running the game almost continously at 100fps (just to show you what decent OpenGL does for you: running on a 2GHz Pentium 4 with Intel Integrated onboard graphics yields only around 11fps after launching from the space station - the same machine with a 3 year old GeFore 4200ti will render the same scene at 100fps, which is Oolite's maximum).

[winston]

A decent virtual memory system will page out textures and sounds that aren’t actively being used [...] I’m not in a position to comment on the decency of Windows in this regard.

The Windows VMM is anything *but* decent (another disclaimer: I've not looked at the gory details since NT4 -- but nothing indicates that the VMM has changed in a major way since NT4). I have a sneaking suspicion the VMM is why where you'd traditionally have one Unix box running many services, Windows admins typically prefer to have one service per box instead (and some years ago when we moved from OS/2 to NT4, without changing anything else - our development machines needed double the memory despite the freshly-booted footprint of NT4 not requiring significantly more memory than OS/2).

The Windows VMM is particularly prone to causing unnecessary swapping storms. I'll try and explain it.

A VMM will look to page out unused memory - some more agressively than others (the Linux VMM in particular is tunable in that respect - you can turn "swappiness" down to zero where it will try and avoid paging anything out at all unless it has to, or increase it to 100, where it will agressively page out any memory pages that even have the hint of not being touched). But one of the jobs of the VMM is to manage what stays in physical RAM and what gets put out to disk. On the x86 architecture, each memory page is 4 kilobytes.

The VMM also looks after a page table. This is a lookup table saying this virtual address is physically located >here<, so when a process runs, virtual addresses can be mapped to where the 4 kilobyte page really is. It might not even exist in physical memory (at which point, the CPU raises a page fault - the VMM catches this then goes looking for this page). So when you open the Task Manager, and add the Page Faults column to the list of stuff it displays, generally - whenever you see a page fault, this is when the OS has had to go and fetch a page from the swap space on disk.

To make the page lookup faster for frequently used pages, the x86 processor has something called a TLB - translation lookaside buffer - basically a very fast on-CPU page table cache that holds a few page table entries. The TLB on an x86 processor holds 64 entries. The TLB increases the performance of your process as the CPU can just look on this on-chip cache to find the next page in physical memory, rather than going through the main set of page tables.

So where is all this guff leading?

Well - imagine you have a large process sitting in main memory. The VMM must decide what to do with the memory belonging to this process - does it need to push some 4K chunks out onto disk? Each VMM implementation will have its own way of deciding (and as I mentioned earlier, some VMMs are tunable in this respect).

The Windows VMM has something called the trimmer. The trimmer's job is to look at a processes' working set (let's say in this example, Oolite) and figure out which pages should be booted out of main memory and put in to the swap space. It runs periodically, examining the working sets. The thing is, the Windows trimmer only looks in the CPU's TLB (that 64 page table entry cache I mentioned earlier) to figure out what should be trimmed. Now this is all very well - looking in the TLB is cheap because it's a fast on-CPU cache. The trouble is the TLB holds 64 page table entries that were *recently used*. So - somewhat antithetically, the trimmer is only looking at recently used pages to see what to push out of a process's working set! In most instances, this works, and processes do get trimmed.

The trouble with Windows really starts when a process actually frequently uses all the pages pointed to by the TLB - because the trimmer will never, ever find any pages that it can swap out. The rest of the process might be completely unused, but once its pages are in the working set, if they never show up in the TLB, they never get looked at by the trimmer. So now imagine a second process starts up that needs to use a lot of memory. This second process now starts a huge swapping storm because instead of the first big process getting mostly swapped out and left swapped out (because it's not actually actively using most of the memory it has in its working set) the second process instead gets starved of physical memory. The machine will now thrash till kingdom come.

(There are tools to force the Windows VMM to reduce a process's working set, but the VMM should really be able to do it automatically without human intervention).

Now why would Microsoft design the VMM in this way? Well, when NT was designed, the x86 processor was crap. It was probably too expensive (in terms of CPU operations, cache misses etc. to have the trimmer go outside the TLB. Unix systems typically ran on much more capable hardware than the lowly PC of the time and could have the luxury of a more capable VMM design. The VMM has probably simply been ossified ever since because after all, it's cheaper to let customers buy more RAM than spend the money on re-engineering the VMM which otherwise works.