GitXplorerGitXplorer
n

KerbalHUD

public
1 stars
1 forks
0 issues

Commits

List of commits on branch master.
Unverified
ddf3e18db1f152882280a799ab16d510df6ce695

clean up a little

nndevenish committed 9 years ago
Unverified
033e77fe8d65323ab3ef48e83bca466f4cdc795c

Don't standby

nndevenish committed 9 years ago
Unverified
e091d35470b9f9dfa472989e623817d6d6577916

Fix discolouring of text when using deferred text renderer

nndevenish committed 9 years ago
Unverified
6ed157882263a04dbeb280baea82949a2d9e73af

Add prograde/markers to binary subscription

nndevenish committed 9 years ago
Unverified
db5bb61746315a451b153a31c2d6dd28e05c33cd

Use new, dynamic binary packets

nndevenish committed 9 years ago
Unverified
c58c1407b347a88ece29aa901d2c6f29e5028d8c

Fix deferred renderer NOT to draw atlas every time

nndevenish committed 9 years ago

README

The README file for this repository.

KerbalHUD

Implements an RPM-style flight hud in swift 2.0 for runnning on iOS devices. This means that it requires a minimum of Xcode 7, along with some method of getting it onto your device.

Requires currently:

Where the custom changes for telemachus are currently in the process of being reviewed and included in the main branches.

In principle the RPM dependency could be eased out down the line by e.g. not requiring any of the variables, but at the moment the supported instruments require quite a few RPM variables.

For the FAR flaps setting visibility, a version of RasterPropMonitor > v0.22.0 is required.

As far as compatibility and efficiency, I've tested on a 1st Gen iPad mini, an iPhone 5 and an iPad mini 4 and it works fine, but claim no expertise or even that the OpenGL code is a good and efficient implementation. It seems to work well enough though.

Configuration

There is no run-time configuration at the moment. The address that it uses to connect is currently hardcoded; currently at GameViewController.swift:60.

Without a connection, it will run with some contrived test data.

Future Plans

More screens/configurability would be nice. A lot of the infrastructure for reading external displays, or even reading RPM definitions directly are in place, but this is still in very early stages.

A proper interface with configurable kerbal connections would be very useful.

Current status

  • Multiple simultaneous instruments, zoomable to fullscreen based on touch
  • RPM Plane HUD
  • RPM NavBall - spherical texture created on the fly at full resolution
  • Navutilities HSI
  • Pretty flexible text layout from arbitrary variables
  • SVG-based overlays/images

Navball Display Plane HUD