Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Josh @ Dreamland

1306
Announcements / Re: Overdue Update
« on: July 27, 2011, 05:20:47 PM »
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.

1307
Announcements / Re: Overdue Update
« on: July 26, 2011, 01:04:32 AM »
There already is one, RetroX... TGMG's been using it to mass-test examples.

1308
Announcements / Re: Overdue Update
« on: July 25, 2011, 01:21:06 PM »
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.

1309
Announcements / Overdue Update
« on: July 25, 2011, 11:04:21 AM »
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.

1310
Issues Help Desk / Re: Failure to start Enigma from SVN on Ubuntu
« on: July 14, 2011, 09:55:23 AM »
I forgot how long ago I made that fix. There's a possibility something else broke it in the meantime. Anyway, it's part of my testing suite now, so it's unlikely to go unnoticed if it breaks again.

1311
Issues Help Desk / Re: Hai halp me 2 fix mah gml plox.
« on: July 12, 2011, 03:53:38 PM »
[Warning: viewing the above game may cause cerebral infarction. View at your own risk.]

1312
General ENIGMA / Re: Questions on EDL and ENIGMA
« on: July 11, 2011, 08:42:47 PM »
I'll remove the parser for you after I finish pasting the audio system back on right-side-up.

1313
General ENIGMA / Re: Questions on EDL and ENIGMA
« on: July 11, 2011, 03:50:31 PM »
Using a PE header that I would normally not hesitate to strip? ...

Anyway, if that's the case, it seems you don't even need any cooperation on my part to get the engine hooked up to your fork. Even our definitions resource would work well with it.

Although I'm not seeing how LLVM would discern the contents of a C structure without being told.

1314
Issues Help Desk / Re: Failure to start Enigma from SVN on Ubuntu
« on: July 11, 2011, 02:18:26 PM »
How are you running the Jar? Last I checked, Ubuntu doesn't run jarfiles from within their own directories; you may want to try opening the terminal in that dir and invoking Java yourself.

1315
General ENIGMA / Re: Questions on EDL and ENIGMA
« on: July 11, 2011, 12:24:15 PM »
I don't much fancy the concept of making anything impossible in the language. I also don't fancy bounds checking. So if there's going to be any anti-segfault measure on this, it's going to be one that pulls a glibc and catches signals to inform the user of what blew up where, instead of preventing the explosion.

So, then, the engine and game codes would be separate. I suppose you want them dynamically linked, with the engine as the DLL. Or, knowing you, you want every piece of the engine as the DLL, and then some sort of go-between to be generated that lays out the functions, yes?

I have dedicated the last five minutes to thinking of the implications of using LLVM for the game and C++ for the engine. We'd miss out on structures for communicating between the C++ functions and the LLVM ones. There'd be a major segregation between the two. Getting arbitrary C functions defined to LLVM would be difficult and likely inconsistent.

1316
General ENIGMA / Re: Questions on EDL and ENIGMA
« on: July 11, 2011, 12:00:47 PM »
The reason G++ is incapable of performing optimizations on var is because it does not recognize it as a plain datatype. The same optimizations cannot be made for variant as for double, because it doesn't understand to treat the class as a plain datatype. Implementing it in LLVM would fix that. Otherwise I'd have to do it myself.

As far as having C++ features without being tied to C++, I don't actually have a retort to that, even if you're trying to pass that off as a benefit.

I also like how you just pretend that C++ is this horribly unstable language while LLVM is the pinnacle of perfection. It reminds me of 4chan threads.

Let me ask; what would the engine be written in when we switched to LLVM? You're apparently implying it's not that bad, old C++.

1317
General ENIGMA / Re: Questions on EDL and ENIGMA
« on: July 11, 2011, 10:05:11 AM »
You're always welcome to fork the project. Maybe the two of you could team up and work on an LLVM version.
Of course, we'd probably have to sacrifice our C++ features, or at very least the lexical optimization that would otherwise come with LLVM. And to utilize the full extent of those optimizations, we'd need to hard-code rules about var into our grammar as though it were a formal, POD type; how much code would we be discarding here, do you suppose?

Maybe you can implement this optimization I've been contemplating for a while using the current, compiler-independent configuration; I'd like to inline calls to small graphics functions such as draw_line and draw_point, and remove the if() for recurring calls to them. If you can get it to inline them, LLVM should be able to do this itself.

1318
How on earth does valign have any effect on draw_text? O_o
If it just centers the text around the given y coordinate, then there's no need to fork again. Just set the initial yy to valign == fa_top ? y : valign == fa_middle ? y - string_height(str)/2 : y - string_height(str).

And yeah, it's "though." But no one really cares if you abbreviate, even unintentionally. :P

1319
Yep. That way, string_width is never called for simple left-aligned text.

1320
Quote
Could you elaborate? You mean having separate drawing functions for all six alignments? Then how will that be backwards compatible with GM? Or how will draw_set_halign/valign actually work in that case?
No, just put the original function in a big if for align being top-left, and then put the rest of the code in the else with whatever hackery is required, that way you don't have to iterate the string for draw_text() when the aligns are default.

Quote
Also, why do I need this: ...
Otherwise, \r\n will put two newlines, or if you place ", u+= str[i]=='\n';" at the end of the proposed replacement, '\n\n' will be treated as one line.