FlightGear and OpenGL Core Profile: Difference between revisions

Jump to navigation Jump to search
Line 23: Line 23:
{{Main article|Howto:Optimizing FlightGear for mobile devices}}
{{Main article|Howto:Optimizing FlightGear for mobile devices}}


The OpenSceneGraph port initiated in 2006 has never been fully completed, so that there is a certain amount of legacy code making use of legacy OpenGL code, which complicates on modernizing the renderer. In particular, this means that [[Supporting multiple renderers]] is unnecessarily complicated, [[Unifying the 2D rendering backend via canvas|unifying the 2D rendering back-end]] is a long standing challenge. It's only since just very recently, that supporting different renderers is being worked on thanks to the [[Compositor]] effort.
The OpenSceneGraph port initiated in 2006 has never been fully completed, so that there is a certain amount of code making use of legacy OpenGL calls, which complicates modernizing the renderer.  


But even then, phasing out legacy code or porting it, still needs to be adressed sooner or later.
In particular, this means that [[Supporting multiple renderers]] is unnecessarily complicated, [[Unifying the 2D rendering backend via canvas|unifying the 2D rendering back-end]] is a long standing challenge. It's only since just very recently, that supporting different renderers is being worked on thanks to the [[Compositor]] effort.
 
But even then, phasing out legacy code or porting it, still needs to be addressed sooner or later.


Being able to run fgfs on such, comparatively low-powered, systems using OpenGL ES can actually be a good thing for fgfs as a whole - it can help us understand bottlenecks that are hardly visible on typical gaming/developer rigs, but that may still show up over time (think leaking listeners/memory) - this sort of thing can also be considered the prerequisite for people wanting to target/build/run fgfs on other embedded hardware, such as thin clients with integrated GPUs or even mobile phones/tablets (think Android)
Being able to run fgfs on such, comparatively low-powered, systems using OpenGL ES can actually be a good thing for fgfs as a whole - it can help us understand bottlenecks that are hardly visible on typical gaming/developer rigs, but that may still show up over time (think leaking listeners/memory) - this sort of thing can also be considered the prerequisite for people wanting to target/build/run fgfs on other embedded hardware, such as thin clients with integrated GPUs or even mobile phones/tablets (think Android)

Navigation menu