GitXplorerGitXplorer
n

KerbalHUD

public
1 stars
1 forks
0 issues

Commits

List of commits on branch master.
Unverified
e38953ecb00ad1c016de554cd5d43483d1ea7c81

Update README

nndevenish committed 9 years ago
Unverified
b5923586598b8f3ea5d7e658a3b61553c18a4be9

Update SwiftJSON/Websockets

nndevenish committed 9 years ago
Unverified
48c94ac9e34c28d2d3248d81fef24d2a544b3be8

Add a kerbal configuration parser

nndevenish committed 9 years ago
Unverified
c7b8355e7dbb7176fc09ea76ade32769de3e7429

Lexify kerbal configs

nndevenish committed 9 years ago
Unverified
f2d67618ac2a2dbd8945395fcbd48f7da93ad076

Tidy point, drawing a little

nndevenish committed 9 years ago
Unverified
b60a107c2f367661017e4a92cb64680f419465dc

Points control their own vertex attributes, and allow text deferrer to use colors

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