Proposal: Redesign InputSystem to Support Events and Pulling Queries

[miogds]

While working on the editor splitting branch, I encountered several issues related to abstracting the input system for separation between game mode and editor mode.

Currently, the input handling across the engine is fragmented:

• Camera movement, entity selection, object rotation, etc. rely on different structures and ad-hoc logic.
• Input is often accessed, modified, and queried in inconsistent ways.
• Platform-specific differences (mouse, keyboard, controller, hand tracking, etc.) complicate the system further.

This raises the need for a more unified and extensible InputSystem that can support both event-driven and polling-based access patterns.

---

Proposed Redesign

1. Two Access Models

The InputSystem should support two complementary modes of access:

1. Event-driven (OS → Engine events):

   • Collect all raw events (mouse, keyboard, controller, hand tracking, etc.) from the operating system.
   • Store them as snapshot events in a circular buffer (FIFO stack with size limit).
   • Each snapshot can include OS state, gestures, notifications, and callbacks.
   • Heavy processing (math, gesture recognition, background tasks) can occur here, without blocking the render loop.

2. Polling (Engine frame loop):

   • On each render frame, the engine should be able to pull the latest input state (fast, minimal computation).
   • This ensures that frame-sensitive operations (e.g., camera controls) are efficient and predictable.
   • Polling must remain lightweight, as it runs every frame and directly impacts frame rate stability.

---

2. Decoupling Input Capture & Consumption

We can think of this as a two-step pipeline:

• Input Capture Layer (slow path):
  • Receives and processes OS-level events.
  • Buffers input states, runs computations, and prepares results.
• Input Consumption Layer (fast path):
  • Used by the renderer and game/editor logic during frame updates.
  • Pops or queries preprocessed snapshots with minimal overhead.

This decoupling allows us to:

• Handle platform-specific quirks in one place.
• Avoid blocking rendering with expensive input operations.
• Maintain deterministic behavior on platforms like Apple Vision Pro, which enforce fixed frame rate timing.

---

3. Benefits

• Consistency: Unified input model across editor and game mode.
• Performance: Heavy processing stays off the render loop.
• Flexibility: Supports both callbacks and frame-based polling.
• Extensibility: Easy to add new input devices (VR/AR, hand tracking, etc.) without rewriting core systems.

---

What do you think?

[untoldengine]

Thanks for putting this proposal together—it’s a really solid direction. I especially like the capture vs. consumption split you outlined, since it directly addresses a lot of the current pain points: fragmented input logic, editor/game overlap, and heavy work happening inside event callbacks.

I’m on board with moving forward, and I think we can build on your idea in a couple of ways:

1. Action/Context layer on top of your design.
   Alongside the capture/consumption pipeline, we could introduce:

• Actions: map raw inputs (keys, mouse, gestures, controllers) into semantic actions like moveForward, select, or gizmoTranslate.

• Contexts: group these actions and assign priorities. For example, an Editor context could override a Game context when the editor is active. That way, we don’t have to scatter if editorEnabled checks in the code—the system decides which context wins.

  This isn’t something you mentioned, but it feels like a natural extension of your proposal and would make switching between editor and game modes much cleaner. Curious what you think.

2. Keep callbacks lightweight.
   I agree with your point about performance. Event handlers should mostly normalize state into the builder, and then heavier tasks (like raycasts or gizmo actions) can run later in the frame update, driven by the snapshot.

Overall, I think your proposal gives us the right foundation for the engine.

Thanks

[miogds]

I agree.

I will draft an implementation proposal so we can agree on the direction. Also I want to introduce event routing so we can direct or subscribe to different events to different views.