ENIGMA Development Environment

Your assumptions are for the most part correct. I have not yet implemented a type for instances. I'm thinking it'll be of form typedef something instance_t, but have not yet decided.

Also, doesn't support rotation and scaling, yes? The math for that is out of my league due to current sleep levels. Perhaps I'll add it tomorrow...

Heh, logical structure in Enigma.

What was wrong with getting a C dll to call java functions? I found JNI quite pleasant to use for this.

I figured that I'd acknowledge that this sounded nice. I don't know much Java though, so all of this is news to me, really. Maybe that will help Ism?

Plus I got my macbook so would love to start on mac port whenever your ready Wouldn't mind looking into adding gml functions aswell if that would be ok

Sounds great. I'm probably not going to be happy with the documentation until I've got the entire system actually working like I say it should (meaning I want LGM-ENIGMA communication done first), but integrating it should be so simple that really you could just start by creating an empty window and GL context in a separate project, then copy over the code when you're done. There are a few function names the rest of the engine relies on; the beauty is that most of them are the GML ones, so as long as you have a header that defines those, it should integrate simply by copying over some files and possibly moving the important parts of main to an initialize function for which I have not yet settled on a name.

My current two systems, XLib and WinAPI, just leave a header to include. I haven't yet decided if that's an idea worth keeping, but will make that decision once it compiles for a system and I can start making sure my changes don't break anything.

As for input, I just keep an array of keys, but really it's up to you if you intend to implement keyboard_check and the like.

So yeah, if you like, just get a Mac copy of the OpenGL rotating-triangle example and do your best to get input functions working, and any window_ functions you can.

Thanks again.

Boy metaphase is taking a long time (For those who are expecting it, hehe).

Anyway, another tidbit worth noting: "Local" typing, as in, "local struct a;" will be possible only if users ensure that said typing is done in the first event parsed. The create event is a safe bet.

Types are remarkable in that they cannot be assumed; that's why I needed a C parser in the first place.

So, I can do "local struct," which wasn't part of the original plan, but it's not going to be as convenient as "local int" or the like, simply because I can't treat something as a type before I know for sure that it is.



I've started documenting the systems that those implementing new libraries will need an understanding of. Aragon has been working on Wii things and has agreed to get started on some draw functions for ENIGMA. What's interesting is that he wanted to get started right away, so he checked out the SVN and started looking through it without docs. ;_;

What's even more interesting is that he commented on how well-organized it was, which is indeed what I was going for, but I didn't think anyone would just figure the whole thing out without bitching about documentation. Makes me wonder why I'm writing it sometimes.

Also, retep998 has volunteered to help with the collisions. I hope the undertaking will go a little more smoothly with more people on them than just me. He'll be starting that when R4 enters a stable test phase.



Ism and I talked for a bit, and now she is working on a set of classes in C and in Java that will allow the two to share resources. Getting a C DLL to call Java functions isn't going to happen, but I can probably communicate some simple instructions by returning an array of them.

Also, we used to use std-out to communicate from ENIGMA to LGM, such as info about what was taking place in the compiler. Well, now we can't, so hopefully we can create a reliable new mechanism for this. (It's a shame, too; she spent a fair deal of time threading that damn output window, and now it's useless...)

On the bright side, though we were originally afraid we'd have to add something to the path folder, we've found workarounds for that, too.



My current difficulty is figuring out a way to simplify installing a compiler for users. Problem is, Vista is incompatible with a release of MinGW for XP and the like, and I hate to think about Win7. The MinGW team has their own automated installer that downloads the correct version; maybe we can use that. The only problem that creates is locating the compiler after it installs it.... It doesn't add anything to the path variable, and the typical GM user doesn't even know what that means. ;_;

Suggestions/comments welcome. Criticism will be bashed thoroughly and considered later.

Yeah. I believe with() is Delphi, but I'm not certain. It'd make sense if it was. You can see it in JavaScript as well.

Posted about having to write an essay elsewhere. I'm nearly done.
Ism's getting Java to pass resources to DLLs and the like.

I'll be essaying for the next day and a half or so.

Didn't think it was worth a news post.

Ism got DLL's working in Java. She's now looking in to how resources can be passed via function calls. Shouldn't be hard to get ENIGMA DLL-ized from there.

@miky
Oh, you're right. I should just include the GCC with it like you first said; wouldn't want to risk the project looking "stupid" to someone.

Also, I'd really like to see an English->French translator hard coded over the two languages' twelve similarities.

@The 11th plague of Egypt
It's actually probable that the majority of users will try their best to avoid LGM, doing major development in Game Maker then bitching when they've used something ENIGMA doesn't support yet a month later when they're ready to compile.

"Also, breaking one of the most idiotic features of GML in order to save one of the smartest features of C++ seems a good trade to me."
Now this, I like.

Directly converting GML to C++ is impossible. They should not expect it.

IMHO we are just trying to make C++ and GML live togheter.

Call me a philosopher, but I'm not sure what you mean by "impossible" or "directly converting." ENIGMA's purpose is to convert GML to C++. I started the project because I noticed enough similarities in syntax that doing so would be relatively easy, in fact. Some things will obviously never work in plain C++, the first of those being with() {}.

@miky as well: Including a C++ compiler is certainly unnecessary for implementing execute_string() for backwards compatibility with GM, and is not really necessary for interpreting most C++ features, either. Yes, there are projects that can interpret C++, but I'm reasonably certain such projects are bloody massive. A smaller alternative is to do a bit more parsing and pass strings to Google V8 (A damn nice JavaScript JIT compiler). With V8, I can link in globals at runtime, and write a variable accessor class called Cthis, which will be appended before all locals (or all variables in general). So, the user's code will be for example, x = 0; y = 0;. It'll be passed to V8 as Cthis.x = 0; Cthis.y = 0;. V8 will call Cthis's accessor for "x," which is a C++ function I register. It'll behave just like GM's interpreter, only, sad as it may be, probably faster. The work for me would be so small as to be laughable.

a = 0;
var a;
a = 3;

Would work just like GM, because after they declare var, I just remove it and stop adding Cthis before the variable. This can be done entirely linearly, and without buffer resize as I can just space out "var" (as in, replace it with "   ").

The only things that may require a new buffer is adding semicolons to the code, which isn't always necessary in JavaScript, either; only when no newline is given. Hell, I might even be able to edit V8 to not require newline either, if I really wanted. Though, that's quite unlikely.

Did I mention it's JIT compiled?


As for scripts returning the value of the last-called script... Heh, that's kind of neat, I was unaware it did that; that's usually a behavior defined in interpreted language. I can't replicate that, as far as I know, simply by not providing a return value in lieu of the user's... I could if the last reference were left in EAX, which is unlikely.

I don't think I'll be replicating any useless GM bugs.