Part of my trip through geekdom lead me to Microsoft Flight Simulator. I've dreamed of becoming a pilot but never had the resources or eyes to do it for real. FS gave me a chance to play and get some sense of what flying is like, mind you without the inner ear working for you, it's certainly nowhere near the same.
Part of the thrill of FS for us geeks is the ability to add your own plug-ins to implement your own instrument gauges and your own airplanes. The gauge SDK was particularly interesting to me and lead me to ponder whether one could create a reasonable flight navigation system with maps and data, much like is common place with modern GPS systems. I think I had enough info to pull it off, but of course, never got the time to do it.
That investigation did help me cross paths with Garmin. They are the leaders in flight navigation systems for general aviation aircraft. They have some pretty sophisticated software and some pretty solid hardware to make it easy to navigate an aircraft through the airways. And they keep getting better, going from simple textual lcd screens, to two dimensional graphical displays showing maps in 2D. And the displays kept getting bigger and contained more and more information to help a pilot with his situation awareness, a key to survival in the cockpit.
And now, they've added 3D display of the terrain and obstacles and other aircraft in your vicinity. Here's a video of a reporter talking to a Garmin rep. It's like the world coming full circle. Instead of trying to figure out how to make a video game more real, they're trying to make reality more like a video game! The reporter asked the right question, aren't pilots going to be more interested in watching this wicked cool technology than look out the airplane like they're supposed to? I know I would.
Anyway, I hope this is the leading edge of what we'll soon see in embedded devices where it makes sense, i.e., more use of 3D graphics. I think it really helps the user experience be more real. We're seeing it already with Mac and Vista. And with announcements like Nvidia's Tegra and seeing what the Garmin has done with their system, I can see it useful for devices as well.
BTW, speaking of the FS SDK, when I mentioned OSGi for C++ the other day, that SDK came to mind and is a great example of how to build a simple component model with interfaces for providing services into a common framework. There are certainly other examples and makes me think standardizing on one at least similar to OSGi, might really be a good idea. More on that later...
You should really get a trial in a light aircraft. It's great fun, and it's much cheaper in North America than it is over in Europe.
ReplyDeleteis there a way to add gdb commands to breakpoints's actions?
ReplyDeletee.g. let's say that i have a custom desing gdb command like:
plist l int
i'd like this gdb command to be executed each time the breakpoint is hit and of course, to be able to add any number of "debugger" actions to each breakpoint
or, to have a specialized watch (or even expression) containing gdb custom design commands...
i am using stl intesively and i'd like to use eclipse as well. i could not find these capabilities yet.
so, mainly to have new type of breakpoint action, called debugger action, allowing you to add any gdb command (which will be executed, just like any other actions, when breakpoint is hit)
ReplyDeleteA framework like OSGi for C++ would be great. But another issue that has to be addressed is interoperability and compatibility between different compiler versions and vendors.
ReplyDeleteIn C++, code often needs to be tweaked to even compile with the next compiler version. When you have to support compilers from different vendors, it's even worse. It's frustrating to see that after such a long time, interoperability is in practice not much more than C89.
I'll give an example: A co-worker of mine some time ago started on a C++ project in his freetime (using wascana btw). Now, he wanted to connect to a database, downloaded a C++ library for database access but failed to compile it under mingw. So what? He had the Visual Studio express installed, and with some clicks had the library compiled with that compiler. The next day, he asked "What do I have to do to link that library to my wascana project? The linker always complains!". Of course you all know the answer: It can't be done.
But does it really have to be that way?
OSGi (or similar) for C++ makes it easy to plug modules together, but creating these very modules often is harder than it should be.
Very true axel. That's why you see most native component technologies base themselves on C, not C++. Even the venerable old Microsoft COM is a C function table. It works as is in C++ because the COM guys sit next to the compiler guys and convinced them to make the C++ virtual function table layout the same as COM.
ReplyDeleteSO when I say OSGi for C++, I guess I really mean for C and we can write C++ wrappers around it to make it nicer for C++ developers. And we can do the same for other languages. But C has a critical role these days.