Oolite Bulletins

The main reason for the improvement is the removal of a Mac-specific optimization that wasn’t actually optimizing.

That was Oolite with few OXPs after launching from Lave station on a G5 iMac with a GeForce FX 5200.

The scale of the improvement is mostly because Oolite (on Macs) runs on a 100 Hz timer, with missed frames simply being skipped; this means each frame effectively lasts for some multiple of 10 ms. In the optimized release build, I’m now seeing a nominal frame rate of 100 ms, where before I’d be seeing 33 or 50 most of the time.

Part of this improvement is probably down to sundry improvements over the last few weeks, without me really noticing.

Thanks Ahruman - I just wanted a perspective(sic) on what you were seeing. It sounds like most Mac peoples will see a significant improvement with these changes - very encouraging.

Once again, many thanks for helping to pick up the traces and move Oolite on, I'm sure Giles will be pleased to know it is in good hands!

Over the last few revisions, we’ve had several problems with OpenStep-format property lists (i.e., the ones that aren’t XML). It appears the reason is this: if the root element in a property list is a dictionary, OS X does not require it to be surrounded with braces, but GNUstep does. In other words, the following works under OS X: …but GNUstep wants: The latter format works under OS X, too. This might possibly be useful to know if you’ve had problems with plist portability in an OXP.

I’ve removed the sentence on the wiki page about property lists stating the first type of syntax is permitted.

So, what’s happening in the world of dauntless Lazy Programmers?

Well, I’m moving towards a release, hopefully this week. This one will have more glitches than 1.68, and I need you to help track them down for me. It also won’t have much in the way of new scripting support (except JavaScript Vector and Quaternion objects, which you can’t do much with. Oh, except teleport the player).

It will, however, have a powerful way to bind shader properties to entity attributes. This means that a shader can, for instance, use the levels of each shield, or the compass mode, or the fuel leak rate, without specific support being added to Oolite for each attribute. Oh, and the shader model has been generalized to allow various other material attributes to be fiddled with, as discussed to apparent bafflement elsewhere.

It will also be faster and smoother (unless complex shaders are in effect), use slightly less memory, and allow somewhat bigger models. All textures will look a bit better, too.

Edit: I forgot to say, the primary hold-up for 1.69 is getting it working on Windows. One of the problems there is a bug in the sky rendering… and since I planned to rewrite the sky code anyway, that will be in 1.69 (although the final texture set won’t be selected yet, so keep ’em coming).

It also won’t have much in the way of new scripting support (except JavaScript Vector and Quaternion objects, which you can’t do much with. Oh, except teleport the player).

Sounds frightening. let's teleport the player.entity instead

What do you mean by this?
Java[script] has no support, vectors and quaternions are the only new scripting stuff, but they do not function as they should?

And what is this stuff about teleporting people? I won't stand for it. I'm telling Giles! :p
<sorry lack of bloodsugarlevels is affecting my judgement...nice stars though...shouldnt have done that handstand in the hallway probably...judgement again. Let's hope this 4hour old coffee will help.>

To answer your question:
1) the game does not distinguish between the player and the player entity/ship.
2) Java is not supported, and no-one has ever suggested it will be.
3) Vectors and quaternions in JavaScript work fine, but there is limited use for them at the moment… except changing the player entity’s position.

2-Gack! By 'Java' I mean Javascript.
3-Some persons will be vewy happy about that possibility, there was talk about freelancer-like teleport-rings and stargate-like stuff.
1-You are being very serious today. :/ I was refering to the player.person.

Teleportation only works within a system, though. Also, you can’t get the position of anything other than the player (yet). Obviously this is planned for the next “full” release.

I’ve added documentation for the new properties available to shaders using uniform bindings. This increases the number of ship properties a shader can query from six in 1.68 to 56 (in the case of the player) in 1.69, not counting the legacy scripting engine methods. Admittedly the usefulness varies somewhat…

Cool! 56 possibilities for mischief!

trumbles_number would be cool...

That reminds me.
Is there a chance that the number (or tonnage) of trumbles will be displayed in the cargo, equipment or commander manifest in future releases?

The "and one little trumble" I heard about sounds so cute.

Arexack_Heretic wrote:

trumbles_number would be cool...

Did you read the list? :-)

Arexack_Heretic wrote:

That reminds me.
Is there a chance that the number (or tonnage) of trumbles will be displayed in the cargo, equipment or commander manifest in future releases?

The "and one little trumble" I heard about sounds so cute. :D

It isn’t on my to-do list…

offcourse I haven't I'm lazy.
Ok have now. Wheee!

It isn’t on my to-do list…

Well... it should be on top by Darntootin!

this sounds really exciting! i've been picking apart some of the rendermonkey example shaders and there's one for evil eyes (!) that has a cool corona type effect that needs 'viewing angle' information to work properly. Looking through the list it seems it's possible to get this info from oolite to the shader using the position & orientation bindings?

can we swap between fragment shaders, eg the 'isCloaked' = 0 or 1 swapping between different fragment shaders used by a ship?

Edit: sorry, just realised you probably query this state in the shader code

Griff wrote:

this sounds really exciting! i've been picking apart some of the rendermonkey example shaders and there's one for evil eyes (!) that has a cool corona type effect that needs 'viewing angle' information to work properly. Looking through the list it seems it's possible to get this info from oolite to the shader using the position & orientation bindings?

Basic viewing angle information consists of the dot product of the normal and the eye vector, similiar to the dot product between the eye vector and the reflection vector used in specular lighting.

More complex directional effects, such as tangent-space normal mapping, require a local co-ordinate system based on the surface normal, surface tangent and surface binormal. This information is currently not provided by Oolite.

Griff wrote:

can we swap between fragment shaders, eg the 'isCloaked' = 0 or 1 swapping between different fragment shaders used by a ship?

Edit: sorry, just realised you probably query this state in the shader code[/s][/b]

As per the wiki page, cloaking state can be queried, but the behaviour of only drawing the cloaked ship in 10% of frames is hard-coded.

Besides accessing their values for shader-purposes,

all these states and conditions of the entity-object can be changed by JSmethods? (I'll not mention legacy plist)