Hi Ross,
 
Giving some thought on how to organize the OpenGC files. would have used private mail but I don't have all your individual emails.
 
Given the size of monitors today, it is possible to fit more than one display panel on a single screen. For example, a 19" screen can hold a PFD and ND panel with a AFDS MCP above it. With a smaller 15" monitor to the right you can place an EICAS primary and secondary, if you have a third you can now provide an MCDU and also use it as a secondary MCP for the secondary EICAS. Or a 15'' as a PFD and a 19" for the ND and EICAS. or ....
 
Each monitor would/could be driven by an app and interconnected via the LAN to the FG side and each other. If one has the resources you might want to have a dedicated FMC to run the nav and generate commands to send to the FCC's (which could be on the FG side or the Opengc side that calculates the control commands to send to FG) or another scene generator, or run some non-display apps in the background on each machine to distribute the compute load, or whatever. In general, the idea is to allow the user to mix and match the various applications to fit the particular hardware configuration and compute resources.
 
As a first cut, seems reasonable to create a directory for each display (entity) and build libraries for each; then envoke the linker with the list of libraries to build the app as desired. it might get a little tricky trying to get two or three panels in the right locations, but the geometry of the flight deck and locations are static and known a priori so it seems doable with .xml or .ini files at startup.
 
ATM I'm trying to relocate the files and some stubs into a set of directories and create the associated makefiles and see what falls out. I ' ve grown kind of fond ;-) of the FG structure so it will probably wind up looking a lot like that. There will be a main, a directory for each panel and entity, a network, some utilities (lots of strings and msgs), and so forth. Also working on a brief description doc for all the various displays and modes. (There is a lot, and I mean a LOT of code to design!)
 
Any ideas, comments, opinions, suggestions,  -- fire away!
 
Regards
John W.
 
Comments, suggestions,
 

Reply via email to