Skip to content

Conversation

@rdw-software
Copy link
Member

@rdw-software rdw-software commented Oct 13, 2025

This is yet another experiment, aimed at removing the need to embed a full Lua VM only to speed up iteration cycles.

The feature is somewhat hacky and has a number of caveats, but in principle allows a realtime(ish)-editing workflow:

  • Start watch.cmd to automatically rebuild continuously (Future: Use OS to monitor for file system changes instead)
  • Start the Win32 runtime once and let it hot-reload the program DLL (Future: Enable snapshots/serialization/fallbacks)
  • When program code is edited, the runtime will seamlessly reload and use the updated version from a different DLL
  • A full restart is still required whenever the data layout changes, but tuning parameters should "just work" already
  • The platform runtime can't detect changes to the platform layer itself... Not sure if that's possible, or even desirable

Also works inside the debugger, though file paths/PDB references may need to be remapped. That's trivial, if annoying.


TODOs:

  • Update CI/pre-release artifacts (build artifacts have changed)
  • Pass controller/inputs to the program DLL (instead of updating the state directly)
  • Disable this feature in release builds (presumably it's enough to just load the DLL at startup)
  • Streamline the output paths to avoid having leftover garbage files when watch.cmd fails
  • Fix profiling UI display; program updates and render times are no longer separate
  • Fail gracefully instead of silently when the program DLL cannot be loaded (alert or placeholder "world" scene?)
  • Maybe store additional metadata inside the executable (program name, memory requirement, platform features?)

Not much of a point in tagging with a lot of debug info right now,.
Doesn't really fit into the platform layer, which is supposed to run multiple programs after all.
Need to use DLLs for hot reloading/to support multiple programs.
Can't base it on HW ticks (no OS API = unknown frame of reference).
These should never be called from within the program DLL and might later be moved elsewhere.
…m DLL

There may be a need to provide OS services that aren't yet covered later. For now, strictly separate them and pass HW inputs each frame.
For convenience, program code should still be able to use arena APIs.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants