Page 1 of 3

SGI IRIX

Posted: Sun Feb 12, 2006 5:22 pm
by Spooky
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 :wink:) 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)

Posted: Sun Feb 12, 2006 6:08 pm
by aegidian
V. Cool! 8)

Posted: Sun Feb 12, 2006 6:45 pm
by Spooky
It ain't working yet :wink:

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

Posted: Mon Feb 13, 2006 3:22 pm
by Spooky
:twisted: SUCCESS :twisted:

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 :oops:

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 :wink:

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 :wink:

Posted: Mon Feb 13, 2006 4:06 pm
by aegidian
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.

Posted: Mon Feb 13, 2006 4:34 pm
by winston
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).

Posted: Mon Feb 13, 2006 4:58 pm
by Spooky
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 :wink:

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 :D

Posted: Mon Feb 13, 2006 5:01 pm
by winston
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.

Posted: Mon Feb 13, 2006 5:30 pm
by Spooky
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 :wink:
Post a screen shot of it running in a window on your desktop, too
Your wish is my command...
Image

Posted: Mon Feb 13, 2006 6:07 pm
by JensAyton
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).

Posted: Mon Feb 13, 2006 6:52 pm
by JensAyton
…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*

Posted: Mon Feb 13, 2006 7:45 pm
by dajt
That really is cool seeing Oolite on yet another platform.

Well done!

Posted: Mon Feb 13, 2006 8:38 pm
by Spooky
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 :wink:
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 :)

Posted: Mon Feb 13, 2006 9:14 pm
by JensAyton
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.

Posted: Tue Feb 14, 2006 10:00 am
by winston
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?