X-Plane Plug-In (The House of X-Plane) XPL: Xset Plug-ins File: XPM: BMC Software Patrol UNIX Icon File: XPM: DESQview Macro (Symantec Corporation) XPM: X Pixmap Graphic: XPO: Expo Product Tours Project (InstallShield Software Corporation) XPO: Microsoft Dynamics AX Microsoft Dynamics AX (Microsoft Corporation) XPO: Omega Research ProSuite: XPO. Plz do not install x-plane in a userfolder on the desktop or any other folder in the os-hierarchy. Install x-plane in it's own folder directly in any root-folder of your drives, like 'c:/x-plane 11' or 'd:/x-plane 11' or whatever drive you prefer. 3) Fast HD, absolute best M.2 SSD Ideal to load X-Plane on SSD 4) Graphics card with at least 2 GB of VRAM, absolutely to have no limitation better than 8 GB 5) Monitor 24 'better than a 27'. Ideal 32 ' In the panel dedicated to Graphics, it is recommended to put the parameters to the maximum possible allowed by hardware available.
This document outlines how the DSF file format is used by X-Plane. DSF is a container format; new features can be added to the X-Plane scenery system without changing the file format. This document lists the different legal DSF configurations that X-Plane understands.
Note: this document is a low level reference, intended for programmers who intend to create tools to edit DSF files. Authors who want to edit DSFs should simply use higher level tools like OverlayEditor, or PhotoSceneryX.
Contents
- 2 DSF Properties
- 4 Mesh Types and Coordinate Organization
- 10 Data Validation
DSF Compression
Starting with X-Plane 10, X-Plane will read 7z-compressed DSF files (a single DSF compressed into a 7z archive) natively. X-Plane thus installs its DSFs without decompressing them, to save disk space. You may need to un-7z DSFs to read them. 7z compression is optional.
DSF Properties
DSF contains a series of properties, with string values. These are the properties X-Plane recognizes:
Bounding Box and Location Properties
All DSFs must contain four properties indicating the bounds of the DSF tile. These bounds are in degrees and must be integers. DSFs should contain a planet tag, which is optional, and assumed to be earth if missing.
| Property Name | Default | Value |
|---|---|---|
| sim/north | (Required) | degrees |
| sim/south | (Required) | degrees |
| sim/east | (Required) | degrees |
| sim/west | (Required) | degrees |
| sim/planet | earth | mars |
Object Density Control Properties
X-Plane only loads part of the facades and objects in a DSF, based on the “number of objects” setting in the rendering options. The “require” properties force X-Plane to load certain objects. Each require statement applies to either facades or objects, and specifies both the minimum setting where the objects are guaranteed loaded and the minimum index within the DSF of the object/facade it applies to.
More than one requirement statement can be used; all are combined together to meet all requirement constraints. Thus you can bring in objects incrementally through proper organization of the DSF object definition order.
| Property Name | Value | Minimum Sim Version |
|---|---|---|
| sim/require_object | obj_level/first_required_index | 8.0 |
| sim/require_agp | agp_level/first_required_index | 10.0 |
| sim/require_facade | obj_level/first_required_index | 8.0 |
Overlay Properties
The overlay properties control how a DSF is used as an overlay to other DSF files. The overlay property signals to X-Plane that the DSF should be loaded as an overlay and not a base mesh.
The exclude properties cause X-Plane to eliminate scenery from lower priority DSFs that are loaded underneath the overlay. Each exclusion zone is a rectangle specified in latitude and longitude. A DSF may contain multiple exclusion zones of the same type, and they may overlap.
| Property Name | Value |
|---|---|
| sim/overlay | 1 |
| sim/exclude_obj | west/south/east/north |
| sim/exclude_fac | west/south/east/north |
| sim/exclude_for | west/south/east/north |
| sim/exclude_bch | west/south/east/north |
| sim/exclude_net | west/south/east/north |
| sim/exclude_lin | west/south/east/north |
| sim/exclude_pol | west/south/east/north |
| sim/exclude_str | west/south/east/north |
The quality of culling depends on the type of scenery being excluded. In some cases, culling may over-remove or under-remove scenery.
[X-PLANE 9] X-Plane 9 improves the quality of forest exclusion. While X-Plane 8 forest exclusions remove a forest polygon if any vertex is in the exclusion zone, X-Plane 9 forest exclusion zones exclude on a per-tree basis for more precise cuts.
LOD Properties
[X-Plane 930:] Historically, X-Plane measures the distance of a mesh patch based on an arbitrary center point computed from the geometry. Since two different LOD mesh patches may have different vertices, their centers will be different. This cannot be predicted by authors. So for example, if a first patch has an LOD of 0 -> 20000 and the second one has 20000 -> -1, the first mesh patch may not disappear when the second one appears because they are being measured using different center points.
Setting the property sim/lod_mesh to 1 changes X-Plane’s behavior in the following way: the center point for LOD calculations of a mesh patch with a non-zero LOD start value will be taken from the previous mesh patch in the command stream.
This in turn means that a series of consecutive mesh patches with increasing LODs (starting at 0) will all have the same center point, and can be switched between using consecutive LOD values. (Also note that when this option is used, the closest LOD must come first, to establish the center point!
Other Properties
For historical reasons X-Plane will only flatten a terrain mesh if these properties are present.
| Property Name | Value |
|---|---|
| sim/creation_agent | X-Plane Scenery Creator 0.9 |
| sim/internal_revision | 0 |
Raster Layers
X-Plane 10 currently accepts one raster layers: “elevation”. Currently x-Plane can only handle a subset of raster formats: 16-bit signed integer with post-centric data. This matches what you’d find in a raw SRTM DEM.
Mesh Types and Coordinate Organization
X-Plane uses .ter files to specify the way mesh patches are drawn. The coordinate organization is:
- Longitude
- Latitude
- Elevation
- Normal – X
- Normal – Z
- Additional Coordinates…
These .ter files may contain “border” textures–the border feature of a .ter file is only used if the overlay flag is set in the mesh patch.
Mesh normals: the normal vector is stored as the X and Z ratio of the normal vector, based on a coordinate system of Y = up and Z = north at the mesh point’s location.
Additional coordinates are ordered optionally S1, T1, then optionally S2, T2. If an odd coordinate is provided, it is treated as alpha. If an alpha is needed but not present, X-Plane generates one using seeded random numbers.
| Base Texture is Projected | Composite Texture Is Projected | Border+Overlay Flag | ST1 Controls | ST2 Controls |
|---|---|---|---|---|
| no | no | no | base | |
| no | no | yes | base | border |
| no | yes | no | base | |
| no | yes | yes | base | border |
| yes | no | no | base | |
| yes | no | yes | base | border |
| yes | yes | no | ||
| yes | yes | yes | border |
X-Plane 8 does not use the alpha channel right now that a DSF may have.
Water terrain (“water” as a patch definition file) uses no ST or alpha coordinates.
Raster Data and Meshes
If elevation raster data is present, it will be used for the elevation of a mesh point as long as:
- The patch vertex’s elevation is -32768.0 or
- The patch vertex’s terrain type is water.
If elevation rater data is present, all normal vectors can be left as 0.0 – X-Plane will calculate them from raster data, for all terrain types.
(By convention v10 DSFs produced with LR’s scenery tools use explicit elevation for all water vertices and all coastal vertices, to ensure precise water elevation even near dams and to keep a water-tight seal between land and water. Interior land elevation points come from raster DEMs for data compression.)
Object Types and Coordinate Organization
Objects are placed with three or four coordinate values:
- Longitude
- Latitude
- Heading
- MSL height (optional in v10)
X-Plane 8 and 9 only allow AGL positioned objects (3 coordinates); X-Plane 10 allows for an optional 4th coordinate, interpreted as the MSL height of the object in meters.
Free Plane Graphics
AG Points (X-Plane 10 only) may only have three coordinates (lon, lat, heading) and are always draped.
Polygon Types and Coordinate Organization
Only one beach .bch definition may be used per DSF. Subtypes within the beach are used to create variety.
X-Plane uses a number of graphic resource files for DSF polygons. The meaning of the coordinates varies based on the type.
| File Type | Minimum Sim Version | Holes Allowed? | Parameter Meaning | Coordinates | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Facade (Flat, No Wall Choice) | 8.0 | No | Height (meters) | Lon | Lat | ||||||
| Facade (Flat, With Wall Choice) | 10.0 | No | Height (meters) | Lon | Lat | Wall Type | |||||
| Facade (Curved, No Wall Choice) | 10.0 | No | Height (meters) | Lon | Lat | Bezier Lon | Bezier Lat | ||||
| Facade (Curved, Wall Choice) | 10.0 | No | Height (meters) | Lon | Lat | Wall Type | Bezier Lon | Bezier Lat | |||
| Forest | 8.0 (10.0 for line and point fill) | Yes | Density (0-255) + Fill (0=solid,256=line,512=points) | Lon | Lat | ||||||
| Beach (MSL) | 8.0 | No | 0=chain,1=ring | Lon | Lat | Elevation | dx | dz | subtype | ||
| Beach (AGL) | 10.0 | No | 0=chain,1=ring | Lon | Lat | subtype | |||||
| Line (straight) | 8.5 | No | 0=chain,1=ring | Lon | Lat | ||||||
| Line (curved) | 8.5 | No | 0=chain,1=ring | Lon | Lat | Ctrl Lon | Ctrl Lat | ||||
| String | 8.5 | No | Spacing (meters) | Lon | Lat | ||||||
| String (Curved) | 8.5 | No | Spacing (meters) | Lon | Lat | Ctrl Lon | Ctrl Lat | ||||
| Draped Polygon (no UV) | 8.5 | Yes | Texture Heading | Lon | Lat | ||||||
| Draped Polygon (curved, no UV) | 8.5 | Yes | Texture Heading | Lon | Lat | Ctrl Lon | Ctrl Lat | ||||
| Draped Polygon (with UV Map) | 8.5 | Yes | 65535 | Lon | Lat | S | T | ||||
| Draped Polygon (curved, with UV Map) | 8.5 | Yes | 65535 | Lon | Lat | Ctrl Lon | Ctrl Lat | S | T | Ctrl S | Ctrl T |
| Autogen Block | 10.0 | No | Block Code + 256 * (Height / 4) | Lon | Lat | ||||||
| Autogen String | 10.0 | Yes | Number of Active Sides + 256 * (Height /4) | Lon | Lat | ||||||
For forests, the density is a scaling factor–255 makes the maximum number of trees, 0 makes none. This control is multiplied by the rendering settings to set a final number of trees. Tree density will not exceed the maximum possible density from the .for file.
X-Plane 10: in X-Plan 10, a packing code is added to forest density. 0 gives the default behavior of filling the polygon with trees. 256 gives the behavior of plotting trees along every line of the polygon, treating each contour as a poly-line. 512 gives the behavior of plotting a tree on each point in every contour. Note that:
- Poly-lines are not auto-closed with line filling (to allow for U shapes) so you must duplicate the final point to make a ring.
- In point-fill mode, all points are equal, so there is no advantage to using contour rings.
For beaches, the parameter can specify a ring, which connects the end point to the beginning. This will create a correct texture transition from the end to the beginning. The dx and dz coordinates for the beaches are a normal vector, similar to a DSF’s normal vector, and are used for draping the beach. The subtype parameter is an integral subtype which describes which beach from within the .bch file is used.
X-Plane 10: in X-Plane 10, the normal vectors and elevation of beaches can optionally be omitted, as X-Plane derives this information on the fly.
For draped lines (.lin), object strings (.str) and draped polygons (.pol) if bezier coordinates are present, then bezier curves are generated.
For object strings, the spacing of objects is controlled by the polygon parameter. For draped lines, the polygon may be treated as a ring or chain. Like beaches, best results come from using the ring feature rather than duplicating the first point. For a draped polygon, texture coordinates (ST from 0 to 1) may also be included–the parameter value 65535 indicates this.
For both autogen blocks (.agb) and autogen points (.ags) the height of variable height elements is encoded in the upper 8 bits of the parameter (e.g. * 256) and represents the metric height divided by four. (In other words, some precision in height is lost to allow for a wider range of building height.
For autogen blocks, the lower 8 bits of the polygon represent a spelling set code – this is used to look up which “spelling set” in the autogen block to use. A typical use is to use different tile arrangements based on different block codes. X-Plane’s global scenery, for example, uses codes 0-7 to indicate whether the “back 3” walls are road adjacent or not.
Autogen strings represent the strangest polygon feature of all. Unlike other polygons, the contours in AGS are interpreted as poly-lines (not closed polygon rigns!); the AGS is required to be a closed polygon with holes when all contours are considered.
The first N contours (where N is the lower 8 bits of the polygon parameter) will spawn autogen buildings; the rest of the contours are used only to create a closed polygon-with-holes area.
A few examples may help clarify autogen strings:
- In the case of a single rectangle city block with houses on all sides, there would be one contour with 5 points (the start point must be duplicated) and the polygon parameter N=1.
- In the case of a single rectangle city block where the north side has no houses, there would be two contours: the first contour would contain the NE, SE, SW, NW points and the second woul contain the NW, NE points. N=1 because only the first contour has houses.
- In the case where only the east and west sides of the block have houses, there would be four contours: NE,SE then SW, NW, then NW, NE, then SE,SW. N=2. Note that the first two and last two contours can swap with each other.
- In the case where a city block has houses on all sides but a lake in the middle, the first contour is the block (with a dupe point to close), the second is the lake (with a dupe point to close) and N=1.
Road Types and Coordinate Organization
Only one road.net definition may be used per DSF. Subtypes within the road file are used to create variety.
Road network files use 4 coordinates.
- Longitude
- Latitude
- Elevation
- Junction ID
Road segments are connected via junction IDs with the following rules:
- The DSF file’s junction IDs must start at 1 and contain no gaps. 0 is reserved as the “no junction” flag.
- A road chain must start and end with a junction.
- A junction must be used any time an intersection is desired.
- A junction must be used any time a road chain changes subtype.
- All nodes that share the same junction code must share the same coordinates.
- A junction should not be used for nodes that are designed only to change the path of a road (“shape” points), because the processing overhead is higher for junctions.
X-Plane 10: if the road.net specifies a draped road type then the elevation should be a stacking layer number (0 for the ground, then 1, 2, 3, etc.) for all junctions to specify overpasses. Within the chains, the shape point should be 0 for a vertex and 1 for a bezier curve control point. There must be no more than two consecutive control points in a road. (That is, quadratic and cubic bezier curves are allowed but no higher degere polynomials.) All bridge-crossing roads should use a junction so that the sim can ensure separation.
Overlay DSF Restrictions
DSF overlays have restrictions on the types of files they may use:
- [X-Plane 8:] Road networks are not allowed in overlays.
- Mesh patches are not allowed in overlays.
X-Plane 9 relaxes the road network rule–in X-Plane 9 a DSF overlay may contain a road network, but the one-.net-per-DSF rule still holds. When a DSF overlay has a road network and the base mesh does too, the junction IDs between the two do not connect.
Guidelines for DSF Extension
- Consider all properties starting with “sim/” as reserved.
- Do not add extra coordinates to vertices beyond what is in this spec.
Data Validation
These rules place limits on the kinds of data that can be specified for various art assets.
Base Mesh
- Every point within the lat-lon rectangular boundaries of the DSF must be covered by exactly one triangle that is ‘hard’ (meaning the hard flag in its parent patch is set).
- It is illegal for a triangle’s vertex to be located on the edge of another triangle; triangles must only meet vertex-to-vertex, not vertex-to-edge. (In other words, there can be no “T” junctions in the mesh.) Triangles meet at vertices if the coordinates of their vertices have the exact same lat, lon and elevation bit-values.
Objects/AGPs
- Objects must be within the DSF lat/lon boundaries.
- Object heading should be between [0 and 360).
Polygons
Area rules (these apply to facades with roofs, draped polygons, filled forests, AGS and AGB).
- All polygons must have counter-clockwise winding for exteriors and clockwise winding for holes.
- Polygons must not be self-intersecting.
Line rules (these apply to all polygons except for forests in “points” mode).
- Polygons must not have zero length sides.
Roads
- All roads chains must be made of at least one segment.
- All road segments must have positive length.
- It is illegal for a road segment to reverse direction (E.g. have a 180 degree turn).
- A junction must not have two roads entering the junction at the same heading and the same level.
- No more than two shape points within a chain can be bezier control points. (In other words, a cubic bezier is the highest degree bezier supported in curved roads.)
- While a bezier control point may be outside the DSF boundaries (typically the point pools contain some margin to allow this) the actual path of the road segment must remain within the DSF boundaries.
While it is not necessary, it is recommended that crossing roads share a junction at the crossing point with the roads on different levels; X-Plane can use this information to try to ensure that the roads are not reordered vertically due to the road draping and smoothing process.
A few notes on coordinate systems:
X-Plane uses three kinds of coordinates. Global coordinates are specifiedas latitude, longitude and elevation. This coordinate system never changes butis not very precise.
OpenGL (or ‘local’) coordinates are cartesian and shift with the plane. They offermore precision and are used for 3-d OpenGL drawing. The X axis is aligned east-westwith positive X meaning east. The Y axis is aligned straight up and down at the point0,0,0 (but since the earth is round it is not truly straight up and down at otherpoints). The Z axis is aligned north-south at 0, 0, 0 with positive Z pointing south(but since the earth is round it isn’t exactly north-south as you move east or westof 0, 0, 0). One unit is one meter and the point 0,0,0 is on the surface of theearth at sea level for some latitude and longitude picked by the sim such that theuser’s aircraft is reasonably nearby.
2-d Panel coordinates are 2d, with the X axis horizontal and the Y axis vertical.The point 0,0 is the bottom left and 1024,768 is the upper right of the screen.This is true no matter what resolution the user’s monitor is in; when running inhigher resolution, graphics will be scaled.
Use X-Plane’s routines to convert between global and local coordinates. Do notattempt to do this conversion yourself; the precise ‘roundness’ of X-Plane’sphysics model may not match your own, and (to make things weirder) the user canpotentially customize the physics of the current planet.
X-PLANE GRAPHICS
These routines allow you to use OpenGL with X-Plane.
XPLMTextureID
XPLM Texture IDs name well-known textures in the sim for you to use.This allows you to recycle textures from X-Plane, saving VRAM.
Warning: do not use these enums. The only remaining use they have is toaccess the legacy compatibility v10 UI texture; if you need this, get it via theWidgets library.
| Name | Value | Description |
|---|---|---|
| xplm_Tex_GeneralInterface | '0' | The bitmap that contains window outlines, button outlines, fonts, etc. |
| xplm_Tex_AircraftPaint | '1' | The exterior paint for the user's aircraft (daytime). |
| xplm_Tex_AircraftLiteMap | '2' | The exterior light map for the user's aircraft. |
XPLMSetGraphicsState
XPLMSetGraphicsState changes OpenGL’s fixed function pipeline state. You are not responsiblefor restoring any state that is accessed via XPLMSetGraphicsState, but you are responsible fornot accessing this state directly.
- inEnableFog - enables or disables fog, equivalent to: glEnable(GL_FOG);
- inNumberTexUnits - enables or disables a number of multitexturing units.If the number is 0, 2d texturing is disabled entirely, as inglDisable(GL_TEXTURE_2D); Otherwise, 2d texturing is enabled, anda number of multitexturing units are enabled sequentially, startingwith unit 0, e.g. glActiveTextureARB(GL_TEXTURE0_ARB);glEnable (GL_TEXTURE_2D);
- inEnableLighting - enables or disables OpenGL lighting, e.g.glEnable(GL_LIGHTING); glEnable(GL_LIGHT0);
- inEnableAlphaTesting - enables or disables the alpha test per pixel, e.g.glEnable(GL_ALPHA_TEST);
- inEnableAlphaBlending - enables or disables alpha blending per pixel, e.g.glEnable(GL_BLEND);
- inEnableDepthTesting - enables per pixel depth testing, as inglEnable(GL_DEPTH_TEST);
- inEnableDepthWriting - enables writing back of depth information to the depthbufffer, as in glDepthMask(GL_TRUE);
The purpose of this function is to change OpenGL state while keeping X-Planeaware of the state changes; this keeps X-Plane from getting surprised by OGLstate changes, and prevents X-Plane and plug-ins from having to set all statebefore all draws; XPLMSetGraphicsState internally skips calls to change statethat is already properly enabled.
X-Plane does not have a ‘default’ OGL state for plug-ins with respect to theabove state vector; plug-ins should totally set OGL state using this API beforedrawing. Use XPLMSetGraphicsState instead of any of the above OpenGL calls.
WARNING: Any routine that performs drawing (e.g. XPLMDrawString or widget code)may change X-Plane’s state. Always set state before drawing after unknown codehas executed.
Deprecation Warnings: X-Plane’s lighting and fog environemnt is significantlymore complex than the fixed function pipeline can express; do not assume thatlighting and fog state is a good approximation for 3-d drawing. Prefer to useXPLMInstancing to draw objects. All calls to XPLMSetGraphicsState should haveno fog or lighting.
XPLMBindTexture2d
XPLMBindTexture2d changes what texture is bound to the 2d texturing target.This routine caches the current 2d texture across all texturing units in the simand plug-ins, preventing extraneous binding. For example, consider severalplug-ins running in series; if they all use the ‘general interface’ bitmap to doUI, calling this function will skip the rebinding of the general interface textureon all but the first plug-in, which can provide better frame rate son some graphicscards.
inTextureID is the ID of the texture object to bind; inTextureUnit is a zero-basedtexture unit (e.g. 0 for the first one), up to a maximum of 4 units. (This numbermay increase in future versions of X-Plane.)
Use this routine instead of glBindTexture(GL_TEXTURE_2D, ….);
XPLMGenerateTextureNumbers
Use this routine instead of glGenTextures to generate new texture object IDs.This routine historically ensured that plugins don’t use texure IDs that X-Plane isreserving for its own use.
XPLMGetTexture
XPLMGetTexture returns the OpenGL texture ID of an X-Plane texture based on ageneric identifying code. For example, you can get the texture for X-Plane’s UIbitmaps.
XPLMWorldToLocal
This routine translates coordinates from latitude, longitude, and altitude to localscene coordinates. Latitude and longitude are in decimal degrees, and altitude isin meters MSL (mean sea level). The XYZ coordinates are in meters in the localOpenGL coordinate system.
XPLMLocalToWorld
This routine translates a local coordinate triplet back into latitude, longitude,and altitude. Latitude and longitude are in decimal degrees, and altitude isin meters MSL (mean sea level). The XYZ coordinates are in meters in the localOpenGL coordinate system.
NOTE: world coordinates are less precise than local coordinates; you shouldtry to avoid round tripping from local to world and back.
XPLMDrawTranslucentDarkBox
This routine draws a translucent dark box, partially obscuring parts of thescreen but making text easy to read. This is the same graphics primitive usedby X-Plane to show text files and ATC info.
X-PLANE TEXT
XPLMFontID
X-Plane features some fixed-character fonts. Each font may have its own metrics.
WARNING: Some of these fonts are no longer supported or may have changed geometries.For maximum copmatibility, see the comments below.
Note: X-Plane 7 supports proportional-spaced fonts. Since no measuring routineis available yet, the SDK will normally draw using a fixed-width font. You canuse a dataref to enable proportional font drawing on XP7 if you want to.
| Name | Value | Description |
|---|---|---|
| xplmFont_Basic | '0' | Mono-spaced font for user interface. Available in all versions of the SDK. |
| xplmFont_Menus | '1' | Deprecated, do not use. |
| xplmFont_Metal | '2' | Deprecated, do not use. |
| xplmFont_Led | '3' | Deprecated, do not use. |
| xplmFont_LedWide | '4' | Deprecated, do not use. |
| xplmFont_PanelHUD | '5' | Deprecated, do not use. |
| xplmFont_PanelEFIS | '6' | Deprecated, do not use. |
| xplmFont_PanelGPS | '7' | Deprecated, do not use. |
| xplmFont_RadiosGA | '8' | Deprecated, do not use. |
| xplmFont_RadiosBC | '9' | Deprecated, do not use. |
| xplmFont_RadiosHM | '10' | Deprecated, do not use. |
| xplmFont_RadiosGANarrow | '11' | Deprecated, do not use. |
| xplmFont_RadiosBCNarrow | '12' | Deprecated, do not use. |
| xplmFont_RadiosHMNarrow | '13' | Deprecated, do not use. |
| xplmFont_Timer | '14' | Deprecated, do not use. |
| xplmFont_FullRound | '15' | Deprecated, do not use. |
| xplmFont_SmallRound | '16' | Deprecated, do not use. |
| xplmFont_Menus_Localized | '17' | Deprecated, do not use. |
| xplmFont_Proportional | '18' | Proportional UI font. |
X Plane Graphics Interface File Size
XPLMDrawString
X-plane Cannot Open The Graphics Interface File
This routine draws a NULL termianted string in a given font. Pass in the lowerleft pixel that the character is to be drawn onto. Also pass the character and font ID.This function returns the x offset plus the width of all drawn characters.The color to draw in is specified as a pointer to an array of threefloating point colors, representing RGB intensities from 0.0 to 1.0.
XPLMDrawNumber
What Is Graphic User Interface
This routine draws a number similar to the digit editing fields in PlaneMaker and dataoutput display in X-Plane. Pass in a color, a position, a floating point value, andformatting info. Specify how many integer and how many decimal digits to show andwhether to show a sign, as well as a character set.This routine returns the xOffset plus width of the string drawn.
X Plane Graphics Interface File Software
XPLMGetFontDimensions
X Plane Graphics Interface File Download
This routine returns the width and height of a character in a given font.It also tells you if the font only supports numeric digits. Pass NULLif you don’t need a given field. Note that for a proportional font thewidth will be an arbitrary, hopefully average width.
XPLMMeasureString
This routine returns the width in pixels of a string using a givenfont. The string is passed as a pointer plus length (and does not needto be null terminated); this is used to allow for measuring substrings.The return value is floating point; it is possible that future fontdrawing may allow for fractional pixels.