Hi fellow wiki editors!

To help newly registered users get more familiar with the wiki (and maybe older users too) there is now a {{Welcome to the wiki}} template. Have a look at it and feel free to add it to new users discussion pages (and perhaps your own).

I have tried to keep the template short, but meaningful. /Johan G

Project Farmin

From FlightGear wiki
Jump to: navigation, search
This article or section contains out-of-date information

Please help improve this article by updating it. There may be additional information on the talk page.

FARMINLogo.png
Started in 01/2015
Description Canvas and MapStructure based Flight deck Framework (see: Canvas Animation Framework/Canvas MFD Framework)
Maintainer(s) www2
Contributor(s) www2
Status Early Prototyping for the FG1000 PFD
Folders $FG_ROOT/Aircraft/Instruments-3d/Farmin
Website https://github.com/www2000/Farmin

Project Farmin is a project aiming at making an aircraft independent framework simulating the Garmin flight decks (G500(H), G600, G900X, G950, G1000(H), G2000, G3000, G5000(H)).

Currently the focus is on the G1000 that is in use on 1 or 2 engine props and jets, for example Cessna 172R/S, 208/208B Caravan, Mustang and Embraer Phenom.

Background

Cquote1.png Canvas itself is a great piece of technology, but using it to implement complex MFDs is like asking someone to create an object-oriented and multi-threaded application using assembly language: it is possible, but very tedious and requires tons of experience and expertise. This is basically the reason why the most generic Nasal/Canvas code was typically written by people already familiar with FG/SG and OSG internals (i.e. core developers).
— Hooray (Mon Feb 02). Re: Project .
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Canvas is an important piece of technology in FlightGear, but it really is just a "toolbox" providing low-level tools for 2D drawing via OpenVG primitives, raster/vector images, and osgText.

However, you'll find that when designing complex MFDs, you need much higher-level functionality, ideally encapsulating important shared concepts - such as having components (=classes) for things like:

  • MFD class
  • Screen class
  • Page class
  • PageManager class
  • Layout/LayoutManager class
  • Button/switch class
  • Mode class
  • Animation class

— Hooray (Mon Feb 02). Re: Project .
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png this is more about identifying requirements first and coming up with a few simple framework for your requirements - which normally also means that others working on unrelated instruments would benefit from those changes, and might even team up at some point (which is what happened to the ND effort, we've seen people contribute to Gijs' 744 ND code, despite never having taken any interest in the 744 at all, simply because that code now allows "styles" to be configured for other airliners)
— Hooray (Mon Feb 02). Re: Project .
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Canvas is still a relatively new feature in FG terms, and like I said, it being pretty low-level, it is conceivable that Canvas will continue to be extended over time to provide better building blocks, or even just better performance - however, doing so is only feasible if people adopt a framework-centric development approach, so that key functionality is properly "encapsulated" (e.g. through a helper class) - which means that if/when more native (=faster) Canvas animation support should be added, we would only need to update the single helper class encapsulating the concept of an Animation - however, what is currently being done all over the place in fgdata, is that Nasal/Canvas related code is written from scratch without things being encapsulated at all - in other words, even if Tom should make a huge commit tomorrow improving Canvas performance/efficiency by 500%, we would still need to manually port/update all the legacy code, because there's no encapsulation taking place.



Overall, we want to support complex MFDs via Canvas, but people should really share their work much earlier so that we can come up with a subset of common/overlapping goals and find a way to meet all requirements, without adding even more problematic Nasal code to the FlightGear base package.


— Hooray (Mon Feb 02). Re: Project .
(powered by Instant-Cquotes)
Cquote2.png

Development

Status Farmin Garmin Family Manual on Garmin site* Extra info
10}% completed FG500 G500 G500/G600 True None
10}% completed FG500H G500H G500/G600 True Helicopter version of the FG500/G500
10}% completed FG600 G600 G500/G600 True None
10}% completed FG900X G900X G1000 False Flight deck for kitplane
10}% completed FG950 G950 G1000 True OEM/after market
10}% completed FG1000 G1000 G1000 True None
10}% completed FG1000H G1000H G1000 True Helicopter version of the G1000
10}% completed FG2000 G2000 G3000 True 2 Screens and 1 touchscreen
10}% completed FG3000 G3000 G3000 True 3 Screens and 2 touchscreen
10}% completed FG5000 G5000 G5000 False Up to 4 screens and 4 touchscreen
  • This mean not that the manuals are on the web

Components

MFD

Top level helper class managing all related components.

ImageSource

An ImageSource will be an invisible Canvas representing the video/graphics output of a display.

var ImageSource = {
 new: func(x,y) {

  var m = {parents:[ImageSource]};
  m.canvas = canvas.new({
  "name": "ImageSource-"~name,   
  "size": [x, y], 
  "view": [x, y],  
  "mipmapping": 1       

 });
 return m;
 },
 del: func() {
 },
};

Screen

A Screen will merely be a placeholder for another Canvas referenced via canvas:// - so that arbitrary placements can be used to display a MFD screen.

var Screen = {
 new: func() {
 },
 attach: func(source) {
 },
 del: func() {
 },
};

ImageSourceSelector

A helper class to manage multiple image sources and hook them up to screens - i.e. for allowing MFDs to be shown on different screens.

Screen Shots

Some screen shots are posted on the forum thread (see below)

Related content

Forum topic