Oolite Bulletins

After following the process to get libnoise to build that's outlined in your readme, (I grabbed the sources from the libnoise website, and their Makefile is hosed beyond belief on my system.) I seem to be getting somewhere. I got Oolite linking properly, and it builds.

However, it Segfaults on startup as it initiallizes the planet rendering (it prints colors for the land and sea on the console) In the directory with ptg.h/cpp, I'm also noticing an Obj-C source file prender.m, Do I need to get that in the Makefile somewhere for this to work properly?

EDIT:
Bam! Got it to work. I ran an strace on the app as it loaded, found that it was getting permission denied when opening 'texture.raw'. So long as I run the game from a working directory where I have write permissions, it works. My suggestion would be to force 'texture.raw' to be written in a location within a user's home directory... Perhaps alongside the Oolite.cache file in the ~/GNUstep directory? That would aleviate that issue right quick.

EDIT2:
I'm tossing a copy of my new oolite binary on my personal server. http://www.chaotique.com:8008/~magamo/oolite.bz2

For anyone running linux (I tested it, it works under every installation I threw it at) you merely bunzip2 it, and copy the binary over the old one in your oolite.app directory (check the permissions) and when you next run the game, presto, it should work.

Well done :)

I've just updated the branch by adding a modified set of libnoise source code to the deps windows staticlibs libnoise directory, with a makefile to make libnoise.a and a shell script to invoke this and copy everything into include and lib directories as required. Someone who knows make better than I want to can probably do all this and more with the makefile ;) See the readme.txt file.

I've modified the libnoise source to remove all warnings and it compiles cleanly with -Wall. I've also hacked the noiseutils source #include statements because it is being compiled in place with the rest of libnoise - no functional changes though. This isn't great and I'll fix it later. But for now it works.

The libnoise warnings were mostly trivial saying some member variables were initialised by the constructor in a different order than they were declared. I can't see this mattering. The others were to do with base classes not having virtual destructors meaning subclass destructors wouldn't be called. There were no destructors in the subclasses so this wasn't a real problem either.

Of course this is someone who can't really program in C++ talking so I could be wrong!

And that texture.raw thing. That should never have been there and is gone now. That file was for debugging when I was trying to find why the cloud textures didn't get the right alpha values.

In the Makefile you are refering to, at least in linux, it wouldn't work as the VPATH variable was set up wrong; the seperator between directories should be a colon, not a semicolon.

I forgot to mention that, sorry. You have to use semi-colon on Windows because the colon is a reserved character for drive paths.

We (the devs) decided the textured planet discussion should head over to the PC forum to avoid confusion for people who might start looking for this stuff on other platforms.

I've started a new topic over there for discussion of this experiment.

dajt wrote:

And that texture.raw thing. That should never have been there and is gone now. That file was for debugging when I was trying to find why the cloud textures didn't get the right alpha values.

How about the bit where it dumps "alpha=foo" several hundred thousand times each time it generates a planet? Is this needed?

Oh, and I’m currently just getting bright red planets. With, apparently, an atmosphere of stars. Is this intended?

:-)

Note that I've tweaked my own experiments, which may be of interest. They're now an option activated by hitting 't' from a paused game in the current $HEAD (which is where i hide all my experimental junk).

Screenshots here:- http://pics.livejournal.com/aegidian/gallery/0000agt1

aegidian wrote:

Screenshots here:- http://pics.livejournal.com/aegidian/gallery/0000agt1

Neat! Can we *please* have pretty planets in an upcoming version? I'd rather have pretty planets than more variety in weapons...

Best wishes,
Oscar

I like the look of that bulk hauler too, when's that going to be available to us grateful mortals!

aegidian wrote:

Note that I've tweaked my own experiments, which may be of interest. They're now an option activated by hitting 't' from a paused game in the current $HEAD (which is where i hide all my experimental junk).

Screenshots here:- http://pics.livejournal.com/aegidian/gallery/0000agt1

Ah, looking very good! Good to have continents etc. a bit visible under the cloud cover!

So, is this going to be implemented in the next mainstream release of Oolite, so that we can all enjoy these lovely planets on other platforms?

Star Gazer wrote:

So, is this going to be implemented in the next mainstream release of Oolite, so that we can all enjoy these lovely planets on other platforms?

Yes and No. libnoise is very pretty - but I'm dissatisfied with it in terms of integration with existing code.

I'm working on a refined way of implementing procedurally textured planets that doesn't use an extra library, hooks nicely into planetinfo.plist (to preserve the 'system oxps'), and also ties in the use of shaders (to properly map shadows from mountains etc.)

Roclidkic wrote:

It is really??

Sorry, is what really what?
If you mean libnoise, then I think it is, which also seems to be the general consensus.