Howto talk:Create a 2D drawing API for FlightGear
Competing and conflicting ideas
This is one of the longest standing feature requests at all, so there are LOTS of ideas around, including some of which would seem competing and conflicting with the approach I currently favor, such as:
—This unsigned comment was added by Hooray (Talk | contribs) 20:55, 5 February 2012 (UTC)
I have started to experiment with OpenVG using the ShivaVG implementation and a basic SVG parser using the XML parsers included with Simgear. Until now it works quite well...
--TheTom 05:47, 21 April 2012 (EDT)
Things to keep in mind
- standalone FG use (FGPanel)
- uses not specific to instruments ?
- multiple screens?
- ARINC 661
—This unsigned comment was added by Hooray (Talk | contribs) 20:55, 5 February 2012 (UTC)
Why not use a simple draw line function in openGL?
First of all, I'm EXTREMELY new to this (like 2 minutes) so please excuse me if the question is stupid or the answer is obvious.
I'm thinking why not draw the line with openGL? why cairo and other things? We don't need a 3d drawing API do we? just a 3d one for instrument panels.
Shouldn't something like this in openGL work?
void DrawLine( int ax, int ay, int bx, int by, int width, int r, int g, int b, int a )
{
glDisable(GL_TEXTURE_2D);
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
glColor4ub( r, g, b, a);
glLineWidth(width);
glBegin(GL_LINES);
glVertex2i( ax, ay);
glVertex2i( bx, by);
glEnd();
glDisable(GL_BLEND);
glEnable(GL_TEXTURE_2D);
}
And to get that functionality in nasal, connect the 'Drawline(<arguments>)' function using an fg_command?
—This unsigned comment was added by Omega1174 (Talk | contribs) 14:22, 15 February 2012 (UTC)
- Yes, you could obviously use "raw" OpenGL here too (pretty much all existing hard coded instruments are doing this already). The thing is, that at some point, you'll probably need more 2D drawing features (more than just primitives like points, lines etc), these would need to be replicated and built on top of OpenGL/OSG, at some point, there's tons of optimization potential which is 2D specific (and already provided by existing libs) - alternatively, one could use an existing 2D drawing library that already has OpenGL support using an internal OpenGL backend and which is already sufficiently optimized. But agreed: for just basic primitives, cairo/glitz might really be overkill. Regarding the fgcommand idea you suggested: Thinking about it, that MIGHT actually work, but it would get tedious pretty soon in my opinion - you would need to provide a bunch of arguments (such as texture handles, OpenGL modes and such) and then implement a handful of primitives, all of this going through the property tree. Keep in mind, that you'll ideally need to be able to create and render to new textures dynamically, and then reference/use these texures in existing instruments/cockpit panels. Also, all raw OpenGL code needs to be properly wrapped for use with the rest rest of OSG-based code, so that it doesn't interfere with it. I hadn't considered using fgcommands for this actually, regardlress of the tutorial that I just wrote. To me, it would feel more natural to implement a new instrument subsystem and provide some Nasal hooks to handle the drawing stuff. To be honest, the idea discussed in Canvas Properties sounds even more intriguing, because it would automatically support other -more advanced- uses, like the ongoing FGPanel stuff. You would basically need to come up with a new SGSubsystem that isn't just specific to instruments anymore, but which could be used for other 2D drawing needs, too. To be honest, even creating just a Nasal specific GL wrapper would feel more natural to me than using fgcommands here. On the other hand, if you'd like to look into the fgcommands approach, I'd certainly be willing to help you with the implementation details, but with all the fgcommands marshalling required for parameter processing, extending the Nasal APIs might actually be simpler. --Hooray 17:06, 15 February 2012 (EST)