1.0.59 - Fixes, features, and optimizations

New features

  • You can now live-reload paths! (path_set_live)
    They are not the most popular resource type, but people found various creative uses for them.
  • You can now live-reload included files! (file_set_live)
    This can be handy for testing game data changes, localization, or anything else.
    Inspired by a similar feature in Juju’s Dynamo (which and/or SNAP you may be interested in for other features)


  • delete keyword is now supported
    (but there is no evidence that delete keyword actually does anything special in GML)
  • Updated API definitions to GMS2022.6


  • Fixed switch blocks expecting exact value matches for integer cases, causing cases to be missed due to floating-point errors or even a negative zero.
  • Fixed sprite speeds (both asset layers and instances) no longer applying in “live” rooms due to JSON field name changes in YY format.
  • Fixed live rooms applying views after they create instances (which resulted in instances being able to poll the “original” view info for live room template).
  • Fixed room_set_live/shader_set_live not being callable in “live” code.
  • When using shader reloading, GMLive-server now looks for HLSLCompiler.exe in subdirectories too (where it had been moved in recent updates).
  • Fixed a “live” room crash when using a tile layer with no tilemap assigned.
  • Fixed “ignore” checkboxes on instances/asset layer sprites not being honored.
  • Fixed named instances in “live” rooms no longer being referable due to self no longer being a constant value.
  • Fixed effect layer colors not working in room reloader due to real(ptr(“…”)) no longer being allowed for some reason.
  • Fixed asset layer sprites being added in reverse order in room reloader.
  • Fixed creation code files not being watched for changes in room reloader.
  • Possibly a few more things that I forgot about.


This release brings a number of optimizations for common operations.

GMLive represents compiled code as an array of instructions. So, for example,

var x1 = mesh[# 0, i] - x;

would be represented as something like

0 push self
1 get field mesh
2 push constant 0
3 push local var i
4 call ds_grid_get with 3 arguments, push result
5 push self
6 get field x
7 subtract values, push result
8 set local x1

A lot of time here is spent on putting something on the stack and removing it in the next instruction.

As an improvement, I started introducing special-purpose instructions, so that instead of “push self” + “get field” you have “get field from self”, for example. Similarly, setting a local variable, incrementing a local variable, comparing a local variable to a constant, etc. are all reduced to a single instructions.

Later I noticed that function/script arguments commonly feature chains of constants, local variables, or self-variables, so I added a special instruction type that can acquire multiple such values at once and place them on stack together - so for a line like


instead of 9 instructions there are now just 2.

Most “normal” code sees a performance boost of 1.5 .. 2.5x from this while specific bits become a lot faster.

Thanks to method(), current versions of GameMaker also offer an opportunity to represent the program as a tree instead of an instruction list (so a + b becomes a function() { return a() + b() } where a and b themselves are also functions), but this is both riskier and a huge effort to support entirety of GML syntax for.

1.0.60 (hotfix)

  • Fixed unusual behaviours for a number of code structures (most notably self.array[index])

1.0.61 (hotfix)

  • Fixed unintended name prefixes for some callbacks and variables.


GMLive (for GMS2.3 and GM2022+).yymps 895 kB
Version 1.0.59 Aug 03, 2022

Get GMLive.gml

Buy Now$29.95 USD or more


Log in with itch.io to leave a comment.

Fantastic. Thank you for your continued updates. Great solution on the optimization field, 1.5x is huge!