Ever since the addition of the (most excellent) shader update Oolite has required OpenGL 1.4 or greater for the GLSL support. The last version of OpenGL supported on any MIPS based SGI hardware was 1.3 (with a few extra extensions) and official support has now ended for this hardware.

Would there be any interest in a graphics light version of Oolite for people who's boxes aren't quite up to the task?

Oolite under OS X still works with OpenGL 1.1 at runtime. Most dependencies on newer versions should be isolated to OOOpenGLExtensionManager.m/h, and go away if you define NO_SHADERS. I’d like the trunk to be buildable with 1.1 if NO_SHADERS is defined, so please report any complications and/or ask for help as necessary.

So far the NO_SHADERS define and IRIX are going nowhere fast. I apologise for the verbose nature of this post but I think it's best that I show you everything that I've done so you can point out my obvious mistake

I'm using GNUStep from the Startup 0.20.0, I'm using the SGI development libraries and foundation 1.3, GNU Make 3.81 and I'm compiling with GCC 3.4.6.

Our first stumbling block is the GNUMakefile. I have to add -std=c99 to the CFLAGS and of course -DNO_SHADERS to both CFLAGS and OBJCFLAGS. Then I tweaked the GNUMake.postamble to sort the object file locations. Finally we're ready to

Code:

make debug=no.

And we hit a problem almost immediately, an undeclared isShadered in PlanetEntity.m

Unfortunately when I try to run it through gdb it only identifies an unrecognised signal and seems to stuff itself into a perpetual loop.

Any ideas?

Just as a passing shot, although NO_SHADERS will go partially to solving the problem I'm of the opinion that I also really need to produce an OXP with massively trimmed textures, a mechanism for disabling the nebula clouds (or examine their rendering technique). I also need to have serious look at the planet/atmosphere texturing.

Ok, looks like I'm getting somewhere. It looks like the NSInternalInconsistencyException error is being caused by a crappy libobjc runtime and I think the reason I've never noticed it on previous IRIX builds (up to 1.65) was the lack of NSThread use. Looks like I'm gonna have to build a new version of GCC and rebuild GNUstep.

Ahruman,
I've made some cpu detection routines for IRIX and FreeBSD in OOCPUInfo.m which I'll fire up once I get this runtime problem sorted. Also I missed a modification in OOpenGL.h in my previous post.

Just my $0.02: shaders are cool and all, but most of the variety needed in most cases comes from simple texturing. Adding Sung's textures for example really gives a massive step forward in visual richness at fairly small cost. I find specular highlights, etc. distracting.

I think the absolutely most important thing is to peg the framerate at 60+fps at all times, that should be doable on almost all systems even with fairly rich texture mapping.

Probably the best thing is just to make sure the switches for low/medium/high/off detail stay in the game so players can make the trade-off themselves.

Oolite 1.71 has better graphical performance than 1.65 on just about any system with any sort of hardware acceleration, and does not have higher system requirements. The settings are in the game, and no-one’s planning to take them away.

The issue in this thread is related to building for operating systems which provide old versions of OpenGL, where supporting shaders at all is not possible. Maintaining that ability has always been my goal, and the obstacles to it (now overcome) were very small.

I completely concur with Ahruman, anything that I'm doing here is purely for machines that are practically antiques. Obviously I want to keep any work I do in line with the trunk so that people with machines that aren't so 'dusty' can choose to leverage the changes and improve their gameplay.

60fps

On my test machine (a 1995 vintage Indigo2 with a 195Mhz processor 768M of RAM and a graphics system with 1mb of texture ram) I'm lucky if I push 20 in v1.65