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)

Improvements

• 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

Fixes

• 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.

Optimizations

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

draw_surface_ext(_surf,_x,_y,2,2,0,c_white,1);

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.