ENIGMA Development Environment

I decided to implement backgrounds in the meantime, and dazappa has kept me busy with a number of interesting bug reports (the worst of which I have just worked out). I am not sure what is in the update-stable/ tag, but fixing it to actually work out of the box on at least Windows and Linux is priority one.

Ism has made great progress on the updater. From what I can tell it is finished, though it has an odd tendency to leave a console window open with a gray background for me.

RetroX has finished some packages, but we were discussing what the package should be responsible for vs what LGM should be responsible for. I believe right now, he's configured them to give 777 permissions to /opt/enigma, where it is installed. But it seems he includes the entire repository with the package, which means users could be downloading an outdated package from square one. Correct, RetroX?

As for the Windows release, I don't even think an installer is necessary. I think a zip file containing ENIGMA.exe, lgm16b4.jar, and the plugins folder will suffice. ENIGMA.exe and LGM will take care of the rest.

If you object to not having an installer for Windows, speak now, and I or someone else will make one.
Retro, if you want to carry our discussion regarding the packages over here, please do so. Otherwise, I think ENIGMA.exe and the jar files will suffice, along with that dependency list you've already implemented.

I am going to finish dazappa's last few bug reports.

IsmAvatar, when you are content with the updater, please say so.
RetroX, when you are done with the packages, please link all of them here, and I will rehost.

The release (And frantic workarounds for everything that goes wrong soon after) will begin as soon as the three of us are done.

Long, long ago, in a land far-- actually, it was in this chair. Or some chair that looked similar. Be it as it may, a while back, I took a shortcut and thought, "If this ever comes back to bite me, it'll be after the rest of the project is stable and I can fix it without fear." Well, that mostly came true. There are no detrimental effects at this time, simply because the amount of skill required for the malefaction to manifest simply isn't being exhibited by ENIGMA users at this time. For those who wish to be weary, this is the issue:

When I designed the C++ parser, I did not implement a proper overloading system. Overloads were, instead of instantiated as children of a main instance as I considered doing, applied to the current copy by way of modifying the bounds for acceptable parameter numbers. For instance,
string func(int a) { return "test"; }
double func(int a, int b) { return  "test2"; }
is stored only as a function returning double that takes either 1 or 2 parameters. Had the second function taken three parameters, the choices would be 1, 2, or 3, even though 3 was actually an invalid option. This makes for a blazingly inaccurate syntax check in rare situations (a GML user would never come close to noticing).

It also means a less pleasant inaccuracy on a more important system.
The following expressions were passed to a new type resolution system of mine:

room_speed
var
*var
room
room + room
room + 1
room - 1
var[5]

The results were, respectively, as follows:
Let's see if I can't waste some space and make a nicer table.

room_speed	=>	int
var	=>	var
*var	=>	double
room	=>	roomv
room + room	=>	variant
room + 1	=>	variant
room - 1	=>	double
var[5]	=>	variant

The more curious of you have a few questions. I'll do my best to answer those here:
room_speed and the like are being left integers. I see no point in wasting memory and speed so users can set some random array element in global scalars.
The type resolution system doesn't distinguish between cast and type at the moment (by choice, so I can debug without thinking of a global by that type. )
The type "roomv" is a special type with an overloaded operator= that calls room_goto(). It inherits from variant.
Because "roomv" is a special variant, room + room will return variant. This is correct. Room + anything will, in fact, so you can keep adding things such as strings.
However, room - 1 is double because subtraction only works on such. It wasn't worth it to avoid a warning on re-cast. Maybe I'll change my mind later, but in any case, the resolver was accurate.
Calls to [] on var are indeed variants.

So what's the problem? Look at item three, "*var". The parser can't distinguish between binary and unary *. Even though it knew it wanted the unary version, it couldn't get the accurate type, because I only store the type of the last declared overload, and so the parser was given `double`, the type returned by the multiplication operator.

When I need, I will store all overloads with argument counts and types, but that is a job for after the basics are all working. I want one more thing to work before I proceed, and it is indeed a trick; I would like for templated types to work, and if possible (by which I mean, it shall pass), templated casts. This way, if you have map<int,int> amap, you can say amap[whatever].x and have it behave correctly. That has been important to me since square one.

---

Another nice thing I can implement with the help of this system is the switch() optimization, as well as something brand new.

It befuddles me that neither C++ nor GML have a foreach construct. ENIGMA will be given one. It will work rather uniquely, since neither language was designed for it. Basically, it will have the following syntaxes:

foreach (array as element)
foreach (element in array)
foreach (element : array) //Java-esque

Trouble is getting it to work around this little issue: "in" and "as" are common variable names. So, I'm going to work around that thanks to how carefree my parser is when it operates.

foreach in in as
  do_something()

will work fine.

To ease the sadistic and curious, that will look like this in intermediate parse:

foreach(in)in;as;do_something();
sssssss(nn)nn;nn;nnnnnnnnnnnn();

Which makes it very easy to parse out. The first item, in (), is either what I'll be iterating, or the element name. The second, of form "nn;", will determine which; it should be "in" or "as". The third set, denoted easily by regexp /;(^;);/, is the corresponding element of the foreach.

So, how will that work from there? Simple. I determine which is the container to iterate. I then check for the following:

• Typedef by name "iterator"; iterator container::begin(); iterator container::end(); iterator::operator++() or iterator::operator++(void)
• container::operator[](int); size_t container::size() or typeof(container::operator[](int))::operator bool()

Depending on which of those I find, the foreach will be replaced with code to iterate each. The real trick is managing to proxy the "as" component in as a method of retrieving the element itself, and not the iterator type. Mind all of you, I'm not afraid to implement a macro if I must. But I imagine I can find a creative way to cram more instructions into the mix using operator, .


Anyway, I'll be busy. Thanks for your patience. I know this is taking a while, but the level of detail Ism and I've put into this goes far beyond the previous releases' quicker development time.

Peace.

I'm so happy with a couple changes I've made and am making.

First off, I'm proud to announce that standard templates are now completely available to ENIGMA users.
map a; // is the same as...
map<> a; // is the same as...
map <variant> a; // is the same as...
map <variant,variant> a;
That's right: ENIGMA now correctly defaults all non-defaulted template parameters (as in, template parameters that are not already optional according to the C++ library) to variant. That means that once Ism and I are finished coordinating our new "Definitions" resource (previously "WhiteSpace"... we're still working on a catchy name) you will be able to #include <map>, use it, and use codes like this:

map a;
a[100] = "one hundred";
a[15625682900000000.0] = "lol, big float";
a[3.141592653589793238] = "pie";
a["pi"] = 3.14;
That's right: with the implementation of var4, comparison operators are correctly implemented for all types and mirrored const. This makes them capable of complete interaction with the standard template library. GM's ds_* functions are officially toilet food in comparison.

Furthermore, map isn't exactly necessary for large numbers. Var4 also implements Lua's algorithm for fast, sparse arrays. This introduces a number of nice properties:

var a = 0;
for (int i=0; i<100; i++) a[i] = i;
a[1000000000] = "one billion";
How can this be efficient? It's simple. a[0..127] operates in O(1), because that's how much space was allocated for the array. a[128] operates in either O(1) or O(n), depending on how your system resources are doing. a[256..INT_MAX] operates in O(log(N)), as it relies on a map for the lookup. (This will hopefully be replaced with a sparse hash map at some point).

Currently the system is functional, but not finished. Var4's lua_table<> needs to ensure that elements can hop data structure when the array part is resized. Templates need field tested, which will happen after my latest renovation: the dot operator.

Because C++ introduces structures and classes which I do not want to alienate, I have to take special care to ensure that the left-hand side of the dot is not an instance of a structure. This requires a type resolver, which I hope to complete inside 400 lines. We'll see. Basically, it will return the type of the expression that precedes the dot. I intend for the following to happen:

If it's an instance of a class, check for a member by name of the variable to the right hand side of the dot. If the member exists, ignore the dot. Possibly, if the class was actually a pointer, not a direct reference, replace the dot with ->. C++ should have done this from square one; I see no use for pointer.member. If no member was found, or if the type was scalar, replace the dot with an integer-based accessor function and record that the global was indeed accessed that way so optimizations can be done later. Also try to warn if it was a class without a member and without operator int() or some other scalar that can be cast easily. Perhaps it should be up to ENIGMA to find an appropriate cast path, such as int(var()).

Anyway, just something to think about.
Back to work, ciao for now.

It's been a long journey, ENIGMA has. I've picked up a lot of tricks on the road, trying to complete it. The events and workings that transpired while working on R4 were extensive, not that I think most will notice. I've finished my replacements now. Instance System 2, Var4, and Reflex2 are all implemented. With little left to correct. But there are still some problems that I have personally and that ENIGMA has in general. The list is large and foreboding.

1) On Windows Vista, video memory is cleared every time the user presses control-alt-delete. ENIGMA loses its drawing context in the fire, and GM6 loses its surfaces. Yes, GM6 doesn't run on Vista, but I can't speak for 7 and 8 because I can only imagine Mark has corrected that in the meantime. So yes, every time the user presses control-alt-delete, ENIGMA loses the ability to display things. I'm not yet sure how to correct this, but I imagine I can test if it's happened and just ask for a new one.

2) On Linux, input is awful. In fact, much of Linux is glued together where it should be loosely tied with strings. I can't tell you how many times I'll be reading something huge, and will, without thinking, use the middle mouse button to gesture vertical scroll, only to wait for ten minutes for Firefox to finish this conversation with X:

Oh, you want me to scroll up? One minute.
*Scrolls some three pixels*
Gee, thanks Firefox.
Hey, Firefox, the mouse moved. And that button's pressed.
Oh, so you want me to scroll up? One minute.
*Scrolls some three pixels*
Gee, thanks Firefox.
Hey, Firefox, the mouse moved. And that button's pressed.
Oh, so you want me to scroll up? One minute.

This continues until either
A) No more mouse move events in the queue. This takes approximately enough time for Earth's amoebas to evolve, gain sentience, become this universe's greatest minds, construct their own universe in parallel with our own, live there for some hundred thousand millennia, populate the entirety of it and then begin a siege on ours for more living space.
B) FireFox reaches the end of the page, which causes the conversation to look more like this:

Hey, Firefo--/Yeah, I know, I'm out of scroll space./Ah, okay./Hey, Firefo--/Yeah, I know, I'm out of scroll space./Ah, okay./Hey, Firefo--/Yeah, I know, I'm out of scroll space./Ah, okay./Hey, Firefo--/Yeah, I know, I'm out of scroll space./Ah, okay.

Causing for near instant completion.
During that time, though, while X is chatting with Firefox, it's too busy to, say, LET ME SWITCH FUCKING WINDOWS. So I've no access to anything to kill Firefox. Gnome-panel is dead, so I can't switch that way or use force quit, and alt-tab/control-alt-delete are non-responsive. Control-alt-f2 also does something very unsavory. I can't remember what.

So, you may be wondering, why the bitchfest on the ENIGMA forum? Well, because ENIGMA inherits all those fun problems. If an input problem surfaces, I never know if it's my fault for screwing up ENIGMA or if it's my cry-blood-inducing, woefully inadequate input drivers.

And speaking of drivers, here on home, sweet 127.0.0.1, my graphics drivers are also parsecs ahead of the latest and greatest human technology. </sarcasm> So basically, it takes ENIGMA (and old Game Maker games that still work with WINE) approximately 11.25 microseconds to draw a single pixel of sprite (A single 128*139 sprite draws at 5fps). No other computer I've tested on has this problem, and GM does it to, so I know it's not my fault directly. The question is, how is Firefox blitting out images at decent framerates? Hell, there's a huge wallpaper rendering on my desktop, and it's not going 0.2 fps. What does it take? I'm not sure. I'll probably need to look into hardware acceleration.

(For the record, draw_rectangle with fantastic gradients works at amazing speeds; it's only sprites that are slow.)


Either way, I imagine those problems will get worked out eventually. Like I said, the instance system, new var, and new reflex (speed, direction, hspeed, vspeed, room, etc) are done. Here's what's coming up to do:

1) Test heredity. This should already work in cases such as instance_nearest, just by nature of the design of my new instance system.
2) Implement depth. This actually isn't all that hard, but may be annoying. Essentially, a new reflexive type will be created for depth. On assign, it moves the instance around in a map of draw events to iterate. In the constructor of each object, depth = <compiler inserts default depth here>; is executed. Or perhaps a separate constructor to avoid checks.
3) Go back over the syntax check and format parse, adding the remaining features.
4) Implement backgrounds. It's about time that got done. Then implement tiles, and add them to the draw depth map by way of instantiating a custom object_basic that does nothing but draw tiles at a given depth.

After that, I'll be content to start adding DND functions. These will be implemented like any other function, by the GM tile name, i.e., action_set_speed(). ENIGMA is healthy enough now that I would recommend and appreciate help implementing those.

Questions on which to pick and why have boiled down to the need to separate var into individual sources, each implementing a behavior. Var 4 will apparently implement several options.

The first of these is in how arrays are handled:
- GM uses a Map for everything, as some of you know. I guess I could make that an option.
- ENIGMA R3 uses a simple dynamic array. It checks for size, then dereferences O(1).
- Lua uses both. It would implement no additional overhead from R3, but would add some in computing whether it should use the map for large indexes.

The second of these is in how variants store memory.
- GM's method cannot be determined simply through experimentation. Presumably, since it is interpreted, Mark keeps close track of type (an extra check among a map lookup is nothing).
- ENIGMA R3 kept variant next to double for max speed, but high memory usage.
- I am capable of constructing and destroying string on the site, at the cost of an additional check per = operation (and of course, constructor and destructor call). This will reduce memory usage, but slightly(?) lower speed as well.

I will spend today trying to implement them (among other things).

Hardly. I've worked on Thank You cards to six million people. My cousin's graduation party is Sunday, which I will apparently be attending. Today I took a trip north with my dad, solely to visit my grandparents. Made the mistake of committing my code so I could work on ENIGMA there from my laptop. Didn't have much time to do so, ultimately. What's more, I came back to a certain someone informing me that the code I committed mid-sentence doesn't compile. <___<"

No, the instance system is not done. But I do have a surprise for you all.

I've seen questions going around of how GM handles events. Specifically, questions regarding the order in which they are executed. I myself used to wonder what exactly went on to implement hspeed and vspeed that ruined my first slope-using platformer. Well, that won't be a problem in ENIGMA.

I have implemented a file for R4 that contains a list of all events, the code executed in them, and some other details and trivia. I know a few are thinking right now, "great, another document for Josh to not maintain." Well, HAH. This one will always be current. Why? Because it's the file ENIGMA actually uses to determine what events were passed.

This is a beautiful thing for a number of reasons, one of the most important being that anyone can correct an event or add an event that a new version of GM implements. This is a snippet of the file, for demonstration purposes:

beginstep: 3
Group: Step
Name: Begin Step
Mode: Special
Case: 1

alarm: 2
Group: Alarm
Name: Alarm %1
Mode: Stacked
Sub Check: { if ((alarm[%1] == -1) or (alarm[%1]--)) return 0; }


# Keyboard events. These are simple enough.

keyboard: 5
Group: Keyboard
Name: Keyboard <%1>
Type: Key
Mode: Stacked
Super Check: keyboard_check(%1)

#...

step: 3
Name: Step
Mode: Special
Case: 0
Constant: {
x += hspeed, y += vspeed;
speed -= friction;
vspeed += sin(gravity_direction * pi/180),
hspeed += cos(gravity_direction * pi/180);
}

#...

collision: 4
Group: Collision
Name: %1
Type: Object
Mode: Stacked
Super Check: instance_number(%1)
Sub Check: place_meeting(x,y,%1)

That code will serve to bring an end to the hard-coded, undocumented GM method of event management.

Anyway, I'm back to work.

Too lazy to log in to Ism's forum on Vista laptop.

File corruption error with totally-LGM-made GM6:

Unhandled Exception:
org.lateralgm.file.GmFormatException - java.lang.NullPointerException: null

Stack trace:
org.lateralgm.file.GmFileReader.readRooms(GmFileReader.java:877)
org.lateralgm.file.GmFileReader.readGmFile(GmFileReader.java:167)
org.lateralgm.main.Listener.openFile(Listener.java:115)
org.lateralgm.main.Listener.actionPerformed(Listener.java:452)
javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
javax.swing.DefaultButtonModel.setPressed(Unknown Source)
javax.swing.AbstractButton.doClick(Unknown Source)
javax.swing.plaf.basic.BasicMenuItemUI.doClick(Unknown Source)
javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(Unknown Source)
java.awt.Component.processMouseEvent(Unknown Source)
javax.swing.JComponent.processMouseEvent(Unknown Source)
java.awt.Component.processEvent(Unknown Source)
java.awt.Container.processEvent(Unknown Source)
java.awt.Component.dispatchEventImpl(Unknown Source)
java.awt.Container.dispatchEventImpl(Unknown Source)
java.awt.Component.dispatchEvent(Unknown Source)
java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
java.awt.Container.dispatchEventImpl(Unknown Source)
java.awt.Window.dispatchEventImpl(Unknown Source)
java.awt.Component.dispatchEvent(Unknown Source)
java.awt.EventQueue.dispatchEvent(Unknown Source)
java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
java.awt.EventDispatchThread.pumpEvents(Unknown Source)
java.awt.EventDispatchThread.pumpEvents(Unknown Source)
java.awt.EventDispatchThread.run(Unknown Source)

This was made with an older version of LGM; it may be a bug with the old one that is now corrected. Of course, I'm still seeing "Unhandled exception..." But I don't speak Javanese.

ENIGMA's spent most of its life without a decent documentation. Now it gets a colorful one.

Gary (MahFreenAmeh) and I have been working over the last couple days (between his work and my stats project, now complete) on a parser to convert plain-text documentation into a rather lovely visual display. The display is meant for newer browsers with real features. This basically excludes IE automatically.

Anyway, the first of the documentation (thrown together only for purposes of testing the parser, so it's kind of ugly yet anyway) can be viewed here:
http://enigma-dev.org/docs/pages/test

For now, the docs use PNG. All PNGs, including the ENIGMA Logo, are merely renders of SVGs, which the docs will use ASAP. I want an all-text documentation, basically. Docs themselves being plain text, images being SVG which, as I'm sure most of you know, is just XML.

Anyway, do view the test page and post your thoughts. Feel free to recommend ways to beautify or simplify.
Do not complain that the layout uses tables, or I will track you down and murder you in a highly creative manner.

I guess I will start typing up more docs as soon as Gary has a method of adding to them arranged.

Should be interesting.

Peace. Unless you have a vendetta against tables.