Apr 05, 2019


It came to my attention that I haven't uploaded builds to itch.io for a while, so here you go.

Most importantly this gets the library to be compatible with Haxe 4 RC2 to benefit from new syntax additions and various other improvements.

Otherwise,

Externs:

  • Added fromBase64, toBase64, readInt64, writeInt64 to gml.io.Buffer externs.
  • Added normal(...), defValue to gml.gpu.VertexBuffer
  • Added gml.gpu.VertexFormat.end()
  • Renamed VertexBuffer.createExt to VertexBuffer.alloc for consistency with haxe.io.Bytes
  • Added some more GMS2 layer function externs.
  • Added gml.NativeType for all those is_X functions.
  • Added gml.input.Window.x/y
  • Fixed a few weird bits with gml.net.* classes

Improvements:

  • You can now have a .gmx.base/.yy.base next to target extension and that will be used if the extension file is missing.
  • This makes it easier to gitignore Haxe-generated extensions without having to manually set them up after pulling for the first time.
  • obj.field = function(...) {...} will now name the auto-generated script as per field name.
  • @:snakeCase can now apply to ds_map typedefs.
  • You can now selectively override whether to use ternary operators/array_create(...)/array literals
  • GML repeat-loops are now utilized in more cases (so long as the iterator variable is irrelevant, basically)
  • Added -D sfgml-hint-var-types, which will include GMEdit-compliant hints of what types local variables are
  • \r\n linebreak are now used for GMS2 extension generation, but GMS2 will probably still re-edit your extension later.

Fixes:

  • Fixed array helper functions not obeying std-prefix.
  • Fixed gml.ds.Queue missing a package.
  • Fixed a compiler crash if a class field is initialized to a bitwise operation.
  • Fixed a compatibility issue with new versions of GMS2 due to initializer in for-loops no longer being allowed to be anything but a variable declaration/assignment
  • Fixed @:doc from class not automatically applying to static fields.
  • Fixed function-typed (but non-method) class fields being called with a "this" argument even though you didn't ask for that.
  • Auto-generated local functions no longer show up when @:doc-ing the containing class.
  • It is now allowed to do function some(req:Int, ?rest:SfRest<String>) (so that you don't have to give it a fake array from Haxe calls)
  • Fixed some setups of enum value index retrieval on a fake enum compiling as "v[0]" instead of "v"
  • Fixed GmlGenAssets failing to use auto-completion cache if one of your resources has a >256-character long name
  • Code generator now prefers `++i;` over `i++;` because this was a thing for a while.

Files

sfgml.zip 393 kB
Version Apr 5, 2019 Apr 05, 2019

Comments

Log in with itch.io to leave a comment.

(1 edit)

Thanks for the release, this is incredible.

Could you please explain what these directives do? Also, any specific reason the target file in the doc example is a .gmx file, and not a .gml script?

sfgml-spaces sfgml-hex

Also, I've noticed that, by default, the helper scripts try to pass 2 arguments into array_create, which has issues compiling with GMS1. They work fine by just removing the second argument, though (it was 0).

sfgml_spaces forces indentation using 4 spaces instead of tab characters. This is somewhat important when generating scripts for GMS1 because GMS1 is allergic to tabs and will remove all of them whenever it updates the script.

sfgml_hex (nowadays, sf_hint_const) will attempt to increase readability of magic numbers where available - for example, if your Haxe code had "0x10", it'll try to make GML code use "0x10" or "$10" as well.

Good reasons to target extension files instead of scripts are:

  • Allows Haxe define macros properly (instead of having to resort to enums for constants, and nothing at all for getters)
  • Allows to bypass IDE-specific issues (e.g. GMS1 compiler in >=1773 knows that array_create can have two arguments, but IDE doesn't, so you can't use that if it's in a script)

Sorry for my ignorance, but what "define macros properly" mean here? I thought GMS1 only allowed you to put macros in a special file, not in-line.

Also, is there any way to automatically generate the function calls for extension? It seems you have to manually add them to the GMS1 IDE before being able to actually call Haxe. Any way around this?

Also, after compiling, I've copied the code inside the .gmx_ file and put it inside the extension's .gml file, is that correct?

Extensions can define macros (named "constants" in the UI) and these work akin to how ones defined in the project do.

If you target an extension ( some.extension.gmx._ ), it will be auto-populated, but you might need to reload the project in GM the first time this happens. You should not have to manually copy anything.

I see, thanks for clarification.

I'm attempting to use this to build the project:

haxe -debug -lib sfhx -lib sfgml -cp src -js ../extensions/Haxe.extension.gmx_ -main Class -dce full -D sfgml-assets-path=../my_project.project.gmx -D sfgml_snake_case -D sf_pretty -D sfgml_local=_

This generates a Haxe.extension.gmx_ file which contains the generated GML code. The original .gmx file remains untouched, and so does the blank script you need to create when setting it up. Is that expected?

I've checked the files with external editors to be sure the IDE wasn't just failing to load changes.
Also, sorry for asking for support here, is there a better/preferable channel?

Please direct your attention to the dot between "gmx" and the underscore afterwards - that's what indicates to modify the extension file. "some.extension.gmx._", not "some.extension.gmx_"

Ideally you'd ask on either itch community or GitHub issues so that other people can find your question later if they have a similar one