Overdue Update

[Josh @ Dreamland]

All right, with nearly a hundred revisions since our last newspost (which was quite small), Polygone recommended that I make a new one. So here it is.

What's been done?
I implemented some of GM's syntax quirks. Assignment = to comparison ==, mostly, along with about 10 bug fixes for bugs discovered in TGMG's mass compilation sprees.

As part of this, I gutted the syntax checker, which was written before we had genuine intention of supporting C++ macros. Yeah, pretty ancient. The new one is in its early childhood (meaning half of it is written).

switch() has been implemented at the repeated request of kkg; at the moment, you can switch() anything that can be stored in "variant". Down the road, you'll be able to switch anything for which there is a switch_hash() overload. As you may have gathered from that previous statement, ENIGMA's switch() is hashed, unlike Game Maker's. This introduces an incompatibility: Putting the default: label first doesn't fuck everything over. <_< Other than that, you'll find that the only incompatibility is the massive increase in performance.

Polygone and HaRRiKiRi have been hard at work implementing functions and DND actions. Polygone, as practice while learning C++, has supplied an implementation of all data structure functions (ds_*), except ds_*_read/write() and ds_set_precision, "whatever the fuck that shit is." He also went on a DND-implementing spree; more trivial, but probably more likely to be noticed (it's surprising how many people fuss about really simple DND tiles missing, just because they threw them in random places).
As for HaRRi, he would like to just point out that C++ sucks, but that he has nonetheless (In addition, of course, to the huge number of font functions he has implemented) been working on an implementation of paths. For which, apparently, IsmAvatar has coded a writer to the EXE. You can expect to be seeing those sometime "in the next 42 years," even if I have to move them somewhere afterward.

Specifically, I would move them into the extensions directory. I spent a little bit establishing a modular system for incorporating underused variables and functions which will allow users to choose which ones they need, disabling the rest which would otherwise just be wasting memory and filesize. I have already moved alarm functions there (including action_set_alarm). With a little luck, Ism will hook that system up formally before I die of old age.

TGMG has been hard at work doing minor tweaks and function implementation to up compatibility further as well. He even wrote a quick, crude implementation of tiles (Don't worry; they're probably still faster than Game Maker's). I'll be replacing his present tile storage and drawing methods with more efficient ones down the road. Specifically, precompiled ones--there's no getting faster, assuming the ratio of fill to vertices is good (which it should be). We collaborated for a while to get some more GM quirks working, and actually made really good progress.

What does this mean for the state of the project?

Presently, our GM compatibility standings are as follows: 81 percent of GM examples harvested from 64Digits compile in ENIGMA when given fillers for missing functions. That means that the system is sound enough to manage all the dynamics of GML provided only that a few more functions are implemented in the backend. Why do nearly 20% fail? "Unforseen circumstances." Namely, they fail where GM's own syntax checker failed.

For example, take these codes:

Code: (GML) [Select]

for (;;;;;i = 0;;;; i < 10;; ;; ; ;i += 1;;; ) {}
// Game Maker doesn't care about semicolons in for(;;), so people got in the habit of doing this:
for (i = 0; i < 10; i += 1;) {}
// It's still wrong, but GM supports it.

if not_a_function
  (100001).variable = true; // GM was okay with this, because instance_nearest(x,y,object0).x would cause a runtime error.

That's right,  instance_nearest(x,y,object0).x would cause a runtime error. Not a syntax error. GM's parser was so poor, it didn't know what to make of that code either. So it did it wrong, and people took advantage of that. But now ENIGMA's left with around 200 games that do that sort of shit. Not necessarily just those two; those two are just common ones that stuck with me. I have a whole laundry list of stupid shit like that to deal with.

As for the project's embrace for C++, with the syntax checker finally supporting macros, it's looking healthier than ever. I may soon add support for full-blown preprocessors.

Anyway, wish us luck. And enjoy the changes.

[Rusky]

Remind me again why the syntax checker is an entirely separate program?

Also I may still have ds_*_read/write floating around somewhere if Polygone wants.

[Josh @ Dreamland]

Mostly so it can be invoked without any of the rest of the DLL.
You'll find GM's does the same thing. Not that doing anything like GM is usually a good idea.

It's also the reason GM could generate lex errors at load time that it couldn't detect during the syntax check, but in ENIGMA's case, that's going to surface as an issue from trying to convert to C++, in any case.

The parser doesn't do any error checking; it just sticks semicolons between things.

[polygone]

Yeah I will grab those Rusky if you still have them.

[RetroX]

Question: Would it be possible, at some point, to have a command-line compiler for GMKs, or for ENIGMA projects (whenever that we get our own format)?

Or rather, would it be possible to at least invoke LGM via command-line to do this?  All of the code's already there; even if it requires a graphical environment, it's still nice to be able to batch-compile things.

[Josh @ Dreamland]

There already is one, RetroX... TGMG's been using it to mass-test examples.

Post made July 26, 2011, 06:54:42 am was deleted at the author's request.

[Rusky]

I seem to have lost the ds_*_read/write source. I was going to post the format they used, but I can't find that either. In case I don't/until I find something more useful, I will say that GM uses strings of two-digit hex numbers using some of the same conventions as gmks (e.g. little-endian 4-byte integers, a length followed by several structures). If you're interested in making it match GM for mostly-non-existent compatibility reasons you could start from there and try to re-reverse engineer it.

[IsmAvatar]

Remind me again why the syntax checker is an entirely separate program?

So you don't have to sit there for 30 seconds while the whole program compiles your code just to report why your code is broken.

Question: Would it be possible, at some point, to have a command-line compiler for GMKs, or for ENIGMA projects (whenever that we get our own format)?

Or rather, would it be possible to at least invoke LGM via command-line to do this?  All of the code's already there; even if it requires a graphical environment, it's still nice to be able to batch-compile things.

Aha. I was always wondering how the fudge he managed to do it. Cheater.

Not sure if I'd really call him a cheater. The CLI is already included with any semi-recent revision of ENIGMA's trunk, courtesy of yours truly. Simply invoke `java -jar plugins/enigma.jar <gmfilehere.gm6/gmk/gmd/gm81>` from the enigma-dev/trunk directory. I just don't advertise it heavily because 1) It's java, and 2) it's still lacking in a lot of places, such as not being able to specify which API systems to use.

Post made July 27, 2011, 06:12:38 am was deleted at the author's request.

[IsmAvatar]

It's been on the wiki since May 22nd: http://enigma-dev.org/docs/Wiki/Command_line_interface

Post made July 27, 2011, 03:14:45 pm was deleted at the author's request.

[Rusky]

Remind me again why the syntax checker is an entirely separate program?

So you don't have to sit there for 30 seconds while the whole program compiles your code just to report why your code is broken.

It is possible to use the same code to check the syntax as to parse it, without compiling the program every time. It's also more useful, because then the syntax highlighter, auto-complete, and other code manipulation tools can use the information as well.

Oh wait- Enigma doesn't actually parse EDL, so you have to maintain a whole collection of programs that all do pretty much the same thing.

[Josh @ Dreamland]

Actually, I gave this new checker a structure-based lex because it's too difficult to do lookaheads inside a macro-flooded system without one. The token structure only stores the position of the token and its type.

But I free the lex after the check because it's too detailed for the parser's minimalistic uses and I don't presently do formatting or highlighting myself. Besides, the syntax highlighter is Java side, and I doubt IsmAvatar favors the idea of making that aspect of LGM so modular as to be able to make calls through JNA.