Progress
Moderators: winston, another_commander
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
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.
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.
E-mail: [email protected]
- Star Gazer
- ---- E L I T E ----
- Posts: 633
- Joined: Sat Aug 14, 2004 4:55 pm
- Location: North Norfolk, UK, (Average Agricultural, Feudal States,Tech Level 8)
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!
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!
Very funny, Scotty, now beam down my clothes...
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
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.
Code: Select all
foo = "banana!";
bar = 42;
Code: Select all
{
foo = "banana!";
bar = 42;
}
I’ve removed the sentence on the wiki page about property lists stating the first type of syntax is permitted.
E-mail: [email protected]
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
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).
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).
E-mail: [email protected]
- Arexack_Heretic
- Dangerous Subversive Element
- Posts: 1876
- Joined: Tue Jun 07, 2005 7:32 pm
- Location: [%H] = Earth surface, Lattitude 52°10'58.19"N, longtitude 4°30'0.25"E.
- Contact:
Sounds frightening. let's teleport the player.entity insteadIt 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).
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.>
Last edited by Arexack_Heretic on Fri Sep 28, 2007 9:59 pm, edited 1 time in total.
Riding the Rocket!
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
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.
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.
E-mail: [email protected]
- Arexack_Heretic
- Dangerous Subversive Element
- Posts: 1876
- Joined: Tue Jun 07, 2005 7:32 pm
- Location: [%H] = Earth surface, Lattitude 52°10'58.19"N, longtitude 4°30'0.25"E.
- Contact:
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
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.
E-mail: [email protected]
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
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…
E-mail: [email protected]
- Arexack_Heretic
- Dangerous Subversive Element
- Posts: 1876
- Joined: Tue Jun 07, 2005 7:32 pm
- Location: [%H] = Earth surface, Lattitude 52°10'58.19"N, longtitude 4°30'0.25"E.
- Contact:
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.
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.
Riding the Rocket!
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
Did you read the list? :-)Arexack_Heretic wrote:trumbles_number would be cool...
It isn’t on my to-do 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
E-mail: [email protected]
- Arexack_Heretic
- Dangerous Subversive Element
- Posts: 1876
- Joined: Tue Jun 07, 2005 7:32 pm
- Location: [%H] = Earth surface, Lattitude 52°10'58.19"N, longtitude 4°30'0.25"E.
- Contact:
- Griff
- Oolite 2 Art Director
- Posts: 2481
- Joined: Fri Jul 14, 2006 12:29 pm
- Location: Probably hugging his Air Fryer
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
Edit: sorry, just realised you probably query this state in the shader code
Last edited by Griff on Fri Jun 08, 2007 10:39 am, edited 1 time in total.
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
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.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?
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.
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.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]
E-mail: [email protected]
- Arexack_Heretic
- Dangerous Subversive Element
- Posts: 1876
- Joined: Tue Jun 07, 2005 7:32 pm
- Location: [%H] = Earth surface, Lattitude 52°10'58.19"N, longtitude 4°30'0.25"E.
- Contact: