Skip to content

libxplanemp 2.0 changes

Chris Collins edited this page Mar 9, 2018 · 5 revisions

This is a list of changes to be expected in libxplanemp 2.0:

Y Clamping is Simplified

  • A CSL can have no offset, a CSL definition defined offset (via VERT_OFFSET), or an externally defined offset.
  • Clamping is enabled or disabled per Plane.

Basically, I don't want the specifics of other clients slipping into libxplanemp - if you want to maintain your own external database of vertical offsets and blend that data in, do it in your client and use the externally defined offset adjustment to set it.

Per plane clamping is required as hard clamping may not be required at all times, and it may well be preferable to be able to switch it off per plane if an alternate (cheaper) clamping strategy is available to the client.

Rendering Changes

  • ACF CSLs are gone.
  • Obj8 CSLs are losing the GLASS subobject as they cannot be supported using XPLMInstance in the same way.
  • Obj8 CSLs are losing LOWLOD subobjects as they're not used for anything
  • LegacyCSL will be left in the codebase for now, but will soon need a #define to be included - I won't be supporting it any longer or accepting patches for it.

Mostly the consequence of the upcoming demise of OpenGL rendering in the 3D passes.

Aircraft labels are in a difficult spot right now

Right now, because it's not possible to translate the aircraft positions during render to window coordinates reliably, we can't paint the labels in the 2D (Windowing) phases. (It works for a single monitor system, but doesn't work at all for multidisplay).

As a result, label rendering has to happen in the deprecated Aircraft rendering phase.

There's a good chance this won't survive the XP11 cycle unless we get a solution from Laminar on this one - I simply haven't found a way to work out which display the Render call is occurring against so I can correlate it to the Global Bounds data.

No callbacks

libxplanemp 2.0 doesn't use callbacks to get aircraft data - instead, it provides a bulk forward update mechanism - your client code should push new state into libxplanemp once a frame if it's animating/interpolating, or as able otherwise. You can drive this through an XPLMProcessing hook.

libxplanemp 2.0 also doesn't use callbacks for configuration state - the old IntPref/FloatPref callbacks are gone - instead, there's a gConfiguration_t struct which contains all of the client adjustable parameters for libxplanemp. This was done to remove a overhead where config parameters were being polled regularly, but also to ensure that references to configured parameters are subject to type/name checks.