20,741
edits
Howto:Optimizing FlightGear for mobile devices: Difference between revisions
Jump to navigation
Jump to search
m
Howto:Optimizing FlightGear for mobile devices (view source)
Revision as of 10:18, 28 July 2012
, 28 July 2012→Linux-based Targets (Android, Maemo etc)
| Line 32: | Line 32: | ||
Now, Android/Maemo support should be easier to implement than Playstation, Nintendo Wii, IPhone and all the other platforms that people keep asking about - simply, because Android/Maemo is basically a downstripped Linux version, so compiling/building FG would certainly be possible. However, running would still be "interesting", there are MANY potential issues here, even on a "full" Linux-System like Android: http://stackoverflow.com/questions/653453/how-would-i-go-about-making-a-flight-gear-port-for-wiibrew | Now, Android/Maemo support should be easier to implement than Playstation, Nintendo Wii, IPhone and all the other platforms that people keep asking about - simply, because Android/Maemo is basically a downstripped Linux version, so compiling/building FG would certainly be possible. However, running would still be "interesting", there are MANY potential issues here, even on a "full" Linux-System like Android: http://stackoverflow.com/questions/653453/how-would-i-go-about-making-a-flight-gear-port-for-wiibrew | ||
Cross-compiling FlightGear for Android devices is not that problematic. However, running FlightGear on an Android device, requires a fair share of customizations, i.e. a downstripped base package, and custom aircraft modifications (key bindings, mouse vs. touch screen support etc). Also, many FlightGear defaults would be unnecessarily high and would not work "as is", these could be reduced (scenery complexity, shaders, rendering settings). | Cross-compiling FlightGear for Android devices is not that problematic. However, running FlightGear on an Android device, requires a fair share of customizations, i.e. a downstripped base package, and custom aircraft modifications (key bindings, mouse vs. touch screen support etc). Also, many FlightGear defaults would be unnecessarily high and would not work "as is", these could be reduced (scenery complexity, shaders, rendering settings). | ||
== OpenGL vs. OpenGL ES == | |||
If FG could be made to run with opengl ES (supported by OSG), it could potentially run on mobile devices that support it and have high enough resources, so long as the rest of the FDM, terrain, and models would work too. However, how to compile the code would depend on the OS, and it seems the iphone uses a cut-down embedded version of OS X. Regular FG can work with regular OS X, so it seems plausible that it could be compiled for the modified OSX (maybe the iphone sdk would help here). | |||
I have hope this is possible if we can find somone with more expertise in programming. I mean, we know FG can run on OS X, and that it needs Open GL. The iphone can use OpenGl ES and seems to use a cut down OS X. | |||
If the differences between them can be over come, then it would be a matter of getting FG system requirements low enough. There is enough hard drive space for even the full version, so its a matter of running it (if the software issues can be overcome). 128 mb memory and the processor seems low, but rendering hvga or qvga is less demanding too. | |||
== Embedded Platforms == | == Embedded Platforms == | ||