Rewriting Everything! | Ed-Engine Devlog #10

Tech/product summary (Ed-Engine Devlog #10)

1) TypeScript migration plan + build system changes

• Motivation: Avoid the “unknown types / mystery objects / cross-referencing files” pain after learning TypeScript via a small Snake game, and prevent the codebase from feeling stuck in a “pre-TypeScript” era.
• Trigger for the migration: A failed v2 → v3 automatic upgrade broke the ability to run the v2 project due to npm/tooling issues, forcing a manual upgrade of the whole codebase.
• Migration technique:
  • Mostly mechanical changes: add TypeScript annotations (e.g., adding function, return types, and : void where needed).
  • Done in parallel with fixing core engine issues—especially a “spatial collection class” that became workable after significant debugging.
• Rendering/build integration:
  • Development: uses direct imports to preserve TypeScript syntax highlighting and enable fast iteration.
  • Deployment: replaces imports with a bundled JavaScript version of the engine.
  • Consolidates the engine’s internal library into a single bundle (“core”) to simplify build setup.
• Vector utilities:
  • The previous “Victor JS Library” for vectors didn’t support TypeScript well, so a custom vector implementation was written for cleaner builds.

2) Performance check after the upgrade

• After converting to v3, frame times in a small test level were “pretty bad.”
• Direct comparison to v2 performance isn’t possible anymore.
• Target: 60 FPS across a wide range of hardware, including a Chromebook.
• Observation: UI/text rendering (e.g., drawing text boxes) is a major slowdown.
• Any frame time above ~16 ms is considered unacceptable for the target.

3) Considering WebGL to regain/extend performance headroom

• Idea: Upgrade path—move from Canvas to WebGL without immediately rewriting everything before Beta.
• Benchmark approach:
  • Create a small web page simulating Atlas sprite drawing using both Canvas and WebGL.
  • Expected ~7–10 ms improvement (later found to be wrong).
• Result:
  • WebGL rendered sprites in sub-millisecond speeds, implying substantial headroom.
  • This also suggests the current rendering “jankiness” can likely be reduced.

4) Proposed rendering architecture for the WebGL version (engine + editors)

• Goal: Replace an old “weird layering system.”

New editor drawing model

• Use a single-plane canvas rendering approach.
• For the art editor: one draw call using:
  • World-space coordinates for the background checkerboard
  • UV coordinates for sprites and the grid

Room editor architecture split

1. Instance renderer
   • Render many objects as instances of a plane in one draw call.
   • Includes planned instance layers:
     • Sprites
     • High-res icons
   • Reuse plan: if moved into engine core, both editors and engine renderers can share the same code, reducing duplicated renderer code.
2. UI renderer
   • Draw grid, mouse cursor, etc.

Grid refactor

• Current infinite grid is described as long/messy due to CPU-side line wrapping.
• WebGL version uses shader code for a clean infinite grid implementation.

Camera/matrices refactor

• WebGL needs matrices, so viewport navigation will be converted to output matrices rather than custom transform code.
• Uses custom 3x3 matrix math (no general-purpose matrix library), aiming for simplicity/performance via loop unrolling/inlining.

5) Atlas rendering + capacity and correctness

• Atlas rendering is the most complex part.
• Each atlas supports up to 4096 unique sprite frames (via instanced reuse).
• If limits are exceeded:
  • The system automatically creates a new atlas and switches seamlessly between atlases.

6) UX/workflow improvements in the editors

Asset placement workflow

• Current pain: cumbersome flow Sprite → Object → place it.
• Planned solution: make every asset type directly placeable in the level editor.
• Consequence: property panels will switch based on the selected tool rather than strict selected object type.

Camera improvements

• Added a “smart camera” option for a more modern feel.

Overlapping instances selection

• Old behavior: repeatedly click the grid cell to cycle through instances (clunky).
• New behavior: Blender-like alt-click approach:
  • Double-click opens a menu listing instances in that cell.

Node editor UI overhaul

• Moved from a strict two-tab layout to multiple tabs per node category.
• Each category includes an icon + color, reused on nodes for readability.
• Added a small back animation when adding instances.

7) Space Invaders as the “node system” stress test

• The game being built is Space Invaders.
• Node features required:
  • Mouse events, collision events, spawning nodes
  • Constant-velocity node
  • Node to read instance details
  • Messaging/broadcast system (event-like)
  • Timers and raycasting
  • Miscellaneous small nodes
• Node API takeaway:
  • The node API design “surprisingly just works,” especially with many nodes.

Timers + messaging issue

• The same node tree runs for all objects that share it.
• Async triggers (timers/messages) can fire after execution context changes, causing “weird issues.”
• Fix:
  • Remove the async event system
  • Update nodes to rely on:
    • their own internal data
    • the recursive nature of the node tree to schedule follow-up work after the rest executes.

8) Collision system upgrade: Minkowski difference + sliding + a major algorithm breakthrough

• Current movement model is discrete/jumpy:
  • Works for maze/tiled movement
  • Not suitable for smooth movement
• New requirements:
  • Prevent fast objects from tunneling through walls
  • Compute intersection along a path mathematically instead of “move then test each frame”

Approach: Minkowski difference

• Expand other objects’ collision boxes by half the moving object’s width/height.
• Convert box-on-box motion into line intersection testing against expanded boxes.

Sliding/clunk fix

• Old behavior: objects stick on collision.
• Needed: slide along surfaces at angles.
• Plan: compute collision surface normals.

TF2 math nerd breakthrough (SDF-like vector field experiment)

• Replacing edge iteration with a vector field representation (SDF-inspired):
  • Instead of returning scalar distance, return a vector offset to the nearest collision point based on current velocity.
• Implementation pipeline:
  • Run collision logic over image pixels to generate expected field output
  • Debug by inspecting relationships between image channels (red/green) and velocity
  • Mask unreachable regions (values that can never collide)
  • Validate using existing box SDF behavior:
    • add the computed offset back to the original point
    • use SDF inclusion testing
• Result:
  • Matches the original algorithm pixel-perfect
  • “Ludicrously faster”
• Benefits gained:
  • Automatic bounce-back if an object overshoots edges
  • Normals become easier to derive
  • Enables a new slide option in the velocity node:
    • On collision, adjust direction and re-run collision checking
    • Since boxes are axis-aligned, subsequent collisions simplify to right-angle cases, limiting sequential collisions to at most two

9) Debugging support

• Added a rudimentary debugging window for testing collision/rendering/game behavior (rough for now, with future improvement ideas).

---

Main speakers/sources

• The video appears driven by the developer of Ed-Engine / Ed (first-person narration: “I,” “we,” “Ed’s devlog”), i.e., the project author.
• No other named external speakers are present in the subtitles.