Oolite Bulletins

I'd like to suggest adding a "status bar" to the initial start up screen. I've noticed it takes the 1.75.x trunk builds longer to load than previous versions. I'm assuming it's at least partially due to the OXP checking going on. I've got about 20 OXPs I test with and sometimes I think Oolite may have "hung" during the initialization process.

Perhaps something like they used in the Sims would be cool. Printing text that told the user what was happening.

Initializing ...
Checking <OXP name> ...
Creating Witchspace sub-ether ...
Loading ship lists ...

That sort of thing.

Cheers.

Loading takes longer every time Oolite has to start clean and rebuild the cache. This happens normally on the first startup after having removed or added an OXP, whenever you start the game with Shift down, or if you have set the "always-rebuild-cache" option to YES inside .GNUstepDefaults. In reality, the OXP loading time has not been changed between the trunk and last official release versions, but it may appear so if you are comparing start up times with and without rebuild of the cache.

SiriusCG wrote:

Initializing ...
Checking <OXP name> ...
Creating Witchspace sub-ether ...
Loading ship lists ...

That sort of thing.

Which is exactly the sort of thing happening already, so I don't understand the suggestion. The status messages displayed during program start are (in exactly this order):

Initialising universe...

Loading ship data...

Populating space...

Running scripts...

Loading player...

Commander McLane wrote:

Which is exactly the sort of thing happening already, so I don't understand the suggestion. The status messages displayed during program start are (in exactly this order):

Initialising universe...

Loading ship data...

Populating space...

Running scripts...

Loading player...

Only on the Mac version of the game (at least for now), I'm afraid...

Only on the Mac version of the game (at least for now), I'm afraid...

Dang! I KNEW I shoulda bought a Mac last upgrade!

Cheers.

another_commander wrote:

In reality, the OXP loading time has not been changed between the trunk and last official release versions, but it may appear so if you are comparing start up times with and without rebuild of the cache.

Not true. Trunk takes several times longer to start up. It is this way since all the check code was added. I just timed it from start to the Y/N message on my 3 MHz Mac with many oxp installed:

1.74 with shift presses : 6 seconds
trunk with shift pressed: 25 seconds
trunk without shift pressed: 18 seconds.

So the main difference is not cache building. I think that is is the JS code checks that slow things down. And not only during startup but also witchspace jumps take much longer in trunk.

I also get the feeling that having a lot of active JS ship-scripts make the screen a bit stuttering sometimes. Its not happening with 1.74. But it may also be the shader code that is responsible for that. Anyhow, shooting a ships down fixes the problems sometimes.

Eric Walch wrote:

Trunk takes several times longer to start up. It is this way since all the check code was added. I just timed it from start to the Y/N message on my 3 MHz Mac with many oxp installed:

1.74 with shift presses : 6 seconds
trunk with shift pressed: 25 seconds
trunk without shift pressed: 18 seconds.

So the main difference is not cache building. I think that is is the JS code checks that slow things down.

This may be applicable on the Mac and Linux, where the JS ObjC native exceptions are used and profiling actually happens. The Windows trunk builds, however, are a different story. Profiling is not enabled on these builds by default and all the profiling functions are mapped to 'neutral' code. So in theory, there should not be significant difference for them compared to 1.74.2. I have not done any benchmarks to confirm, but now that you have picked my curiosity I might as well do.

another_commander wrote:

So in theory, there should not be significant difference for them compared to 1.74.2. I have not done any benchmarks to confirm, but now that you have picked my curiosity I might as well do.

Its not only the JS stuff slowing startup, but also the shader compiling. When I throw out the 9 oxps with the longest worldScripts, startup is 6 to 8 seconds faster. When I throw out all griff and neolite ships, startup is about 10 seconds faster. With both sets out, total startup time is about 10 seconds for trunk. (Thats still not as fast as 1.74 with all oxps).
You may be right that the extensive checks only happen on mac. Because trunk is still unplayable on a mac. JS code might stop at unpredictable times by timeouts. For oxp development I can only use 1.74.

Eric Walch wrote:

I just timed it from start to the Y/N message on my 3 MHz Mac with many oxp installed:

Are you sure...?

DaddyHoggy wrote:

Eric Walch wrote:

I just timed it from start to the Y/N message on my 3 MHz Mac with many oxp installed:

Are you sure...?

That is still 3 times faster as my old C64....... I have lost counting since.

Eric Walch wrote:

another_commander wrote:

Because trunk is still unplayable on a mac. JS code might stop at unpredictable times by timeouts. For oxp development I can only use 1.74.

Or just modify/disable the JS-killing routine

Eric Walch wrote:

DaddyHoggy wrote:

Eric Walch wrote:

I just timed it from start to the Y/N message on my 3 MHz Mac with many oxp installed:

Are you sure...?

That is still 3 times faster as my old C64....... I have lost counting since.

Actually on the NTSC version of the C64 ran at the full 1MHz, I believe the PAL versions only ran at 985KHz

Micha wrote:

Or just modify/disable the JS-killing routine

Yes, that did I some time ago. I did not kill it completely, but set the time limiter for debug compiles to that of release compiles. Now it rarely triggers.

DaddyHoggy wrote:

Eric Walch wrote:

DaddyHoggy wrote:

Are you sure...?

That is still 3 times faster as my old C64....... I have lost counting since.

Actually on the NTSC version of the C64 ran at the full 1MHz, I believe the PAL versions only ran at 985KHz

I have Casio Calculator watches that run faster than both of those combined!

another_commander wrote:

Commander McLane wrote:

Which is exactly the sort of thing happening already, so I don't understand the suggestion. The status messages displayed during program start are (in exactly this order):

Initialising universe...

Loading ship data...

Populating space...

Running scripts...

Loading player...

Only on the Mac version of the game (at least for now), I'm afraid...

Is there a chance of having it in Linux/PC versions too?