Application entry point and process-level runtime services.

App owns the runtime bootstrap sequence for the engine. It initializes Kha, input devices, audio, default resources, shader compilation, and the main frame loop.

In normal projects App is configured declaratively through compile-time @:app.* metadata handled by the @:autoBuild macro on this class. The macro collects those metadata entries, builds a kha.SystemOptions object, and rewrites main() into a call to start.

Typical usage:

@:app.title("Game")
@:app.window(width = 750, height = 500)
@:app.framebuffer(samplesPerPixel = 2, verticalSync = false)
class Main extends s.App {
}

The example above becomes roughly:

s.App.start({
	title: "Game",
	window: {
		width: 750,
		height: 500
	},
	framebuffer: {
		samplesPerPixel: 2,
		verticalSync: false
	}
}, window -> {
	// original main body
});

@:app.* metadata are therefore just shortcuts for kha.SystemOptions. The supported top-level metadata names are:

Supported @:app.window(...) fields:

  • title:String Window title. Overrides @:app.title(...) for the actual OS window caption.
  • x:Int Horizontal window position in screen coordinates. -1 lets the backend choose automatically.
  • y:Int Vertical window position in screen coordinates. -1 lets the backend choose automatically.
  • width:Int Initial client width in pixels.
  • height:Int Initial client height in pixels.
  • display:Int Display index for multi-monitor setups. -1 lets the backend choose.
  • visible:Bool Whether the window starts visible.
  • windowFeatures:kha.WindowFeatures Bitmask of optional window capabilities. Combine flags with |.
  • mode:kha.WindowMode Window presentation mode.

Available kha.WindowFeatures flags for windowFeatures:

The default Kha feature mask is:

kha.WindowFeatures.FeatureResizable
| kha.WindowFeatures.FeatureMaximizable
| kha.WindowFeatures.FeatureMinimizable

Available kha.WindowMode values for mode:

  • kha.WindowMode.Windowed Uses a regular OS window.
  • kha.WindowMode.Fullscreen Uses regular fullscreen mode.
  • kha.WindowMode.ExclusiveFullscreen Uses exclusive fullscreen mode. In Kha this is primarily meaningful on Windows and may switch the monitor resolution.

Supported @:app.framebuffer(...) fields:

  • frequency:Int Preferred refresh frequency in Hz. The backend may ignore unsupported values.
  • verticalSync:Bool Enables or disables vertical sync.
  • colorBufferBits:Int Requested color buffer precision in bits.
  • depthBufferBits:Int Requested depth buffer precision in bits.
  • stencilBufferBits:Int Requested stencil buffer precision in bits.
  • samplesPerPixel:Int Requested MSAA sample count. Use 1 to disable multisampling.

Supported @:app.audio(...) fields:

  • allowMobileWebAudio:Bool HTML5-only Kha option that enables audio2.Audio initialization on mobile browsers. Use this when the application must opt into mobile Web Audio behavior.

Example with less common options:

@:app.title("Game")
@:app.window(
	width = 1280,
	height = 720,
	mode = kha.WindowMode.Windowed,
	windowFeatures = kha.WindowFeatures.FeatureResizable
		| kha.WindowFeatures.FeatureMaximizable
)
@:app.framebuffer(
	verticalSync = true,
	samplesPerPixel = 4,
	depthBufferBits = 24,
	stencilBufferBits = 8
)
@:app.audio(allowMobileWebAudio = true)
class Main extends s.App {}

In normal projects you usually interact with App through: - @:app.* metadata to configure startup - state to react to lifecycle changes - input to access shared mouse and keyboard devices

start still exists as the low-level runtime entry point, but direct calls are mostly useful for custom bootstraps or tooling code.

App is process-wide. It should be treated as a singleton-style service layer, not as something instantiated manually.

See also:

  • kha.SystemOptions

  • kha.WindowOptions

  • kha.FramebufferOptions

  • kha.WindowMode

  • kha.WindowFeatures

Static variables

staticread onlyinput:{mouse:Mouse, keyboard:Keyboard}

Shared input devices available after startup.

This field is assigned during application initialization. Access it after start has begun setup, not at module load time.

@:value(Shutdown)staticread onlystate:AppState = Shutdown

Current application lifecycle state.

This value changes when the platform reports pause, resume, foreground, background, or shutdown transitions.

@:value(new s.shortcut.signals.Signal([]))staticread onlystateChanged:Signal<(state:AppState) ‑> Void> = new s.shortcut.signals.Signal([])

Static methods

staticexit():Void

Requests application shutdown.

Whether the request can be honored depends on platform support.

staticinlineoffFropFiles(dropFiles:String ‑> Void):Void

Removes a previously registered file drop handler.

Parameters:

dropFiles

Handler to remove.

staticoffStateChanged(slot:(state:AppState) ‑> Void):Bool

staticinlineonCopy(copy:() ‑> String):Void

Registers a copy handler.

Parameters:

copy

Called when the platform requests copy text.

staticinlineonCut(cut:() ‑> String):Void

Registers a cut handler.

Parameters:

cut

Called when the platform requests cut text.

staticinlineonCutCopyPaste(cut:() ‑> String, copy:() ‑> String, paste:String ‑> Void):Void

Registers cut, copy, and paste handlers at once.

This is the low-level clipboard registration point used by the convenience helpers above.

Parameters:

cut

Called when cut text is requested.

copy

Called when copy text is requested.

paste

Called with pasted text.

staticinlineonDropFiles(dropFiles:String ‑> Void):Void

Registers a file drop handler.

Use this when your application needs to accept files from the desktop.

Parameters:

dropFiles

Called for each dropped file path.

staticinlineonPaste(paste:String ‑> Void):Void

Registers a paste handler.

Parameters:

paste

Called with pasted text.

staticonStateChanged(slot:(state:AppState) ‑> Void):(state:AppState) ‑> Void

staticstart(options:SystemOptions, ?setup:Window ‑> Void, ?started:() ‑> Void, ?progress:Float ‑> Void, ?failed:ResourceError ‑> Void):Void

Starts the application.

This is the low-level bootstrap entry point used by the generated @:app.* startup code. It creates the Kha system, initializes the first window, loads default engine resources, compiles shaders, and only then starts the frame loop.

Most applications should prefer configuring startup declaratively through class metadata instead of calling this manually.

The setup callback is the place to configure the initial Window and build scenes attached to it when a custom bootstrap is needed.

Parameters:

options

Kha system options used to create the application.

setup

Called once for the primary window before rendering starts.

started

Called after initialization finishes and frame delivery has been registered.

progress

Called with loading progress in the 0.0..1.0 range while boot resources are loading.

failed

Called when resource loading fails.