SGI IRIX

Spooky · Post by **Spooky** » Sun Feb 12, 2006 5:22 pm

Not that anyone's gonna care but I'm currently porting Oolite to SGI's IRIX. This unfortunately requires using the GNU compilers rather than the far superior MIPSPro compilers (Hey, not everyone uses x86 and Linux

) for the objectiveC support.

I'll should be able to get a fully functional build in a day or two the way it's going at the moment but as with anything this is subject to change. I'll post a link once I'm done and I'll try and get it package by the SGI community into their software respository (http://www.nekochan.net)

aegidian · Post by **aegidian** » Sun Feb 12, 2006 6:08 pm

V. Cool!

Spooky · Post by **Spooky** » Sun Feb 12, 2006 6:45 pm

It ain't working yet

I'm waiting until I see a spinning Cobra MKIII and a 'load commander (y/n) before I pronouce it cool

Spooky · Post by **Spooky** » Mon Feb 13, 2006 3:22 pm

SUCCESS

Managed to get a successful compile... with a little bit of tweaking.

In HeadUpDisplay.m there was a conditional statement using isnan (for scanner range checks I believe). I couldn't find a library which would supply support so I fudged it a little, I'll go back and tidy this up in a sec

I'm getting some pretty weird errors when I fire up the app though.

2006-02-13 15:01:13.842 oolite[152214] OPENGL_DEBUG GL_ERROR (1280) 'invalid enumerant' in: SkyEntity after drawing <SkyEntity: 111c40a8>

This I ascribe to an unsupported GL function? (This current machine is OpenGL 1.1 complient only)

This next one I don't have a clue about or where I should even start looking? It looks like some sort of i-Tunes integration at a guess...

2006-02-13 15:01:08.023 oolite[152214] don't know how to load entity 'http://www.apple.com/DTDs/PropertyList-1.0.dtd' id '-//Apple Computer//DTD PLIST 1.0//EN'
.:3: validity error : Validation failed: no DTD found !
<plist version="1.0">

Now I have to stop playing long enough to fix some of this stuff

Thanks aegidian and the other devs for making a great game.

Thanks to Winston for hosting the source on his FTP. If I'd had to have build SYN as well that may have been the straw that broke the camels back

aegidian · Post by **aegidian** » Mon Feb 13, 2006 4:06 pm

Spooky wrote:
I'm getting some pretty weird errors when I fire up the app though.

2006-02-13 15:01:13.842 oolite[152214] OPENGL_DEBUG GL_ERROR (1280) 'invalid enumerant' in: SkyEntity after drawing <SkyEntity: 111c40a8>

This I ascribe to an unsupported GL function? (This current machine is OpenGL 1.1 complient only)

Oolite checks for GL errors after each draw method to try to catch stuff like this.

This is most likely a drawing style that's defined for OpenGL 1.2+, let me have a look... mm... possibly one or more of the vertex array pointer enumerants?

Spooky wrote:
2006-02-13 15:01:08.023 oolite[152214] don't know how to load entity 'http://www.apple.com/DTDs/PropertyList-1.0.dtd' id '-//Apple Computer//DTD PLIST 1.0//EN'
.:3: validity error : Validation failed: no DTD found !
<plist version="1.0">

That's a common problem with linux versions of Oolite when reading Apple plists. It's not harmful, but could be worked around.

Post by **winston** » Mon Feb 13, 2006 4:34 pm

You see both of those warnings on Linux, they don't seem to cause a problem (the DTD warning is just whining because it can't find the DTD - it's entirely harmless).

Spooky · Post by **Spooky** » Mon Feb 13, 2006 4:58 pm

You see both of those warnings on Linux, they don't seem to cause a problem

That's good... at least its not just me then

I'm gonna try and bang a little self contained package together which I'll hopefully have finished by tomorrow (depending on how much of bitch GNUstep is going to continue to be). I'm talking to the Nekoware guys about a proper build but there's some nasty GCC-isms in SDL_gfx and of course GNUstep that are causing a bit of a stumbling block.

Still, it's good to put this 16 processor supercomputer to some use at last

Post by **winston** » Mon Feb 13, 2006 5:01 pm

Oolite isn't (particularly) multithreaded - the main game is one single thread so unfortnately, the other 15 processors will be wasted!

Post a screen shot of it running in a window on your desktop, too.

Spooky · Post by **Spooky** » Mon Feb 13, 2006 5:30 pm

Oolite isn't (particularly) multithreaded - the main game is one single thread so unfortnately, the other 15 processors will be wasted!

Yeah, it barely uses one when running but I was talking more about the compiling

Post a screen shot of it running in a window on your desktop, too

Your wish is my command...

JensAyton · Post by **JensAyton** » Mon Feb 13, 2006 6:07 pm

Oolite under Mac OS X uses eigh threads, but most of them are related to sound.¹ My working copy also has one that logs object allocations every second, and one which theoretically loads textures asynchronously. Only the latter provides any significant performance advantage to multiple-processor systems… or rather, it would if [NSPortMessage sendBeforeDate:] didn’t consistently crash in a nonsensical way. Bah, humbug, etc.

Now, if we could move AI into a separate thread… and maybe mesh loading. And then do updates + physics separately from rendering. ;-)

¹CoreAudio’s real-time feeder thread, some other CoreAudio thread, OOSound reaper thread, OOMusic streamer, three Speech Manager threads. Also the main thread and the NSUIHeartBeat thread (I think this is used to animate progress bars).

JensAyton · Post by **JensAyton** » Mon Feb 13, 2006 6:52 pm

…and now that crash is fixed, but I can’t even start working on the next one because XCode has randomly decided to ignore my build settings and compile Oolite in such a way that I can’t step through code using the debugger. *Aargh!* *rampage*

Post by **dajt** » Mon Feb 13, 2006 7:45 pm

That really is cool seeing Oolite on yet another platform.

Well done!

Spooky · Post by **Spooky** » Mon Feb 13, 2006 8:38 pm

That really is cool seeing Oolite on yet another platform.

Well done!

Thanks, I hope it inspires other users of 'exotic' machines to have a bash. The more the merrier and all that

Now, if we could move AI into a separate thread… and maybe mesh loading. And then do updates + physics separately from rendering.

Heh heh, that works for me... massively parallel is my bread and butter

JensAyton · Post by **JensAyton** » Mon Feb 13, 2006 9:14 pm

Treating AI, physics iteration + collision, and rendering as three serial stages in a pipeline, then doing them in separate threads is the easiest way to make use of multiple processors in a typical game. The AI could obviously be parallelised further, as could the physics if you use a space partitioning scheme.

Unfortunately, going from “easiest way” to “easy” isn’t all that, er, easy in the context of an existing engine not designed that way.

Post by **winston** » Tue Feb 14, 2006 10:00 am

Spooky: that is way cool. How many FPS are you getting (press Shift-F for the framerate display), and what's the spec of the machine?