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.
76
Off-Topic / Introductions
« on: March 16, 2011, 09:34:35 am »
In an effort to end this forum's war on spam, I've made it so it's virtually impossible to spam until you've made a post. The side effects of that include the inability for new members who are here legitimately to edit their profile or do other personalizations one would typically do upon registration. So, this topic is for humans who would like to have somewhere legitimate to post so they can edit their profiles and use the messaging systems.
So yes, say hi, and say something to make the admins think you're here because you are genuinely interested in what goes on here.
So yes, say hi, and say something to make the admins think you're here because you are genuinely interested in what goes on here.
77
Proposals / LateralGM extensions; official proposal
« on: January 28, 2011, 10:42:56 pm »
Once ENIGMA has its own format, it will finally be possible for it to include its own resources in outputted game files. That being the case, it is time, as Luis indicated earlier, that LGM offers a less painful method of defining custom resources.
Notice: I am in no way an expert on Java. I speak in this thread solely on authority of designing the C++ backend to potential extensions, which here is not much authority at all. My suggestions are to be taken not as a suggestion for the Java code behind the mechanism, but as the overall concept of the goals thereof.
That said, I think we should first define the goals simply in terms of what has been shown to be needed thus far (namely, by Luis's "Panes" extension proposal and my "Libraries" proposal which will conclude this message).
Before that, terms. For the purpose of this message (feel free to adopt them for your own), the following lexicons will be used:
"Loader" refers to the mechanism which will load extensions to the LateralGM interface.
"Extension" refers to a single unspecified object the Loader is loading.
"Component" refers to an interface element, such as a button or a graphic.
"Node" refers to a resource tree Component.
"MDI" refers to whatever the fuck that Java thing is that houses all the other editor windows.
I have not decided how the C++ backend should be extended, aside from that it must share a list of extension IDs.
What I have decided on is a new resource that will be added, in addition to Panes. R4's introduction called for a resource dubbed "Whitespace" and renamed to "Definitions." Both names suck. I now propose that this be a tabbed, C-code resource, basically offering what simple C IDE's offer (tabs and a code editing pane with simple features).
This proposal is likely incomplete, but I have work tomorrow and should be sleeping. Comments welcome. Comments from Java programmers especially welcome.
Notice: I am in no way an expert on Java. I speak in this thread solely on authority of designing the C++ backend to potential extensions, which here is not much authority at all. My suggestions are to be taken not as a suggestion for the Java code behind the mechanism, but as the overall concept of the goals thereof.
That said, I think we should first define the goals simply in terms of what has been shown to be needed thus far (namely, by Luis's "Panes" extension proposal and my "Libraries" proposal which will conclude this message).
Before that, terms. For the purpose of this message (feel free to adopt them for your own), the following lexicons will be used:
"Loader" refers to the mechanism which will load extensions to the LateralGM interface.
"Extension" refers to a single unspecified object the Loader is loading.
"Component" refers to an interface element, such as a button or a graphic.
"Node" refers to a resource tree Component.
"MDI" refers to whatever the fuck that Java thing is that houses all the other editor windows.
- The Loader must allow the addition of a Node or group of Nodes (represented by a folder) into the resource tree.
- The Plugin must be informed when a tree Node under its control is double clicked. (original proposal said this job was the Loader's)
- Each extension will be responsible for tracking its own data and creating its own UI elements in the passed MDI context.
- Each Extension will be given the opportunity to save or load its data when the rest of the game is doing so.
- Extensions will be given a method of identifying themselves as being instantiable in other resources
- Take, for example, a 3D mesh resource. It would inherit from a class that can be assigned to a GM object as one assigns a sprite or mask.
- An Extension that can be instantiated in room will be allowed to be placed multiple times, visually.
- Such an Extension should provide a method to obtain bounding box information for placement and clipping, as well as a method to render itself in the room.
- Extensions that can be instantiated in GM objects should provide a method of obtaining an iconic preview, as sprites do.
- Extensions must be able to supply a unique ID and a C-structured or easily restructured dump of relevant data to the output executable. If the ID is not unique, backend plugins (Namely, ENIGMA) will be unable to determine what structure they are looking at, resulting in undefined behavior (like segfault). The data must obviously be easily structured per the C spec (like POD) so that ENIGMA can work with them.
- A method must be provided of accessing any complicated UI Components to the Extensions (Namely, the JEdit class and the GML syntax highlighting context, which should be easily extended or swapped out in a specific JEdit instance). (original proposal said this job was the Loader's)
I have not decided how the C++ backend should be extended, aside from that it must share a list of extension IDs.
What I have decided on is a new resource that will be added, in addition to Panes. R4's introduction called for a resource dubbed "Whitespace" and renamed to "Definitions." Both names suck. I now propose that this be a tabbed, C-code resource, basically offering what simple C IDE's offer (tabs and a code editing pane with simple features).
This proposal is likely incomplete, but I have work tomorrow and should be sleeping. Comments welcome. Comments from Java programmers especially welcome.
78
Proposals / ENIGMA Game Format
« on: January 28, 2011, 10:19:02 pm »
ENIGMA needs its own format for game storage. GM takes far too long to load and store some executables; I was thinking it would be best to use a format allowing for quick addition, subtraction, and modification of contained resources.
With that in mind, and with the interests of picking a format that works well with Java, I believe our best bet is to use ZIP.
Essentially, .ogf or .egm files would be a compressed directory containing a subdirectory for each resource, which would be in its own format. I was thinking that the format could be largely eYAML; for instance, a sprite would be given a file name reflecting its ID (sprite0000.ey), and would contain a name: and file: attribute indicating, of course, the actual name of the resource and the image file it contains. This way, the format would basically document itself.
Just as easily, however, individual resources could be kept in separate binary files with their own unique formats.
As an option, a manifest file could be kept, but I think it'd be nicer if users could open and manipulate the resources in any zip-capable file browser and text editor. ZIP also reduces the likelihood for total corruption, and there are many tools around which can repair damaged zip files. Plus, since ZIP is he medium of choice for Java, it is unlikely we will encounter such an issue if we are using Java's own ZIP functions for the same purpose.
Any other settings would be stored in the trunk of the Zip, along with the game information and other important metrics.
This concludes my proposal for the egm (ENIGMA) or ogf (Open Game-) format. If you believe you have a better idea, post it here, andI'll call you a trollwe'll have a reasonable debate.
With that in mind, and with the interests of picking a format that works well with Java, I believe our best bet is to use ZIP.
Essentially, .ogf or .egm files would be a compressed directory containing a subdirectory for each resource, which would be in its own format. I was thinking that the format could be largely eYAML; for instance, a sprite would be given a file name reflecting its ID (sprite0000.ey), and would contain a name: and file: attribute indicating, of course, the actual name of the resource and the image file it contains. This way, the format would basically document itself.
Just as easily, however, individual resources could be kept in separate binary files with their own unique formats.
As an option, a manifest file could be kept, but I think it'd be nicer if users could open and manipulate the resources in any zip-capable file browser and text editor. ZIP also reduces the likelihood for total corruption, and there are many tools around which can repair damaged zip files. Plus, since ZIP is he medium of choice for Java, it is unlikely we will encounter such an issue if we are using Java's own ZIP functions for the same purpose.
Any other settings would be stored in the trunk of the Zip, along with the game information and other important metrics.
This concludes my proposal for the egm (ENIGMA) or ogf (Open Game-) format. If you believe you have a better idea, post it here, and
79
Announcements / Happenings
« on: January 03, 2011, 07:42:06 pm »
So after four people in less than a month struggled to install ENIGMA, I've finally begun redoing ENIGMA.exe. It will automatically call mingw-get to install necessary files; the user needs only to specify a drive letter (if he or she is dissatisfied with the default, being the current drive). I was actually looking for a function to prompt for drive letter, but couldn't find one and so abandoned the notion.
In other news, Gary has added unix names to all user accounts. As new users sign up, they will be given a unix name (or can edit it themselves). This name will be used in the Wiki shortly enough, and for user upload directories and whatnot later on.
In what may be old news, ENIGMA is only three functionalities away from being able to run the official GM platform example perfectly. The three include instance_deactivate() and co, dialog functions (for showing and logging high scores), and tiles. We'll see about those three ASAP. (But after the Windows installer).
With any luck, the provisions I am implementing in the Windows installer (new organization system for compilers and makefiles) will mean, once and for all, simplicity of adding devices for which ENIGMA can officially compile. Also with this addition will come the ability to use ENIGMA portably if configured on a USB drive.
Wish us luck.
In other news, Gary has added unix names to all user accounts. As new users sign up, they will be given a unix name (or can edit it themselves). This name will be used in the Wiki shortly enough, and for user upload directories and whatnot later on.
In what may be old news, ENIGMA is only three functionalities away from being able to run the official GM platform example perfectly. The three include instance_deactivate() and co, dialog functions (for showing and logging high scores), and tiles. We'll see about those three ASAP. (But after the Windows installer).
With any luck, the provisions I am implementing in the Windows installer (new organization system for compilers and makefiles) will mean, once and for all, simplicity of adding devices for which ENIGMA can officially compile. Also with this addition will come the ability to use ENIGMA portably if configured on a USB drive.
Wish us luck.
80
Announcements / Scalability
« on: November 24, 2010, 12:10:21 pm »
This r/coderaid business has made me realize that ENIGMA's site is not ready for the same kind of jumps that ENIGMA itself is ready to make. While the engine is scalable in the sense that most of the systems are completely modular now, the site is based off of SMF, which has a very sad excuse for a user name system.
We now have a bug tracker -and- a Wiki to contend with as far as users are concerned. Since a2h wrote the tracker himself, we haven't had issue with it. But the new Wiki requires an entirely new user base, and it just isn't compatible with SMF. The crossover that was written for it does not comply with SMF 2.0; from what I can tell, the database system between 1.2 and 2.0 is -very- different. They are similar enough that I think a port is possible, but then we have a new issue: user name content. "Josh @ Dreamland" isn't exactly a Unix name. However, Wikis don't agree with underscores or dashes, either. That's difficult to work around with our current layout.
We have two options.
1) Change everyone's login name, leaving the display name.
This means I will have to log in as JoshDreamland from now on, but you will still see me as Josh @ Dreamland on the forums. Score_Under will have to log in as ScoreUnder. I don't have figures on the matter, but from what I can tell, the number of people affected will be approximately a lot.
2) Add another field to the SMF SQL table for Unix names. This puts less strain on the users, but more on the web developers trying to port bridge modules such as SMF-Wiki. What I mean is, a2h or myself will have to custom-tailor bridge code such as the code that enables MediaWiki to use SMF user names. Also, we have to modify SMF's account creation process, and run a script on our current SQL tables to generate Unix names for the 350 existing members and check for conflicts (this is the easy part). I don't personally have the web experience to make the former change to SMF, and I'm not going to volunteer a2h to do this.
This is here as an FYI for what might happen. If a2h doesn't appraise as simple modifying the user creation query to generate a unix name and store it with the rest of the information, we may go with option one and change at least a tenth of everyone's logins. We can probably post a notice about that to help members remember (most of them will just enter it once and tell FireFox to change it).
So, yes. Just a heads up. If you have a better idea, let us know, of course.
And if you're outraged about all this work over a Wiki, this is =not= the last time we'll be seeing this issue. Look at 64Digits. I am confident in saying that if we have an influx of users, we can start a 64Digits-like hosting system. When we do that, a behind-the-scenes Unix naming convention will be very handy, otherwise some download URLs may be invalid or difficult to escape (think of all the %20s!).
-Josh
We now have a bug tracker -and- a Wiki to contend with as far as users are concerned. Since a2h wrote the tracker himself, we haven't had issue with it. But the new Wiki requires an entirely new user base, and it just isn't compatible with SMF. The crossover that was written for it does not comply with SMF 2.0; from what I can tell, the database system between 1.2 and 2.0 is -very- different. They are similar enough that I think a port is possible, but then we have a new issue: user name content. "Josh @ Dreamland" isn't exactly a Unix name. However, Wikis don't agree with underscores or dashes, either. That's difficult to work around with our current layout.
We have two options.
1) Change everyone's login name, leaving the display name.
This means I will have to log in as JoshDreamland from now on, but you will still see me as Josh @ Dreamland on the forums. Score_Under will have to log in as ScoreUnder. I don't have figures on the matter, but from what I can tell, the number of people affected will be approximately a lot.
2) Add another field to the SMF SQL table for Unix names. This puts less strain on the users, but more on the web developers trying to port bridge modules such as SMF-Wiki. What I mean is, a2h or myself will have to custom-tailor bridge code such as the code that enables MediaWiki to use SMF user names. Also, we have to modify SMF's account creation process, and run a script on our current SQL tables to generate Unix names for the 350 existing members and check for conflicts (this is the easy part). I don't personally have the web experience to make the former change to SMF, and I'm not going to volunteer a2h to do this.
This is here as an FYI for what might happen. If a2h doesn't appraise as simple modifying the user creation query to generate a unix name and store it with the rest of the information, we may go with option one and change at least a tenth of everyone's logins. We can probably post a notice about that to help members remember (most of them will just enter it once and tell FireFox to change it).
So, yes. Just a heads up. If you have a better idea, let us know, of course.
And if you're outraged about all this work over a Wiki, this is =not= the last time we'll be seeing this issue. Look at 64Digits. I am confident in saying that if we have an influx of users, we can start a 64Digits-like hosting system. When we do that, a behind-the-scenes Unix naming convention will be very handy, otherwise some download URLs may be invalid or difficult to escape (think of all the %20s!).
-Josh
81
Announcements / r/coderaid
« on: November 19, 2010, 11:13:43 am »
It was brought to my attention just this morning that ENIGMA is ranking for consideration on r/coderaid, meaning a possible influx of developers (and of the competent variety, no less!) working on ENIGMA.
The page on the matter, given to me by Enkiv2 (I presume; Freenode nick "Enki-]["), is here. (Full link http://www.reddit.com/r/coderaid/comments/e4bui/project_suggestion_enigma_game_maker_foss_clone/).
So, if you have an account there, and feel ENIGMA could use a few more helping hands, feel free to vote.
I'm going to write some introductory pages to the documentation for people who really don't know what the project is all about (I love the description justyellowboy gave, but I need to convey what the project looks like on the inside).
I'll be writing. Peace.
The page on the matter, given to me by Enkiv2 (I presume; Freenode nick "Enki-]["), is here. (Full link http://www.reddit.com/r/coderaid/comments/e4bui/project_suggestion_enigma_game_maker_foss_clone/).
So, if you have an account there, and feel ENIGMA could use a few more helping hands, feel free to vote.
I'm going to write some introductory pages to the documentation for people who really don't know what the project is all about (I love the description justyellowboy gave, but I need to convey what the project looks like on the inside).
I'll be writing. Peace.
82
Sound and Music / Audio Sequencing (midi alternatives)
« on: November 16, 2010, 07:50:49 am »
Mod Edit: This post was originally posted in response to http://enigma-dev.org/forums/index.php?topic=666.0 but was split when a whole discussion branched from it.
The topic of discussion is possible alternatives to the MIDI audio sequencing format, preferably something that both LGM/Java and Enigma can support and/or convert.
Original post:
Why not extended fucking module? Someone find a midi2xm we can port around. MIDI is the only format smaller than XM, and XM sounds nicer and more consistent. They're practically siblings.
Isn't something for Java able to do that?
The topic of discussion is possible alternatives to the MIDI audio sequencing format, preferably something that both LGM/Java and Enigma can support and/or convert.
Original post:
Why not extended fucking module? Someone find a midi2xm we can port around. MIDI is the only format smaller than XM, and XM sounds nicer and more consistent. They're practically siblings.
Isn't something for Java able to do that?
83
Proposals / Re: Preprocessor Directives (The compile-time "if")
« on: November 06, 2010, 10:42:18 am »
I see what you mean, Rusky. For a little bit I was thinking about doing something like that (C takes a lot of heat over the issues rising from copy-pasted macros, of course), but I don't think I should. The only reason I'm keeping any sort of macros is because of ENIGMA's C heritage. If it wasn't for that, they'd be expression based if they were in at all, but my reason for wanting preprocessors at all at this point isn't for macros. My number one concern is the #if directive. The rest are just kind of there. The reason I want #if is for altering behavior from platform to platform. I was discussing with marbs the other day the implications of ENIGMA compiling for iPhone, and he mentioned motion detecting devices.
Originally, I intended to offer controller_get_angle_x/y/z() and controller_get_shaken(). On Windows, they'd all return zero unless an applicable device was connected. On Wii, they'd all have an accurate return. On iPhone, _angle _x and _y would work, as well as _shaken (same for android). Issue is, what if that isn't enough? What if having a shake is a critical part of the game, and they would have to work around it with multiple lines of code (likely to test for a key combo instead)?
I like a number of features for Lisp's macros, but my focus is really more on preprocessors right now. Maybe we can pile on a new macro system as well, later. But for now I'm more concerned about being able to say
[[If Target_Device == eDev_iPhone]]
if (controller_get_shaken())
earthquake();
[[else]]
if (keyboard_check(vk_control) and keyboard_check_pressed(ord("E")))
earthquake();
[[fi]]
Granted, that's not a very good example, since a simple "or" could technically have sufficed with little overhead. But it conveys the basic idea.
Say we want our mobile game to always be oriented correctly, and which direction has the high resolution doesn't really matter.
Persistent Controller Step Event:
Originally, I intended to offer controller_get_angle_x/y/z() and controller_get_shaken(). On Windows, they'd all return zero unless an applicable device was connected. On Wii, they'd all have an accurate return. On iPhone, _angle _x and _y would work, as well as _shaken (same for android). Issue is, what if that isn't enough? What if having a shake is a critical part of the game, and they would have to work around it with multiple lines of code (likely to test for a key combo instead)?
I like a number of features for Lisp's macros, but my focus is really more on preprocessors right now. Maybe we can pile on a new macro system as well, later. But for now I'm more concerned about being able to say
[[If Target_Device == eDev_iPhone]]
if (controller_get_shaken())
earthquake();
[[else]]
if (keyboard_check(vk_control) and keyboard_check_pressed(ord("E")))
earthquake();
[[fi]]
Granted, that's not a very good example, since a simple "or" could technically have sufficed with little overhead. But it conveys the basic idea.
Say we want our mobile game to always be oriented correctly, and which direction has the high resolution doesn't really matter.
Persistent Controller Step Event:
Code: (EDL) [Select]
[[if Target_Device == eDev_iPhone or Target_Device == eDev_Android]]
int az = controller_get_angle_z();
if (az > 45 and az < 135 or az > 225 and az < 315)
view_wview[0] = display_get_width(),
view_wview[0] = display_get_height%
84
Announcements / Long enough without an update
« on: November 04, 2010, 09:42:40 am »
As usual, we've been trying to get all our ducks in a row. It looks something like this:
More specifically, it looks like this:
(Or more recently, this: http://dl.dropbox.com/u/1052740/enigma/screens/fonts/Screenshot-Untitled%20Window-2.png)
And with that, here's what's been happening.
Resources
ENIGMA has gained two new resources lately, namely backgrounds (courtesy of HaRRiKiRi and TGMG) and fonts (my own doing). However, fonts must be added via font_add_sprite(), and backgrounds must be drawn manually. Ism is working on giving me a compression method, which I will use to re-zlib the font glyphs after I pack them. Also, before I ever got to post news on fonts, HaRRi added all the font functions (they still need finalized once it is convenient to test them; it's nothing more than 20 minutes of work, if only the issue I have foreseen now afflicts them). Maybe I'll do something about backgrounds soon...
To tie up a couple questions, by "pack them (the glyphs)," I mean stick them tightly together to conserve VRAM and increase the likelihood that they'll work on, say, the iPhone. I wrote a rectangle packing algorithm, which in the outdated screenshot above is packing the font glyphs a little too tightly. That has since been fixed, but what you see is the packed result of what was once a 256*256 font sheet.
Systems
As pictured vaguely above, r9k has been working on triangle-based collisions. These will evolve into polygon-based collisions with a little TLC. Thanks to some other changes mentioned later in this post, r9k was able to get simple triangle-triangle collision class, Triangle, working from within EDL.
Code
I fixed a few problems with the syntax checker and parser, and here's what they can do now:
If that doesn't mean anything to you, just know that it puts a lot of power at the finger tips of those to whom it does. Since then, r9k found a problem seemingly regarding the difference between class and struct in my parser. I'll be looking into that shortly enough.
Technical details:
When resolving operator., ENIGMA isolates the left-hand side of the dot, and runs it through a stack-based coercer, which resolves a viable type to represent the expression. Any variables in the expression will be searched for starting from the script scope, then to the globalvar scope, then the object scope, and finally to the global scope. If no type is explicitly named or no variable is found, the coercer defaults to var. From there, the type is checked for a member by name of the right-hand side of the dot.
If one is found: The type is checked for any reference marks (such as * or []) that would indicate it's a pointer. If one's found, the dot becomes ->. Otherwise it's left alone.
If one is not found: The expression is placed in parentheses. If the right-hand side is a global local (a local found in all instances), the entire segment is rewritten as enigma::glaccess(expression)->varname, where glaccess() returns a pointer to the parent class containing all global locals. Otherwise, the expression is replaced with an accessor function, in this format enigma::varaccess_varname(expression). The compiler will later generate an accessor function to fit the bill. Additionally, the expression is cast to int to reduce the likelihood for compile error/warn.
Additionally, I finished with(), in the sense that "other" now works in it.
Finally, just yesterday I implemented all the mouse events. Most still need tested; they are bbox based for now.
Portability/Extensibility
Ism now uses my network of YAML files to provide build platform/API options to the user. So now, at least on Mac, you can select "iPhone" or "Android" to build for. I don't believe TGMG has capitalized on this yet (there is still work to do), but we should have the whole system working soon enough (implying the ability to switch between target OS/device from LGM).
Also, someone submitted a bug that ENIGMA wasn't working on Windows a while back; it's difficult to keep it working on both platforms. Today, I'm going to get mingw-get working with ENIGMA.exe, so we can finally have a respectable install process on Windows.
I'm also going to hit Ism up to call "make enigma" even when she thinks it doesn't need done.
Finally, I have been working on widgets for ENIGMA. The reason for this is so I can finally bring Build Mode to R4. Some of you may remember it from R3; It was by far the best idea introduced in the system. Widgets are looking like this so far:
Those functions will be available to the user and used by Build Mode's new system. Build Mode will be renamed to Design Mode to avoid ambiguity in communication.
Also, I did most of the GM dialogs (get_color, get_open_filename, show_menu, etc.). I also added, just to be original, my own show_menu_ext:
So anyone that was hoping for a powerful widget interface in ENIGMA can rest easy. However, to answer someone's next question, no, you cannot place the widgets over your game screen. You need to make them their own window. Someone will probably code an in-game widgeting library later on. (Menus and color selections are, of course, their own windows, and do not need any special treatment to make).
Anyway, as you can see, the new widget library has no trouble re-creating R3 Build Mode's UI.
Lastly finally, Ism has been working on some DND functions. With that, we needed to fix isolated, system-invoked events such as Create to maintain a valid self-referential iterator so functions like action_set_motion (or whatever the hell it is; no one uses those directly) can accurately access the current instance's locals. For the continued success of this endeavor, I will need to finish my YAML-based instance block system (very similar to Rusky's proposal of components from long ago, only without unsightly pointer members; feel free to irritate the issue and we can discuss the intricacies of why I won't tolerate pointer members and why the low-level components are still tiered
).
And on the subject of events, in fixing up the mouse wheel event, I added mouse_get_wheel_vangle(). It returns how many increments the mouse wheel has rolled vertically, even though most devices anymore do not have a wheel but a trackpad of sorts (Laptops, Apple Magic Mouse). Also, I've seen only two devices with a horizontal scroll wheel (Apple's Mighty Mouse scroll ball, some off-brand fucking-huge mouse with 36 buttons on each surface). That being the case, feel free to propose a better name.
Cheers.
More specifically, it looks like this:
(Or more recently, this: http://dl.dropbox.com/u/1052740/enigma/screens/fonts/Screenshot-Untitled%20Window-2.png)
And with that, here's what's been happening.
Resources
ENIGMA has gained two new resources lately, namely backgrounds (courtesy of HaRRiKiRi and TGMG) and fonts (my own doing). However, fonts must be added via font_add_sprite(), and backgrounds must be drawn manually. Ism is working on giving me a compression method, which I will use to re-zlib the font glyphs after I pack them. Also, before I ever got to post news on fonts, HaRRi added all the font functions (they still need finalized once it is convenient to test them; it's nothing more than 20 minutes of work, if only the issue I have foreseen now afflicts them). Maybe I'll do something about backgrounds soon...
To tie up a couple questions, by "pack them (the glyphs)," I mean stick them tightly together to conserve VRAM and increase the likelihood that they'll work on, say, the iPhone. I wrote a rectangle packing algorithm, which in the outdated screenshot above is packing the font glyphs a little too tightly. That has since been fixed, but what you see is the packed result of what was once a 256*256 font sheet.
Systems
As pictured vaguely above, r9k has been working on triangle-based collisions. These will evolve into polygon-based collisions with a little TLC. Thanks to some other changes mentioned later in this post, r9k was able to get simple triangle-triangle collision class, Triangle, working from within EDL.
Code
I fixed a few problems with the syntax checker and parser, and here's what they can do now:
Code: (EDL) [Select]
list a; var b = 10;
a.push_back(b);
show_message(string(a.size()));
rect* a = some_rect_function();
a.left = 0;If that doesn't mean anything to you, just know that it puts a lot of power at the finger tips of those to whom it does. Since then, r9k found a problem seemingly regarding the difference between class and struct in my parser. I'll be looking into that shortly enough.
Technical details:
When resolving operator., ENIGMA isolates the left-hand side of the dot, and runs it through a stack-based coercer, which resolves a viable type to represent the expression. Any variables in the expression will be searched for starting from the script scope, then to the globalvar scope, then the object scope, and finally to the global scope. If no type is explicitly named or no variable is found, the coercer defaults to var. From there, the type is checked for a member by name of the right-hand side of the dot.
If one is found: The type is checked for any reference marks (such as * or []) that would indicate it's a pointer. If one's found, the dot becomes ->. Otherwise it's left alone.
If one is not found: The expression is placed in parentheses. If the right-hand side is a global local (a local found in all instances), the entire segment is rewritten as enigma::glaccess(expression)->varname, where glaccess() returns a pointer to the parent class containing all global locals. Otherwise, the expression is replaced with an accessor function, in this format enigma::varaccess_varname(expression). The compiler will later generate an accessor function to fit the bill. Additionally, the expression is cast to int to reduce the likelihood for compile error/warn.
Additionally, I finished with(), in the sense that "other" now works in it.
Finally, just yesterday I implemented all the mouse events. Most still need tested; they are bbox based for now.
Portability/Extensibility
Ism now uses my network of YAML files to provide build platform/API options to the user. So now, at least on Mac, you can select "iPhone" or "Android" to build for. I don't believe TGMG has capitalized on this yet (there is still work to do), but we should have the whole system working soon enough (implying the ability to switch between target OS/device from LGM).
Also, someone submitted a bug that ENIGMA wasn't working on Windows a while back; it's difficult to keep it working on both platforms. Today, I'm going to get mingw-get working with ENIGMA.exe, so we can finally have a respectable install process on Windows.
I'm also going to hit Ism up to call "make enigma" even when she thinks it doesn't need done.
Finally, I have been working on widgets for ENIGMA. The reason for this is so I can finally bring Build Mode to R4. Some of you may remember it from R3; It was by far the best idea introduced in the system. Widgets are looking like this so far:
Code: (EDL) [Select]
int window = wgt_window_create(480, 96);
int layout = wgt_layout_create(window,
"OOOOOOO\n"
"PUXYWHS\n"
"FRGGIIS", 2, 2);
int cbbobj, bpause, bfreeze, bundo, bredo, bstop, tegx, tegy, tegw, tegh, cbgrid, cbiso;
wgt_layout_insert_widget(layout, "O", cbbobj = wgt_combobox_create("object0|object1|object2|cat|hat|box|wall|toilet|cloud|mushroom"));
wgt_layout_insert_widget(layout, "P", bpause = wgt_button_create("Pause"));
wgt_layout_insert_widget(layout, "F", bfreeze = wgt_button_create("Freeze"));
wgt_layout_insert_widget(layout, "U", bundo = wgt_button_create("Undo"));
wgt_layout_insert_widget(layout, "R", bredo = wgt_button_create("Redo"));
wgt_layout_insert_widget(layout, "X", tegx = wgt_textline_create("X",3));
wgt_layout_insert_widget(layout, "Y", tegy = wgt_textline_create("Y",3));
wgt_layout_insert_widget(layout, "W", tegw = wgt_textline_create("W",3));
wgt_layout_insert_widget(layout, "H", tegh = wgt_textline_create("H",3));
wgt_layout_insert_widget(layout, "G", cbgrid = wgt_checkbox_create("Grid"));
wgt_layout_insert_widget(layout, "I", cbiso = wgt_checkbox_create("Iso"));
wgt_layout_insert_widget(layout, "S", bstop = wgt_button_create("Stop"));
wgt_window_show(window);
Those functions will be available to the user and used by Build Mode's new system. Build Mode will be renamed to Design Mode to avoid ambiguity in communication.
Also, I did most of the GM dialogs (get_color, get_open_filename, show_menu, etc.). I also added, just to be original, my own show_menu_ext:
Code: (EDL) [Select]
show_menu_ext(32,32,"test|of|menus|-|>Project|/Save|Close|<|[]Checkbox|[*]Checked|-|()Radio|(*)Radiod|etc")So anyone that was hoping for a powerful widget interface in ENIGMA can rest easy. However, to answer someone's next question, no, you cannot place the widgets over your game screen. You need to make them their own window. Someone will probably code an in-game widgeting library later on. (Menus and color selections are, of course, their own windows, and do not need any special treatment to make).
Anyway, as you can see, the new widget library has no trouble re-creating R3 Build Mode's UI.
Lastly finally, Ism has been working on some DND functions. With that, we needed to fix isolated, system-invoked events such as Create to maintain a valid self-referential iterator so functions like action_set_motion (or whatever the hell it is; no one uses those directly) can accurately access the current instance's locals. For the continued success of this endeavor, I will need to finish my YAML-based instance block system (very similar to Rusky's proposal of components from long ago, only without unsightly pointer members; feel free to irritate the issue and we can discuss the intricacies of why I won't tolerate pointer members and why the low-level components are still tiered
).And on the subject of events, in fixing up the mouse wheel event, I added mouse_get_wheel_vangle(). It returns how many increments the mouse wheel has rolled vertically, even though most devices anymore do not have a wheel but a trackpad of sorts (Laptops, Apple Magic Mouse). Also, I've seen only two devices with a horizontal scroll wheel (Apple's Mighty Mouse scroll ball, some off-brand fucking-huge mouse with 36 buttons on each surface). That being the case, feel free to propose a better name.
Cheers.
85
Announcements / Proceedings
« on: September 30, 2010, 03:18:53 pm »
More and more people have been taking an interest in helping with the ENIGMA Project lately, and I believe I need to recognize that.
TGMG sort of waltzed in one day and added support for three new operating systems, as most of you are aware. Since then, he has taken to improving ENIGMA full-time; adding functions, testing for bugs, and contributing to the system as a whole.
I am unsure whether or not r9k has an account here, but he worked with Ism on polygon collisions, online functions, and, independently, d3d_* functions.
Though dazappa is not a very active member on the forums, he has been trying to help Ism out with some Java aspects. He researched rendering font glyphs to pass to ENIGMA, and more recently has begun writing a YAML parser for Ism to use (apparently, porting my 200-liner to Java is a lost cause).
HaRRiKiRi, with a little help from TGMG and even less from myself, coded several graphics functions, including draw_sprite_tiled*, draw_sprite_general, and draw_background*.
As for myself, I've been working more with my network of YAML files, trying to make extending ENIGMA as simple as copying in a directory. I've also fixed some things in the syntax checker, but I'm pretty much always doing that.
I've also been up to something different. ENIGMA needs an exception written to the GPL. The problem is trying to define officialness. The reasoning is simple.
1) ENIGMA is GPL software.
2) ENIGMA links your game against its engine.
3) The engine is also GPL.
4) Therefore, your game must be open source, GPL software as well.
5) Game Maker doesn't require this, so something must be done.
6) Two options to correct this:
a. Use a less restrictive license, such as BSD
b. Write an exception to the GPL.
Opting to write a specific exception to the GPL just for official ENIGMA copies is, to use TGMG's words, "a good idea so a whole load of GM's don't pop up." But don't assume our motives are entirely selfish: This exception grants an additional right to ENIGMA's users. The idea is that by NOT GRANTING this right to users of unofficial forks, we increase the likelihood of third-party development of ENIGMA vs that of a third party simply offing and doing their own thing with ENIGMA's source.
Basically, we are locking an incentive to use our official version instead of someone's clone. That way, if that person actually had anything to contribute, it will go to ENIGMA instead of staying with that individual.
Problem is, I'm not a lawyer. Neither's Ism. So if you think you can assist us in writing this exception, here's where we left off:
Peace.
TGMG sort of waltzed in one day and added support for three new operating systems, as most of you are aware. Since then, he has taken to improving ENIGMA full-time; adding functions, testing for bugs, and contributing to the system as a whole.
I am unsure whether or not r9k has an account here, but he worked with Ism on polygon collisions, online functions, and, independently, d3d_* functions.
Though dazappa is not a very active member on the forums, he has been trying to help Ism out with some Java aspects. He researched rendering font glyphs to pass to ENIGMA, and more recently has begun writing a YAML parser for Ism to use (apparently, porting my 200-liner to Java is a lost cause).
HaRRiKiRi, with a little help from TGMG and even less from myself, coded several graphics functions, including draw_sprite_tiled*, draw_sprite_general, and draw_background*.
As for myself, I've been working more with my network of YAML files, trying to make extending ENIGMA as simple as copying in a directory. I've also fixed some things in the syntax checker, but I'm pretty much always doing that.
I've also been up to something different. ENIGMA needs an exception written to the GPL. The problem is trying to define officialness. The reasoning is simple.
1) ENIGMA is GPL software.
2) ENIGMA links your game against its engine.
3) The engine is also GPL.
4) Therefore, your game must be open source, GPL software as well.
5) Game Maker doesn't require this, so something must be done.
6) Two options to correct this:
a. Use a less restrictive license, such as BSD
b. Write an exception to the GPL.
Opting to write a specific exception to the GPL just for official ENIGMA copies is, to use TGMG's words, "a good idea so a whole load of GM's don't pop up." But don't assume our motives are entirely selfish: This exception grants an additional right to ENIGMA's users. The idea is that by NOT GRANTING this right to users of unofficial forks, we increase the likelihood of third-party development of ENIGMA vs that of a third party simply offing and doing their own thing with ENIGMA's source.
Basically, we are locking an incentive to use our official version instead of someone's clone. That way, if that person actually had anything to contribute, it will go to ENIGMA instead of staying with that individual.
Problem is, I'm not a lawyer. Neither's Ism. So if you think you can assist us in writing this exception, here's where we left off:
Quote
ENIGMA GPL Exception
Preamble
This Program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; version 3 of the License or any later version.
Disclaimer of Warranty
This Program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
Full License Text
You should have received a copy of the GNU General Public License along with this program; if not, see <www.gnu.org/licenses>.
Additional Definitions
The GNU General Public License defines several generic terms. All of these terms apply here, in addition to the following.
"The ENIGMA Development Environment" refers to the Program as defined by the GNU General Public License, in its entirety.
"ENIGMA" (where not followed by either "Development" or "Environment") refers to the segment of the Program designed to behave as a compiler, parsing inputted code and invoking additional compilers and linkers.
"ENIGMA Website" refers to the series of pages accessible from http://www.enigma-dev.org or any site to which that URL redirects.
"Officially Endorsed" implies that the information or material has been officially published on the ENIGMA Website.
"Stable Release" refers to an Officially Endorsed release of the ENIGMA Development Environment.
"Approved Compilers" refer to any toolchain executables, including, but not limited to, Make, Compilers, Linkers, and Assemblers, invoked by an official Stable Release.
"Approved Interface" refers to any graphical user interface capable of taking user input and invoking ENIGMA, which in turn parses the user input and invokes Approved Compilers to compile the input. This group is composed EXCLUSIVELY of any such programs contained in a Stable Release of the Program, or outlined in the "Exception" section of the ENIGMA Website.
"The ENIGMA Team" refers to one or all of the group of individuals whose code is distributed in the Stable Release.
Special Exception
In addition, as a special exception, the ENIGMA Team gives You the additional right to link the code of this Program with code not covered under the GNU General Public License ("Non-GPL Code") and to distribute linked combinations including the two, subject to the limitations in this section.
1. Non-GPL Code permitted under this exception must only be linked to the code of this Program by an OFFICIAL RELEASE of the ENIGMA Development Environment, as defined here:
a. The ENIGMA Environment must be unmodified from its Stable Release as Officially Endorsed by the ENIGMA Team.
b. The Compilation phase of the exempted Object Code must be Invoked from an Approved Interface.
c. The programs Invoked by ENIGMA (including, but not limited to, the Compiler and Linker) must all be Approved Compilers.
2. The files of Non-GPL Code may instantiate templates or use macros or inline functions from the Approved Interfaces without causing the resulting work to be covered by the GNU General Public License.
3. Only the ENIGMA Team may make changes or additions to the list of Approved Interfaces.
4. You must obey the GNU General Public License in all respects for all of the Program code and other code used in conjunction with the Program except the Non-GPL Code covered by this exception.
5. If you modify this file, you may extend this exception to your version of the file, but you are not obligated to do so. If you do not wish to provide this exception without modification, you must delete this exception statement from your version and license this file solely under the GPL without exception.
Peace.
86
Announcements / What's happening now
« on: September 13, 2010, 12:13:25 am »
Since I put out that zip file to test who can install ENIGMA, I've been getting feedback from all angles. Basically, a couple serious issues were corrected or are being corrected, in the order they likely surfaced:
1. ENIGMA.exe could not recognize the Program Files directory on foreign (Non-English) Windows systems. This meant that it simply couldn't find Java to run it for the user. Since %programfiles% is evidently not interpreted correctly by CreateProcess, this was fixed (in theory; I've not tested but assume it to work) by fetching the environment variable manually.
2. An invalid handle (as far as DuplicateHandle is concerned) to stdin was passed to make.exe when no console window was open. This caused make to bail for no rea reason (It doesn't actually use stdin in ENIGMA's process, or in any process of which I'm aware). Combined with the previous error, this means that if ENIGMA.exe can't find Java.exe, you can't use ENIGMA at all. This error was resolved by requesting a new (also either NULL or INVALID) handle to CONIN$, which placates make.exe (again, for no good reason).
3. D:C:\ Was an issue that surfaced when I threw kkg and some others on the IRC a fix for (1). This error lived a total of ten minutes, and was fixed by adding a NOT.
4. LateralGM exception: Cannot find ENIGMA's class. This error can only be explained by blaming the update sequence. It can be remedied simply by restarting LGM without it updating. Ism is working on a fix for it now.
5. LateralGM constantly pesters for update: Fixed.
5.5: LateralGM frequently pesters for update: This is due to a number of factors, the common ones being, as Ism said, as follow:
- An update is in fact available.
- A file has changed that is under strict version control (aka, everything that downloads when you run LGM for the first time).
- An update exists for one of the other branches. This should certainly not be notified on.
What else I've fixed/am working on:
- Fixed a couple small but annoying bugs, mostly reported by polygone. The most severe of them was a crash on missing closing comment, which originally I was going to have error, but then remembered that GML allows it and removed the check for it in syntax without taxing the parser to do that check as well.
- Am currently working on the network of flag files ENIGMA will use to identify different platforms that can be compiled for. The basic gist of them is this:
That file contains everything (so far) needed to describe OS X as a platform for which ENIGMA can compile. It is located under ENIGMAsystem/SHELL/Platforms/Cocoa/. Three other files almost identical to that one exist under the other three folders. Android is not presently supported in the repository version; TGMG will likely add it after this flagging system is finished.
Wish us luck. Especially Ism. She has a lot of crap to sort through due to such road blocks as Java lacking a "delete."
*mutters something under breath*
When all of the bugs above are fixed and re-tested by my group of victims, we will re-release the zip file. If all comes back positive, the zip will be uploaded to SourceForge, as well as the other zips/packages.
Peace.
1. ENIGMA.exe could not recognize the Program Files directory on foreign (Non-English) Windows systems. This meant that it simply couldn't find Java to run it for the user. Since %programfiles% is evidently not interpreted correctly by CreateProcess, this was fixed (in theory; I've not tested but assume it to work) by fetching the environment variable manually.
2. An invalid handle (as far as DuplicateHandle is concerned) to stdin was passed to make.exe when no console window was open. This caused make to bail for no rea reason (It doesn't actually use stdin in ENIGMA's process, or in any process of which I'm aware). Combined with the previous error, this means that if ENIGMA.exe can't find Java.exe, you can't use ENIGMA at all. This error was resolved by requesting a new (also either NULL or INVALID) handle to CONIN$, which placates make.exe (again, for no good reason).
3. D:C:\ Was an issue that surfaced when I threw kkg and some others on the IRC a fix for (1). This error lived a total of ten minutes, and was fixed by adding a NOT.
4. LateralGM exception: Cannot find ENIGMA's class. This error can only be explained by blaming the update sequence. It can be remedied simply by restarting LGM without it updating. Ism is working on a fix for it now.
5. LateralGM constantly pesters for update: Fixed.
5.5: LateralGM frequently pesters for update: This is due to a number of factors, the common ones being, as Ism said, as follow:
- An update is in fact available.
- A file has changed that is under strict version control (aka, everything that downloads when you run LGM for the first time).
- An update exists for one of the other branches. This should certainly not be notified on.
What else I've fixed/am working on:
- Fixed a couple small but annoying bugs, mostly reported by polygone. The most severe of them was a crash on missing closing comment, which originally I was going to have error, but then remembered that GML allows it and removed the check for it in syntax without taxing the parser to do that check as well.
- Am currently working on the network of flag files ENIGMA will use to identify different platforms that can be compiled for. The basic gist of them is this:
Code: (e-yaml) [Select]
%e-yaml
---
Name: Mac OS X
Identifier: Cocoa
Represents: MacOSX
Description: Run on Apple Mac OS X, or other Cocoa-enabled Apple systems.
Author: TGMG
Build-Platforms: MacOSX
Run-Program: open
Run-Params: $gameThat file contains everything (so far) needed to describe OS X as a platform for which ENIGMA can compile. It is located under ENIGMAsystem/SHELL/Platforms/Cocoa/. Three other files almost identical to that one exist under the other three folders. Android is not presently supported in the repository version; TGMG will likely add it after this flagging system is finished.
Wish us luck. Especially Ism. She has a lot of crap to sort through due to such road blocks as Java lacking a "delete."
*mutters something under breath*
When all of the bugs above are fixed and re-tested by my group of victims, we will re-release the zip file. If all comes back positive, the zip will be uploaded to SourceForge, as well as the other zips/packages.
Peace.
87
Function Peer Review / Instance Interface How-to
« on: September 09, 2010, 12:40:21 pm »
Some functions need to interface with the current instance or with all instances.
The new instance system I was singing praises about for so long offers a simple interface to do this.
To fetch the currently active instance, use
Example:
Iterating instances is about as easy.
As I've said, ENIGMA uses a unified iterator class. The class contains two members of concern; a pointer to the instance (guaranteeing only id and object_index members) and a pointer to the next iterator. If at any point the pointer is NULL, iteration is over.
An iterator can be fetched by an integer just like in EDL by using enigma::fetch_inst_iter_by_int(obj).
Example:
A system has not yet been added to manipulate locals that are not guaranteed (such as health).
Variables that are key parts of the system (such as x and y) are included in different tiers of ENIGMA's instance system. The lowest tier is collisions, implementing bbox_* variables, and solid. The graphics tier implements such variables as sprite_index and image_index (which may eventually be removed as its use seems to indicate that placing it in system tiers is unnecessary). x,y, speed, direction, hspeed, and vspeed are implemented in the tier below that. Variables id and object_index are implemented in the bottommost tier.
The new instance system I was singing praises about for so long offers a simple interface to do this.
To fetch the currently active instance, use
Code: [Select]
enigma::instance_event_iterator.Example:
Code: [Select]
int instance_destroy()
{
enigma::instance_event_iterator->inst->unlink();
return 0;
}Iterating instances is about as easy.
As I've said, ENIGMA uses a unified iterator class. The class contains two members of concern; a pointer to the instance (guaranteeing only id and object_index members) and a pointer to the next iterator. If at any point the pointer is NULL, iteration is over.
An iterator can be fetched by an integer just like in EDL by using enigma::fetch_inst_iter_by_int(obj).
Example:
Code: [Select]
int instance_find(int obj, int num)
{
int nth=0;
for (enigma::inst_iter *it = enigma::fetch_inst_iter_by_int(obj); it != NULL; it = it->next)
{
nth++;
if (nth>num)
return (int) it->inst->id;
}
return noone;
}A system has not yet been added to manipulate locals that are not guaranteed (such as health).
Variables that are key parts of the system (such as x and y) are included in different tiers of ENIGMA's instance system. The lowest tier is collisions, implementing bbox_* variables, and solid. The graphics tier implements such variables as sprite_index and image_index (which may eventually be removed as its use seems to indicate that placing it in system tiers is unnecessary). x,y, speed, direction, hspeed, and vspeed are implemented in the tier below that. Variables id and object_index are implemented in the bottommost tier.
88
Function Peer Review / Function Peer Review Board
« on: September 09, 2010, 12:24:09 pm »
Greetings, all.
This board was added with the completion (However temporary) of ENIGMA's C++ Definitions resource.
Using this resource, users can add their own C++ functions and types to ENIGMA, or include them from other headers.
This board is for users who wish to share their C++ function sets, and perhaps even include them in the specification. If you meet developer peer review, and your function is included in the Game Maker spec, it will almost certainly be added.
Basic board rules apply. No flaming; every contribution or attempt at a contribution, however poor or inefficient, is welcome.
A sad cry of a stab in the dark at implementing a function may even provoke a developer to implement it correctly and add it in.
Cheers.
This board was added with the completion (However temporary) of ENIGMA's C++ Definitions resource.
Using this resource, users can add their own C++ functions and types to ENIGMA, or include them from other headers.
This board is for users who wish to share their C++ function sets, and perhaps even include them in the specification. If you meet developer peer review, and your function is included in the Game Maker spec, it will almost certainly be added.
Basic board rules apply. No flaming; every contribution or attempt at a contribution, however poor or inefficient, is welcome.
A sad cry of a stab in the dark at implementing a function may even provoke a developer to implement it correctly and add it in.
Cheers.
89
Announcements / ENIGMA R4
« on: September 08, 2010, 04:38:46 am »
OUTDATED
The contents/links of this page may be outdated. We have instead starting hosting our installation links and directions on the wiki: http://enigma-dev.org/docs/Wiki/Install
It's been a long road. So much has come and gone, and even just changed slightly, since the release of R3 near the end of 2008. R3, as most of you know, was basically a proof-of-concept. It demonstrated that with a little effort, it is possible to take something like Game Maker and compile it for a number of advantages. Since then, ENIGMA's philosophy has changed by leaps and bounds. What started only as a spite-fueled attempt to compile GML has evolved into a nonstop effort to develop the better scripting language.
R3 brought most of GM's language functionality to the compiled world, and with some limitations, most of C++'s as well. R4, however, has shattered the boundary between the two.
With R4's new setup, the system is astoundingly extensible, and even faster and more efficient than ever before. The newly designed instance system functions like a dream, handling the more thought-consuming concepts such as heredity automatically, by nature of its design.
C++ functions and containers are available to anyone who wants to #include them in the new resource, so far called "Definitions." By that mechanism, anyone can create C++ structures and functions for use in ENIGMA games. Even with a (constantly shrinking) list of missing features from R3, ENIGMA has never been in a better condition.
That said, as has been hinted, there is much left to do. The main system is in place and has undergone basic testing. But this release marks the public beta of the final product. Please report any and all errors you encounter immediately.
The first challenge on our list of things to work out in the beta is actually getting ENIGMA to install on all operating systems. The most anticipated release package--a simple zip file for windows--I present now, without further adieu:
ENIGMA R4 install-ready zip, for Windows
ENIGMA R4 install-ready zip, for Mac (mac sdk has to be preinstalled)
For this phase of the testing period, please unpack the zip and run ENIGMA.exe. It should take care of the rest for you, provided you have Java installed.
When the MinGW installer gives installation choices, just make sure G++ is checked in addition to the default.
When LGM prompts you to fetch libraries, leave the default selection of Stable as your choice, and choose Yes. This will start the installation process. Depending on your internet connection (which will need to remain up for install), this may take upwards of two minutes. It is a one-time install. Your first compile will complete the installation, and depending on your processor, can take the same amount of time. Use only "Run" for now, if you would.
Let me know how the installer treats you. Post any problems with installation here, and any other bugs on the tracker.
The reason for the delay is the amount of effort that went into setting up an update system and the user-defined functions system. Everyone who likes those features owes IsmAvatar a huge "thank you." I personally believe she did an outstanding job on the matter.
For now, C++ Definitions are persistent throughout all games, but can be saved or loaded. We'll get around to fixing them to be game-local eventually.
Happy coding, and I sincerely hope you enjoy the release.
The contents/links of this page may be outdated. We have instead starting hosting our installation links and directions on the wiki: http://enigma-dev.org/docs/Wiki/Install
It's been a long road. So much has come and gone, and even just changed slightly, since the release of R3 near the end of 2008. R3, as most of you know, was basically a proof-of-concept. It demonstrated that with a little effort, it is possible to take something like Game Maker and compile it for a number of advantages. Since then, ENIGMA's philosophy has changed by leaps and bounds. What started only as a spite-fueled attempt to compile GML has evolved into a nonstop effort to develop the better scripting language.
R3 brought most of GM's language functionality to the compiled world, and with some limitations, most of C++'s as well. R4, however, has shattered the boundary between the two.
With R4's new setup, the system is astoundingly extensible, and even faster and more efficient than ever before. The newly designed instance system functions like a dream, handling the more thought-consuming concepts such as heredity automatically, by nature of its design.
C++ functions and containers are available to anyone who wants to #include them in the new resource, so far called "Definitions." By that mechanism, anyone can create C++ structures and functions for use in ENIGMA games. Even with a (constantly shrinking) list of missing features from R3, ENIGMA has never been in a better condition.
That said, as has been hinted, there is much left to do. The main system is in place and has undergone basic testing. But this release marks the public beta of the final product. Please report any and all errors you encounter immediately.
The first challenge on our list of things to work out in the beta is actually getting ENIGMA to install on all operating systems. The most anticipated release package--a simple zip file for windows--I present now, without further adieu:
ENIGMA R4 install-ready zip, for Windows
ENIGMA R4 install-ready zip, for Mac (mac sdk has to be preinstalled)
For this phase of the testing period, please unpack the zip and run ENIGMA.exe. It should take care of the rest for you, provided you have Java installed.
When the MinGW installer gives installation choices, just make sure G++ is checked in addition to the default.
When LGM prompts you to fetch libraries, leave the default selection of Stable as your choice, and choose Yes. This will start the installation process. Depending on your internet connection (which will need to remain up for install), this may take upwards of two minutes. It is a one-time install. Your first compile will complete the installation, and depending on your processor, can take the same amount of time. Use only "Run" for now, if you would.
Let me know how the installer treats you. Post any problems with installation here, and any other bugs on the tracker.
The reason for the delay is the amount of effort that went into setting up an update system and the user-defined functions system. Everyone who likes those features owes IsmAvatar a huge "thank you." I personally believe she did an outstanding job on the matter.
For now, C++ Definitions are persistent throughout all games, but can be saved or loaded. We'll get around to fixing them to be game-local eventually.
Happy coding, and I sincerely hope you enjoy the release.
90
Announcements / Mini Progress Feed
« on: August 28, 2010, 06:26:16 am »
They say coordinating programmers is like herding cats.
Well, if herding cats is this disinteresting, I believe them.
Anyway, I have truly no idea where everybody is. I swear LGM still isn't rebuilding ENIGMA for me on Linux. I think Retro's done with his packages, and I think they only contain the essentials now, but I'm not certain. Last I heard he was uploading them at 80kbps, with an ETA of 18 hours or something? It wasn't exactly encouraging.
Anyway, I wanted Ism to get our new C++ resource working (as in, saving) before the release, as it is the method by which users can create and share C++ functions. With it, you can take part in ENIGMA's development, whether by implementing your own C++ functions or by including other users' to test or for personal use. The resource has many applications outside of the beta program; I know it'll become a crowd pleaser over time. Especially when I finish what I'm working on right now.
Basically, I have three things in my scope at the moment:
1) var[x,y]
2) room order: base off resource tree, not ID
3) OBJ.varname
Presently, I am working on the third. It worked in R3, but was so inefficient I decided to replace it early on, but didn't finish it.
When that is done, with() should start working also.
I added backgrounds to the executable, but I don't do much with them at the moment. I didn't want to add tiles until I worked out a depth system that agreed with the way I read events from a YAML configuration file. As it stands, the compiler doesn't ship knowing the name of a single event: How am I supposed to give draw event order special behavior?
Actually, the answer just came to me (Which is odd considering the hour; I think I had the idea before). In essence, the special variable I'll need to instantiate for depth will insert its call into the correct depth layer on construct. On assign, it unlinks and re-inserts. On destruct, it unlinks finally.
Okay, that solved, I'm going to sleep, then finish OBJ.varname so with and such works. To-do to finish that:
1) Keep list of `member` instances parsed as "access_%1"
2) Add that function to the usable function list so as to avoid a.b.c mis-parse.
3) Check variable data from all objects for type conflicts
4) Generate the access functions based off data from all objects
Next I'll do var[x,y] (needs replaced with var(x,y)), then rooms (needs double-buffered: one array by room ID, one non-sparse array for quick traversal.
Mac progress... Good on my end, waiting for update from TGMG. Must have fixed ten problems. Looking promising.
For now, good night.
Well, if herding cats is this disinteresting, I believe them.
Anyway, I have truly no idea where everybody is. I swear LGM still isn't rebuilding ENIGMA for me on Linux. I think Retro's done with his packages, and I think they only contain the essentials now, but I'm not certain. Last I heard he was uploading them at 80kbps, with an ETA of 18 hours or something? It wasn't exactly encouraging.
Anyway, I wanted Ism to get our new C++ resource working (as in, saving) before the release, as it is the method by which users can create and share C++ functions. With it, you can take part in ENIGMA's development, whether by implementing your own C++ functions or by including other users' to test or for personal use. The resource has many applications outside of the beta program; I know it'll become a crowd pleaser over time. Especially when I finish what I'm working on right now.
Basically, I have three things in my scope at the moment:
1) var[x,y]
2) room order: base off resource tree, not ID
3) OBJ.varname
Presently, I am working on the third. It worked in R3, but was so inefficient I decided to replace it early on, but didn't finish it.
When that is done, with() should start working also.
I added backgrounds to the executable, but I don't do much with them at the moment. I didn't want to add tiles until I worked out a depth system that agreed with the way I read events from a YAML configuration file. As it stands, the compiler doesn't ship knowing the name of a single event: How am I supposed to give draw event order special behavior?
Actually, the answer just came to me (Which is odd considering the hour; I think I had the idea before). In essence, the special variable I'll need to instantiate for depth will insert its call into the correct depth layer on construct. On assign, it unlinks and re-inserts. On destruct, it unlinks finally.
Okay, that solved, I'm going to sleep, then finish OBJ.varname so with and such works. To-do to finish that:
1) Keep list of `member` instances parsed as "access_%1"
2) Add that function to the usable function list so as to avoid a.b.c mis-parse.
3) Check variable data from all objects for type conflicts
4) Generate the access functions based off data from all objects
Next I'll do var[x,y] (needs replaced with var(x,y)), then rooms (needs double-buffered: one array by room ID, one non-sparse array for quick traversal.
Mac progress... Good on my end, waiting for update from TGMG. Must have fixed ten problems. Looking promising.
For now, good night.