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

1291
Issues Help Desk / Re: Installation Failure
« on: August 07, 2011, 09:43:56 PM »
I take it this is still when running from ENIGMA.exe?
If so, that's really weird. Did the compile complete successfully? As in, is there a compileEGMf.dll in the ENIGMA folder?

1292
Issues Help Desk / Re: Installation Failure
« on: August 07, 2011, 07:04:35 PM »
If I were you, I'd just rename the old MinGW and let it install a fresh one. I have no idea how or why, but it always fails to copy the files over an existing installation. I specified that it should not bail on missing files, but it seems to do so anyway.

Let me know if that works.

Cheers

1293
Issues Help Desk / Re: Compilation failure at C++ level
« on: August 07, 2011, 02:44:49 PM »
That's a catch-it-all error that happens for a number of reasons, which has increased recently due to the state of the new syntax checker. If you upload the GM6/K, one of us could take a look, or you could just paste the entire terminal scrollback so we have a better idea of what failed. Or I guess you could wait for it to be fixed when one of us finds any/all of the problems it's giving you. If it's the latest revision, it probably doesn't recognize that a function isn't implemented.

1294
General ENIGMA / Re: Stuph
« on: August 03, 2011, 01:02:31 AM »
No, it's not that hard. It just requires me picking a spot to put that function table, and generating it at compile time.

1295
General ENIGMA / Re: Stuph
« on: August 02, 2011, 09:50:10 AM »
Ah, yes, I forgot about that extension system. TGMG was working on the selector for it... I haven't heard back from him.

1296
General ENIGMA / Re: Stuph
« on: August 02, 2011, 09:47:03 AM »
HaRRiKiRi is working on paths now, actually. I gave him a hand with converting GM's 0-1 path positions to a position on a segment and ultimately to coordinates. From what I've seen, they're coming along rather well.

He's probably going to hit a snag with preallocation and getting his constructor to do reallocation, but I'll help him with that if he needs.

As for user events, I didn't realize so many people actually had use for them. I will see about implementing them; there may be some additional memory overhead or it may be completely optimized out, but it should be easy enough to do.

1297
Function Peer Review / Re: GM's Data Structures
« on: August 01, 2011, 11:28:30 AM »
Well, they're missing speed and efficiency, too. But I'm going for "working" with those functions--they're kind of unusable.

1298
Proposals / Re: Remove GLU dependency
« on: July 31, 2011, 03:12:03 PM »
I'd sooner just comment all the 3D functions for now until we finish the extensions system to accompany graphics. Fixing the two instances of GLU functions for now would be short-sighted at best.

1299
Issues Help Desk / Re: Compile Errors
« on: July 31, 2011, 12:07:10 PM »
The problem is that Debian implements a <cmath> that overloads only two abs() functions, so passing it unsigned short is somehow ambiguous. I could say a hundred nasty things about Debian, but I won't bother. The fix is to add an (int) before the parameter to abs() on line 67.

1300
General ENIGMA / Re: Stuph
« on: July 29, 2011, 11:48:58 AM »
Holy shit, it's a daz!
Anyway, yeah... *hides*
I'm working on the code editor again.

1301
General ENIGMA / Re: Stuph
« on: July 28, 2011, 02:18:15 PM »
Event_user isn't all that hard; it's just gone unimplemented because its use is uncommon. If you bother us about it enough, it'll get done.

Collision_circle isn't in just because it requires math that's more fun to do out on paper than to implement in a collision engine.

Anyway, aside from callbacks often being threaded or handled by some other system, I don't see a difference between them and the list you described. At least in C++.

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

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

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

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