Development Notes

This page contains notes in developing FlightGear OS X and some snapshots while I'm flying, or I should say it's my diary. feel free to leave a comment.

DevNote Dec-11-2009?

ImageIO doesn't properly handle PNG transparency (part 2)

You can read the first part here.


After some hours of investigation, I found the cause of another half of my problem (PNG with transparency got black edges). The alpha channel of an RGBA image is completely ignored. The cause apparently is that GL_UNSIGNED_INT_8_8_8_8_REV is specified for the data type in calling osg_image::setImage() for 32 bpp images, but this somehow makes OpenGL (or osg::Image) ignore the alpha channel. I tried so many combinations of data_type, pixel_format, and internal_format for avoiding this but none worked well. After tons of trial, I tried GL_UNSIGNED_BYTE for data_type, and this worked like a charm!!

So I tried this workaround on ppc Mac (using rosetta). I got weird colors on the first try so I made some tweaks like changing data_type, pixel_format, or internal_format, but none gave me a good result. After many failures, I decided to swap the endian of each pixel for ppc before un-multiplying the color values.... And that worked great!! Though I think there is some smarter ways than this, it is enough at this moment at least for me.

Now it's time to check if these workarounds work on different image formats. I tried osgviewer with this image in several different formats (like tiff, tga, psd, and gif converted by Gimp) on both intel and ppc (using rosetta). The results are shown in the table below.

formatpixel formatsizeresult
GIFINDEXED Grayscale/dithered256x256OK
TGAGrayscale+A256x256N/A(image converted by Gimp seems corrupted)
GIFINDEXED Grayscale/dithered300x300OK
TGAGrayscale+A300x300N/A(image converted by Gimp seems corrupted)

It seems working on almost all supported formats. I also tried these images with the original imageio plugin for comparison, and all of images had black edges. This means that this problem is not only on the PNG but on all supported images....

Anyways, I'm very happy that I can use PNG textures with no problem!

By the way, I found that the osgdb_bmp plugin also has the same problem (sigh....). I will look at the code if I have time.

You can get the patch for OpenSceneGraph/src/osgPlugins/imageio/ReaderWriterImageio.cpp.

ImageIO doesn't properly handle PNG transparency?


As I mentioned in DevNote Nov-26-2009, OSG's imageio plugin doesn't properly draw PNG images with alpha channel. I posted this issue to the OSG list and got an interesting information that SDL has the same issue and they already have a workaround for it. According to the bug info, ImageIO premultiplies the color values with alpha (R, G, B *= A / 255) and this is the cause of the darker edges. Thus the workaround code un-multiplies the color values to get an expected result.

So I got SDL source and borrowed the workaround code from IMG_ImageIO.c. The code reverts the premultiplied RGB values for avoiding unexpected darken edge:

if ((bitmap_info & kCGBitmapAlphaInfoMask) == kCGImageAlphaPremultipliedFirst) {
  int i, j;
  Uint8 *p = (Uint8 *)surface->pixels;
  for (i = surface->h * surface->pitch/4; i--; ) {
      Uint8 A = p[3];
      if (A) {
        for (j = 0; j < 3; ++j) {
          p[j] = (p[j] * 255) / A;
//(snip -- Big Endian)
#endif /* ENDIAN */
     p += 4;

I embedded this code to OSG's imageio plugin (src/osgPlugins/imageio/ReaderWriter.cpp) and tested it. What I got is the brighter cloud edges, Yay! But, but the tail lights doesn't look good. these still have dark (black) edges (middle picture). Ok, so my problem is half solved by SDL's workaround. I'll investigate the rest of the problem. (read part 2).

png-imageio-no-patch.png SIZE:800x600(?KB) png-imageio-SDL-patch.png SIZE:800x600(?KB) png-osgdb_png.png SIZE:800x600(?KB)

ImageIO with no patch (left), imageIO with SDL patch (center), with osgdb_png instead of imageIO (right ; expected).

You can click an image to enlarge.

3D Cloud Shaders


Tim announced a cool 3D clouds shader, so I updated SG/FG/data and tried this shader right away. But what I got was:

3dclouds-effect-enabled.png SIZE:800x600(?KB)
Oops, rainbow-ish crystals covers everywhere

Though this looks fancy and very dramatic, I got big fps drops (less than 1.0) and I couldn't control anything. This phenomenon went away when I disabled the material shaders. Thus I assume this is the shader problem (or C++ side of shaders). One thing I can think of is a weird alpha value for each pixel. So I tried disabling the modification on alpha values in shaders (default.vert and model-default.vert) and this works like a charm!

There is another issue (3D clouds go colored rectangles) but Tim said it is expected. so that will be fixed soon, I believe.

You can get the diff for the shaders here.

Clouds and lights got back to normal


Since some time around 1.9.1 release, I haven't seen 2D clouds. 3D clouds were there but the edges are too dark and these look much more like smokes of anti-air cannons...

And things went worse. Since some time in the last month, I haven't seen 3D clouds... 

png-alpha-grayscale-noclouds.png SIZE:800x600(?KB)
No 2D/3D clouds comes up (with FG/SG/OSG as of 2009/11/24)

What's going on here? I've asked some FG developers (Linux users) but they said they could see 2D/3D clouds properly. 

I thought that 2D clouds didn't show up because of my graphic chip issue. However, I found the following error messages in fgfs log:

<Error>: CGBitmapContextCreate: unsupported parameter combination: 
           8 integer bits/component; 16 bits/pixel; 
           1-component colorspace; kCGImageAlphaLast; 512 bytes/row.
<Error>: CGContextDrawImage: invalid context

I've seen these since some time ago... Maybe some time around 2D clouds went disappear. "This might be it," I thought, so I googled the error message and found that this is caused since you're designating a wrong combination of colorspace, pixel format, bpp, etc for an image. The function CGLBitmapContextCreate is called only from ReaderWriterImageIO.cpp (imageio plugin for Mac OS X), so I added a debug print for dumping the filenames that generate the errors. 

All the files with errors are cloud texture png images like cl_cumulus.png, which are 16-bit grayscale images with alpha channel. I thought "If this is the case, I can fix it." I made a simple workaround patch for creating a 32bit RGBA context instead of 8-bit grayscale for such grayscale images, hoping that CGLBitmapContextCreate automatially converts the pixel format from Grayscale-Alpha to RGBA. And it worked! Both 2D and 3D clouds came up and the errors were gone.

png-alpha-grayscale-imageio.png SIZE:800x600(?KB)
3D clouds came up, but with darker edges...

Okay, one problem solved. Another problem is the "dark edges." I have a similar problem that transparency in png files aren't drawn properly, so it might has something to do with the dark edged clouds (c172p's tail light has wide black edge. You can see the c172p's tail light around the rudder in the image above is rather black than red).

To make sure this is a png problem, I converted one 16-bit grayscale cloud texture (cl_cumulus.png) into rgba (SGI' RGBA file) and then edited cloudlayers.xml to use the rgba file instead of png. Running FG with the rgba texture gave me a result that I expected. The cloud edges went much brighter. Therefore, I edited osgDB/Registry.cpp for not letting imageio handle png images. I also built for handling png files instead of imageio (of course I reverted cloudlayers.xml). I launched FG again with, and the result was perfect. I finally got brigher clouds and the red tail light without weird black edge.

png-alpha-grayscale-osgdb_png.png SIZE:800x600(?KB)
3D clouds and the tail light with my patch.  


You can get the patch that I made for this experiment from: here.

To build (or .dylib), you need to modify CMakefile and/or OpenSceneGraph.xcodeproj file yourself. You also need /usr/X11/lib/libpng.dylib and /usr/X11/include/libpng/png.h to build osgdb_png plugin.

Further note on Dec-03-2009

I made further more investigations (DevNote Dec-02-2009, and DevNote Dec-03-2009) on this issue, and I made the workaround patch for

You can get the patch for OpenSceneGraph/src/osgPlugins/imageio/ReaderWriterImageio.cpp.

FYI, This patch is applied to osg/svn on Dec-05-2009. If you use osg earlier than 2.9.6 (or 2.9.7?) and have this issue, you need this patch.

Dangerous code, indeed.


Oops, FlightGear won't start after applying the Mac OS X 10.5.2 update. I got some reports from users complaining about FlightGear (fgfs) quits unexpectedly on launch and falls back to GUI.

With a quick trace, the problem happens when "Download Scenery on the fly" option is enabled. So I disabled the option and tried it again to find FlightGear launched with no problems. A log file sent from a user shows that SimGear fails to connect to a udp socket. Why such thing happens? Did Apple change anything about socket implementation? To check this, I wrote a very simple ruby script that connects to terrasync via udp ---- and it worked as expected.

So, the cause IS in FlightGear side, not in Apple side. Tracing back the SimGear code gives me a real cause of this issue:

 * Socket address, internet style.
class netAddress
  /* DANGER!!!  This MUST match 'struct sockaddr_in' exactly! */
  short          sin_family;
  unsigned short sin_port;
  unsigned int   sin_addr;
  char           sin_zero [ 8 ] ;

As the comment saiys, it is DANGER since it highly depends on socket implementation. As a matter of fact, Apple implements the sockaddr_in struct in a different way:

struct sockaddr_in {
        __uint8_t       sin_len;
        sa_family_t     sin_family;
        in_port_t       sin_port;
        struct  in_addr sin_addr;
        char            sin_zero[8];            /* XXX bwg2001-004 */

sizeof(sockaddr_in) is the same but the member variables are not exactly the same. Especially the first and second members are critical, which caused the problem. So I made an easy-way-out kinda patch to avoid this issue. It seems working find on my Mac.

I'll make a quick tests on other Macs and make an updater package, combined with r154-candidate.

Fgcom and Favorite list - Sign of the next update


I've been working on building fgcom - A VOIP Radio communication add-on for FlightGear. Now it's done and works perfectly. I also got a request from a user about having a "Favorite list" in GUI launcher, which enables user to save and restore a set of options just like a bookmark of a web browser.

I implemented these and released as r154-candidate since I want users to check if it works on their Macs before making a release package. I guess fgcom should be tested in some different Macs.

It is available from FlightGear Mac OS X 1.0.0-r154 candidate.

Feedbacks are always welcome!


More than 10,000 downloads!


Wow, 1.0.0 has been downloaded more than 10,000 as of today. According to the stats, Jan. 11th was the date of serving 10,000th downloads. I'm very happy to know that more than 10,000 users use FlightGear on their Macs in a short time since 1.0 release.

Due to this rapid downloads, I've been able to receive some constructive feedbacks on 1.0.0 and 1.0.0-r151, which make me motivated to move on. I'll keep up to make this simulator better and easier. Actually I've updated GUI (r152) that reflects such feedbacks and encouragements that I've received from users. I like such emails since I can feel that many users like FlightGear and its GUI launcher.

it is also a good for you to tell us what you need, since you might be able to have it in the near future. So, if you find any questions, suggestions, or comments, just let me know. I'll reply as soon as I can. If you don't get any answer from me, maybe I'm busy doing something. Just keep sending me. I'll reply in a few days.

By the way, Apple has released MacBook Air - the world thinnest note book Mac. Though it's very attractive, I wonder if GMA X3100 (Intel's integrated graphic chip) can run FlightGear better than MacBook. I also wonder if SSD improves the frame rate. If it runs FlightGear at 20fps with default options, I want to have it. I also want to have some Tiger capable Macs for testing the release packages. I'm currently don't have Macs that has Tiger in it, which means I need to reboot my MacBook Pro to test the packages on Tiger. That's no good since I have to reboot on every debug.... Well, probably I should have old macs instead of new macs at least for now.....

T-4 "Blue Impulse" is updated, as well as other Japanese warbirds

I've updated T-4. I guess 3D model is getting better, and its behavior using JSBSim has reached to acceptable level. With my own comparison between Blue Impulse's demo flight pattern and my T-4's behavior in FlightGear, the gaps between these are less than 10% in most case. The updated T-4 is available from Aircraft page, so give it a try. The other Japanese warbirds are also updated and available from the page. T-4 also comes with yasim model, but is not that accurate, so it's good to use JSBSim version.

Though the changes in j7w and Ki-84 are not that much, but are compatible to 1.0.0/CVS. The changes made to A6M2 is big. Now A6M2b is integrated into A6M2 and you can change its livery (texture) at any time by pressing 'l' key. You can go visit Aircraft to get these aircraft.

New GUI is coming soon


Happy New Year!

FlightGearMacOSX-screenshot1.png SIZE:532x260(?KB)

Since I've been busy preparing FlightGear Mac OS X 1.0.0, I couldn't update GUI launcher. But Now FlightGear is released and I have a bit free time renewing GUI launcher for Mac OS. It'll be coming soon after some more tests.

Though GUI launcher is getting better compared to the one at the time when I involved to this project, I don't get satisfied at all.

The new GUI launcher has some new features including:

  • Aircraft searchable (using name, FDM, status, or filename (without -set.xml))
  • More Airport data (almost all airports/carriers in FlightGear), searchable with code, city/location, country, or name
  • Super Fast launching (less than three seconds with all aircraft from CVS when aircraft data are cached)
  • More Options like real-weather-fetch, visibility, etc
  • New Look (a bit though)
FlightGearMacOSX-screenshot2.png SIZE:532x582(?KB)

What I first did was adding full airport data to GUI launcher, but it took more than 20 seconds to read all data. So I changed the data format from binary plist to ruby script, which makes 10 times faster than the original one even with 20,000+ data.

Then, I added the aircraft search similar to airport search, which also reads all -set.xml files from Aircraft folder. Since the xml parser on ruby is very slow, it took about 5+ seconds to read all aircraft data. To make launch time shorter, I introduced cache mechanism in loading aircraft data. As a result, launch time is less than three seconds with all aircraft in CVS when fully cached.

Though searching airports takes a bit longer than the current version, flying from 20000+ airports in FlightGear is way better, I believe. so I'm very happy with the new GUI launcher.

GUI launcher is getting better compared to the one at the time when I involved to this project, but I don't get satisfied at all. I want to add more options, more useful features to Mac OS X version, so be patient!

By the way, I'm kinda interested in building fgcom for Mac OS X platform. Though it has some OpenAL related problems, it seems very attractive to me. If any of you already tried it out on Macs, please let me know.