Oolite Bulletins

GNUstep for Windows comes as a complete package, with the *NIX-like msys and MinGW compiler buried inside it. The MinGW that comes buried in there just didn't have the C++ stuff compiled in - who knows why?

In other news I've found the bad colours are to do with how SDL loads the BMP file, which is the format that libnoise knows how to write. My sample program also rendered the colours wrongly so I converted the image to a PNG and now it looks right.

The list of things necessary to make libnoise work grows by the hour! Still, if I can get it to happen I'm sure we'll have some great looking planets after the parameters are tweaked just right.

OK, with much dark voodoo I've managed to get the C compiler and library of GCC 4.1.1 to compile under the "current" MinGW compiler (which is newer than what comes with GNUstep).

So now I've restarted the process including C++, ObjC, and ObjC++. I'll leave it go overnight.

If this works, next steps are to try and create a simple ObjC++ program that can link with libnoise.a.

If that works, I need to try and replace the C compiler and runtime in GNUstep with GCC 4.1.1 and get Oolite compiling and running in that environment.

If that doesn't work I'll have to keep calling an external program, and I'll need to learn to use libpng so that program can write PNG files.

Do it as a branch - I'm so busy with other stuff that I won't have time to look at this much for a while.

aegidian wrote:

Moving to GCC 4 would also be a good idea, it's used to build the Mac binaries already, so it's really just a case of how well it sits with SDL and GNUstep.

I build Oolite-Linux (on my workstation) with GCC 4.1 (it's part of Fedora Core). Runs fine, no problems at all.

The 'production' builds (and nightlies etc.) are all built with GCC 3.3.5, because that's what's in Debian Sarge, and Debian Sarge is what vexed3.alioth.net runs. A requirement for gcc 4.x will require some jiggery pokery because I don't want to really move my server off Debian, since Debian is a nice, slow moving target that fits well with a server.

Yes, I know requiring GCC 4.x will be a problem for debian until about 2010, so I'll make sure the textured planet code is optional.

I have GCC 4.1.1 with C, C++, ObjC, and Obj-C++ compiled and running now but still cannot get a .m file to link with a static lib made from C++ code. Quite frustrating.

Update: Simple .m file can be linked with the .o files resulting from C++. Still no joy with either getting it to work when those other files are put into a static library, or when building Oolite itself.

Update: OK, the compiler used by GNUstep has to be changed to g++ for everything, and all the functions in .c files have to be surrounded by extern "C"... but we have a link and the noise C++ code is being called and writing an image to disk! Now to try to get the image bytes back into Oolite directly.

Aside from some weird effect I don't know the cause of yet, Oolite on Windows can now generate planet textures calling libnoise in-process and without having to save them to disk:

Image removed, see better one below.

It was lucky I made chicken soup yesterday so had a ready and plentiful supply of chicken bones for the extreme voodoo this requires.

At present, all worlds look about the same in as far as they have the same colouring. I have to experiment with a few different noise generators and colour ranges to get desert worlds, water worlds, etc.

I also need to get the cloud layers going.

nice moire patterns! - that's normally due to producing two patterns whose underlying structure has a very small size difference...?

Other than that, very pretty planet. Keep up the chick stew!

It was actually as simple as getting the width and height of the texture image mixed up ;)

Here it is, fixed:



I have checked the code to do this into the textured-planets branch. I still need to make a new dev env package before anyone else will be able to compile this, and even then they'll probably need GCC 4.1, and certainly some other GCC than what comes with GNUstep.

When I have more variety in the generated textures I'll post a Win32 installer for people to play with.

It does take a second to generate the textures, so that might need some thought. The code is very bad at present - as always I just wanted some pretty pictures before I could relax and clean it up. I think the lighting is playing a bit funny with them. I might have to alter whatever it is that makes the sun's colour show up on everything.

OK, I couldn't help it. I've posted a replacement for the 1.65 oolite.exe on the Windows berlios site - it is called oolite-1.65-tp.exe.

If you want to try it, rename your existing oolite.exe file to something else, download the above, put it where oolite.exe used to be, and rename it to oolite.exe.

Warning - the planet textures are regenerated when you go to the F7 screen, so this slows your game down a bit. I'll get around to caching them soon.

Wow this looks amazing. I'll be downloading this as soon as I get home!

Well done. Any chance of being able to land on planets soon?

dajt wrote:

Anyway, I changed the generator program to create a seed based on the given Random_Seed so all the planets have different geography now, but the colours are all wrong - rust red and dark greens, etc. Not sure what's going on there - that isn't what is in the generated texture.

Maybe use the entirely non-randon Fibonnaci sequence that also makes the planet names . Anyway something that shows plenty of greens and blues when the description has 'rain forests' in it. Or is is difficult to get that much control over the colours that appear?

It would be nice to have a water level to go with each surface pattern, so that the Moray Star Boat can actually show it's usefulness. All other ships could lose energy as if they were getting too warm or something..

Already looking great, though!

Tried your new exec file. Although Oolite ran, the planets were unchanged.

Worked for me, the planets look great - am I allowed to say f***ing brilliant?

(The sun is a lot further away from the planet though, is this a bug or intentional??)

Will try again. Could the Lave and Disco OXPs cause a problem?

My fault!

I had two oolite.exe s for some reason. One in Oolite and the other in the Oolite\App. Only changed the one in Oolite!

Looks amazing in space. On my F8 screen though Lave seems not to have the rainforests althrough they are there on the Planet in real space.

Stunning addition! Will check out where the sun is in a minute!