The collected works of SkyBound

I am pleased to announce the release of FlightGear v0.9.4.
It is available for free download from:

http://www.flightgear.org

The IRIX binary is available at:

http://www.a1.nl/~ehofman/fgfs/

FlightGear is a free, open-source, multi-platform flight simulator.
The source code is licensed under the GPL.

Precompiled packaged versions are available for most platforms including Windows,
Linux, Sgi, Solaris, and Mac OS X.

The IRIX version now lives in the standard conformal /opt/FlightGear-0.9.4 directory
and has optimized versions of the main program for mips3/R4k and for mips4/R10k.

Here are a few of the highlights from this release:

- Ability to fetch weather conditions in real-time from the NOAA web site.
- Working VASI/PAPI lights.
- Ability to fly under bridges, taxi into hangers, etc.
- Added a tool to facilitate installing additional scenery chunks.
- Many updated textures and models.
- The San Francisco area has been vastly improved.
- Several new aircraft were added (Comper Swift, Hawker Hunter, and T37 Tweet)
and most of the existing aircraft have been improved in various ways.
- A built in scripting language.
- Updated aircraft AI and ATC modules.
- Complete overhaul of the autopilot system.


For more information on the FlightGear project, please visit our web
page at:

http://www.flightgear.org

You can view a summary of the new features, changes, and bug fixes for
this release here:

http://www.flightgear.org/version.html

Erik[/list]

GIJoe wrote: just wondering if anyone has real-world numbers on flightgear's performance.
i've just browsed through the info that was linked from the official page and from what was written there, even a relatively "newish" octane2 v6 didn't manage to score more than 10 fps in their benchmark. let alone onyx2 or systems comparable to what i have at home (max impact R10k) which seem to score at astonishing 2 - 3 fps.

This information is based on the results of a survey I held a few months back. There wasn't much response though. But you have to keep in mind that these numbers are for the default startup locaton only. The rates can be much higher when starting in other regions.

I have to admit the numbers aren't spectacular, but this is what sgi hardware can give I guess. My hopes are that the latest ATI based graphics adapters give much better numbers (comparable to PC based graphics adapters).

There are some trick to speed FlightGear up a bit, one of them is renaming the data/Textures.high directory to data/Textures.unused. Other tricks are described on the performance page.

Erik

Mare wrote: Very cool find!

Just had a good play with them, its a shame they dont have the other games from the bottom, would be cool to have a simple pool/snooker game for my Octane.

How about this:
http://foobillard.sunsite.dk/

Here is another list of Freeware (and non Freeware) games that might be interesting:
http://happypenguin.org/forums/viewforum.php?f=17

Erik

I had a simillar problem with my new CD-ROM drive. I just used a cable clip (without nail) that fits nicely over the original mechanism, no glue was needed.

Erik

We are pleased to announce the release of FlightGear v0.9.8.

FlightGear is a free, open-source, multi-platform flight simulator.
It is available for free download from:

http://www.flightgear.org

FlightGear features:

* Sophisticated and highly tunable flight dynamics engines.
* Aircraft modeling system that supports fully interactive, fully 3d cockpits, sophisticated internal and external animations can be tied to just about any FlightGear variable.
* SRTM based world scenery available for free download.
* Over 20,000 airports modeled around the world.
* Seamless continuous oblate ellipsoid world model.
* Accurate day/night and lighting effects synced to real time.
* Correct sun, moon, star, and planet placement (and correct phase of the moon.)
* Ability to automatically sync with real weather conditions via the internet.
* Flexible, adaptable, interfaceable, open architecture.
* Complete source code licensed under the GPL.
* Ported to many platforms including Windows, Max OS X, Linux, FreeBSD, Solaris, and sgi.

A summary of the new features, updates, and changes for this release
can be viewed here:

http://www.flightgear.org/version.html

Erik

nekonoko wrote: I've posted this on the news page. Thanks!

Great, thanks Nekonoko!

Erik

squeen wrote: We just got the BG Electronics flybox up and running for our sim. I'll have to see if I can get it to work with flightgear on the Onyx350!

Joystick support for IRIX is very limited in FlightGear (well .. actually there is no joystick support), but:

There is a js_server program included in the FlightGear/utils/js_server (sourcecode) directory. The client for this server is part of FlightGear, so you could modify the joystick server to accept the values from this device and drive FlightGear using this (network) protocol.

Erik

msunix wrote: Hi!

Has anyone here tried to run FlightGear on a Onyx2?
I have no success here. After i start fgfs (with fgrun or simply by ./fgfs) it just prints 'Abort' to the console and quits. On my Octane2 it runs nicely with the same installation and settings. Is there something i'm doing wrong or does it simply not run on Onyx2? I tried 0.9.8 and 0.9.6, both with the same results.

Unfortunately I have only access to an O2. There is another developer running it on an Octane.

Could you sent the last few (say 20) lines of output when running fgfs --log-level=info

Erik

msunix wrote: Hi Erik!

Thanks for doing a good job in porting FlightGear to Irix!

You're welcome.

msunix wrote: Unfortunately i don't get much useful information about the crash, i fear. As i mentioned, all i see is the following:

Code: Select all

michael@onyx2:/opt/FlightGear/bin > ./fgfs --log-level=info
Abort
michael@onyx2:/opt/FlightGear/bin >

That's all! Do you have any idea what it could be?

Not really, I searched all through the code to see if it is generated by either FlightGear or one of it's support libraries but none of them print "Abort" and end the program.

Maybe there is a hint in the SYSLOG?

Erik

gandalf wrote: on my Indy r5k with XZ I get a kernel panic when I launch fgrun... The screen gets all black and then crash

-R

I really don't think FlightGear can run on any Indy. Even my O2 is worse than I would have hoped for. I'm sorry.

At this page you can see what framerate you could expect for your hardware:
http://www.a1.nl/~ehofman/fgfs/comparison.html

Erik

Mgras wrote:

SkyBound wrote: Errrm, I might be the mentioned developer running FlightGear on an Octane R12k and R10k
(back to R10k after the R12k CPU died ....).
I've never seen such an 'Abort' but I guess it is a CPU incompatibility. The FlightGear binary
is built for R10k and it is known to work on an R5k2 of the mentioned O2 as well but it
probably doesn't run on those CPU's that are built into the Onyx2 !?

Actually I build tow binaries, one for R4k and one for R10k which are clearly marked that way. So I don't expect that would be the problem. It could be worth the effort to try the other binaries though.

Erik

AX wrote: Has anybody loaded Flightgear as described on there site and still received an error like this, "unable to map soname libsgprops.so". Am I missing am library or do I need to point flightgear to this?

It looks like an older binary of FlightGear is being found. I had one release in the past that used shared libraries but it's very hard to maintain so I switched back to static libraries.

You might want to to run 'which fgfs'
The binary should point to '/opt/FlightGear/bin/fgfs' then.

Erik

joerg wrote: I have create a neko_flightgear but my opionon is that it is not worth for release the package because the very poor performance. Or anyone know why my FUEL only runs the simulation with only 5fps?

FlightGear (like many OpenGL programs) uses features that the card supports. But this doesn't necessarily mean they are hardware accelerated. You could try to add one (or more) of the following options to your ~/.fgfsrc file:

http://www.a1.nl/~ehofman/fgfs/downloads/.fgfsrc

In your case I suspect one of the following:

--fog-fastest
--disable-specular-highlight
--disable-clouds3d

Erik

dexter1 wrote: BTW, *bows* to you Ben. I am honored to see a legendary MegaMix DMC DJ entering our ranks! Must have been '83-'84 since i first heard of you via the Soul-Show i believe. I blame my older brother for all that music influence:)

Yeah, can you believe that.
Makes me remind the old days of the Friday evening show on Veronica radio!

At least I 'm able to give him back some, a Flight Simulator for his rendering hardware:
http://www.ehofman.com/fgfs


Erik

Ben_Liebrand wrote: As for Friday Nights on Veronica.
They have now moved to the Saturdays:
http://www.liebrand.nl/inthemix/index.html

Good to know, I've lost sight a bit on Veronica Radio.

Erik

Odd, we're using the RenderTexture code that is also extensivelly tested outside the scope of FlightGear.

The easierst eay to get rid of the problem is to run "fgfs --disable-clouds3d".
It may be that it requires more texture RAM than available.

Erik

FlightGear contains older 2d-clouds code (just a textured layer of quads) and 3d clouds that uses pbuffers and imposters et all.

--disable-clouds only disables 2d clouds
--disable-clouds3d disables the 3d clouds

Erik

At the risk of saying complete nonsense, there is a glitch between the MIPSpro compiler suite and other compilers in that it uses reverse order for macros that work twice on the same variable.

To check against this one could change the macro into a function and see whether that fixes the problem. For example (this is a Nasal/FlightGear example), changing:

#define PUSH(r) do { \
if(ctx->opTop >= MAX_STACK_DEPTH) ERR(ctx, "stack overflow"); \
ctx->opStack[ctx->opTop++] = r; \
} while(0);

into
# define PUSH(r) _PUSH((ctx), (r))
void _PUSH(struct Context* ctx, naRef r) {
if(ctx->opTop >= MAX_STACK_DEPTH) ERR(ctx, "stack overflow");
ctx->opStack[ctx->opTop++] = r;
}

causes the following code to start working:

PUSH(ctx->opStack[ctx->opTop-1]);

which ended up like:
ctx->opStack[ctx->opTop++] = ctx->opStack[ctx->opTop-1];

As you can see the ctx->opTop variable was accessed twice in the same macro. BTW. This macro is now rewritten like this:

// Note that opTop is incremented separately, to avoid situations
// where the "r" expression also references opTop. The SGI compiler
// is known to have issues with such code.
#define PUSH(r) do { \
if(ctx->opTop >= MAX_STACK_DEPTH) ERR(ctx, "stack overflow"); \
ctx->opStack[ctx->opTop] = r; \
ctx->opTop++; \
} while(0)

Erik

Line 71 of jsarena.c looks fishy to me in this regard:
JS_ARENA_ALIGN(pool, &pool->first + 1);

You might want to convert the JS_ARENA_ALIGN macro into a function to see if this solves the problem.

Erik

I think this would be the correct function for that:

jsuword JS_ARENA_ALIGN(JSArenaPool *pool, JSArena *n)
{
return (((jsuword)(n) + (pool)->mask) & ~(pool)->mask);
}

It would be nice to see the difference of the JS_ARENA_ALIGN macro between the two versions also.

The easiest way to reduce the texture size is to rename Textures.high in the root of the base package. Only the low resolution versions of the texture will be used then.

Erik

I think I have a dual core R10k/195Mhz board laying around.
Could you tell me how I can be sure, the numbers on the board (30-1235-001 REV A) does not return anything useful.

Update: Oh it turns out to be 180Mhz

Erik

Oh O2000, not O200. Sorry for the fuzz.

Erik