ENIGMA Development Environment

As you can plainly see, the interests of this community have changed from software and game development to unicorns. As such, the ENIGMA project has been discontinued, effective immediately. For the third year in a row.

Okay, enough of that now. On to serious matters.

Upon further consideration, it has appeared to me that C++ just isn't right for ENIGMA; despite my best efforts, I don't think I can pull off all the things Game Maker does without a better system. Specifically, one with such goodies as dependent typing and a good garbage collector, so users can use ds_list_create and just forget they did so without worry, and so late at night when it's hard to keep track of what I'm doing, I'll be fine. I won't have to fear that I've made a mistake in my coding; something else will let me know or just take care of it for me. We all want that, right? Switching to a better language could definitely improve development speed, in that respect.

Besides, it's time to give the project's organization some serious rethinking. POD has become, though efficient, too confusing when looking at the bigger picture: we're better off calling things by reference. Doing so makes sense, and will help the garbage collector and any debugging implementations as well.

I was looking at C# or Java, maybe even with some Haskell. All of those languages are gaining popularity quite quickly; chances are they'll work on all the platforms we want ENIGMA to compile for within the next ten years. Those languages don't each offer all of the features I mentioned above, but they'll make mine and users' lives easier.

Think about it:  With their garbage collectors and referencing systems working for us, you can just create a ds_list, forget about it, and in a few steps, it'll just be gone! To ensure that users don't accidentally reuse a destroyed list, the integer-id (probably between 0 and 20) will cease to exist along with it, meaning you can no longer set any variables to it. So, if you said, for example:

a = ds_list_create();
ds_list_...

But then just stopped using "a"'s list for a while (like if you had it in an alarm that was taking a really long time to execute and so probably never would), list 1 would be freed. So what would happen if you were to pass "1" to ds_list_find again? That's the beauty: You can't! When list "1" is freed, so is the constant "1" from the game. That means that from now on, you can't use "1" anywhere in your code, and ENIGMA will make sure that you don't accidentally add anything to obtain "1". Also, make sure not to divide by it, as doing so may cause an error (don't worry though, each of these languages has great exception handling).

This can be accomplished by keeping everything stored as pointers, especially constants. Instead of "1" just being an integer in memory, it will be an integer pointing to an integer, and then another integer to verify that our integer points to an integer. Simple, yes? Efficient, too: modern processors are making it so no one will even notice the effects of doing so.

I haven't seen any Java games for Wii, yet, but maybe they could be played through the Wii's browser. On the other hand, I have seen one C# program for the Wii, and I'm sure it has reached shelves of hard-core gaming fanatics everywhere; just look at it. Although I don't think development with C# for non-Windows systems will be supported by Microsoft, they have agreed not to sue for it.

Because of that, C# is looking like a really good option. Plus, using C# would give us access to Microsoft's powerful .NET framework on Windows, which end users would simply have to download. It's only a few hundred megabytes. The Mono team has been working very hard to get that framework running on other operating systems, too; it should be mostly supported.

I can't wait to hear your comments on this. I feel we'll need a new logo to go along with it, possible something with gears and happy faces.

XOXOXOXO
<3<3<3
something about unicorns

Ism is presently dealing with "real-life" things. She'll be around; hopefully enough so to wrap this up quickly.

I've implemented the tier system, reducing the compile time to about four seconds on this computer, which apparently is about average in comparison to some of other ENIGMA members' computers, assuming those are what you'd call "good". Basically, it's what you'd get out of a GM game, except the compile's a one-time deal and accounts for 95% of the time at least.

So yeah, ENIGMA's up to speed. Much better than R3's 30 second compile jobs.

Eh...
ENIGMA is a DLL now. The ENIGMA plug-in fails to pass it the resources, though, due to some major JNA failure. Ism has successfully segfaulted Java on multiple occasions today.

I'm not sure what I will do tomorrow, other than go to school, which will be weird since it's Spring Break for high school but not college. I'll try to get something in this household running Linux again and make sure the engine works for it, too. Oh, by the way, I'm making sure that the new tiering system comes with even better organization than in the repo. It's going to be a fun time committing all these moves and deletes. -.-"

I prepared a small todo list of revisions for the engine. Really, I need Ism to get JNA working so I can test the damn compiler part already. >_<

If anyone has the patients of a saint and the Java skills of, er,... a patient gopher, I could use a hand.

Ciao for now; going to do any homework I may still be putting off.

Serp remarks that GM is unsuitable for collaboration due to resources all being in one file.

I think a nice fix for this would be to store a time of creation (milliseconds-since-Jan-1970 style) as well as a time of last modification and time of last splice in with every resource.

LGM could then offer a splice function that would check each of the three things, like so:

If the resource exists in A (true, we're iterating)
{
  If it doesn't in B (!B)
  {
    Keep A
  }
  else, it does exist in B (B)
  {
    If the time stamps of creation are the same (A.created == B.created)
    {
      If the time stamp of modification of A matches the time stamp of last splice of A (A.modified == A.spliced)
      {
        If the time stamp of modification of B does NOT match the timestamp of splice of B (B.modified != B.spliced)
          Assume B is newer, and copy B to A
        Else
          Continue to the next resource; they should be the same.
      }
      else
      {
        If the time stamp of modification of B matches the timestamp of splice of B (B.modified == B.spliced)
          Assume A is newer; keep it
        Else (B.modified != B.spliced and A.modified != A.spliced)
          I have no idea what to do here. Ask the user, show a Diff somehow. This is what requires work.
      }
    }
    else, they are different resources entirely (A.created != B.created)
    {
      If the names are the same, both users may have been thinking the same thing (A.name == B.name)
        If on prompt for action the user says to skip it
          Continue to next resource
      Increment the id of B to the next available resource ID.
    }
  }
}

Var makes it so users don't have to worry about their array bounds. Scalars allocated in bulk do not.

The idea of present is abstract and unresearched. Basically, we create a structure to proxy for each scalar*, such as int* or double*. A second proxy (or perhaps just the class of the first) will be used with calls to new[], having that operator overloaded.

So, in int_allocator::operator new[] (size_t sz), we do something like this:
value = new int[sz+1];
*value++ = sz;

Treating the struct as an int* will work just like a regular int*, but more operators could be overloaded to ensure correct performance.
#define is also an option; this is just a debug mode.

Upon access via the other class, int_proxy, the allocator class will be decremented and dereferenced for a bounds check.

Luda is back!

He offered to take up collisions again today, which is good news for the project. Luda wrote the original system used in R3, which I implemented rather poorly (no collision event), but it has since been over a year and it is safe to say we're both "on top of shit."

He apparently has hatched a plan for improving collisions to operate in O(n*log n) rather than O(n**2) like most systems. I'm not sure what time GM operates in, but frankly, who gives a crap; Luda's were faster than Mark's last time. (At least, as far as I can tell. I thought Mark was supposed to be an expert on collisions?)

Anyway, I'm personally tickled pink. Luda learned not long after making the original system that he could improve it by using integers instead of bytes (somehow that wasn't common knowledge at the time, now it's so obvious...), and with his new Quad Tree idea, we should be cooking with gas.

Also, I'd like to remind everyone that DLLs are also part of the equation now. These systems are the two things that everyone concurred are all that's left to set ENIGMA and GM apart. Let's hope we don't blow this, eh?

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.

In R3, you were allowed to say "int a;" in a code piece to declare "a" as C++'s fastest type. To declare it as a local variable to the object, however, I made you say "localv int a;". Well, that system was brutally easy to implement. However, it's not so convenient to type.

When I started the project, I was enamored by how similar C++ and GML were. I saw "var" as a data type; GM's only data type.  It was only logical that var should be a class.

However, long, long ago, NoodleNog suggested that to declare script-local variables, of type "int" for example, you should use "var int" rather than just "int." This makes it a bit of a hassle to declare script-locals, but then actual object-local variables are simply declared as "int."

He was presenting this to me as I suggested ambiguating the word "local" to use. Locals would be declared one-time, preferably in create events but technically in any event, as "local int a;".

My first choice was actually to have Ism add an event for such declarations; in this event, you would have only your locals declared. It seems rather unprofessional in retrospect, but would technically be as easy as adding semicolons and copying over the code to the front of the structure. It would make my life easier, but it would leave a bad feeling in my stomach and would cause Ism a good amount of work, possibly delaying the project further.

I was going to just go with the first option (which I will cast a vote on this time), but I figured I'd give you all a chance to toss it around and/or shoot flames at it first.

To clarify, no outcome of this poll will affect backwards-compatibility with Game Maker. This is purely an extension of the language. Undeclared variables will be treated as local vars. "localv var" and "local var" are meaningless.

Anyway, same drill as last time.
Peace.