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.

Topics - Josh @ Dreamland

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 »
Announcements / News points
« on: March 19, 2012, 10:25:46 pm »
Greetings, all; I have a few small pieces of news to report.

First and foremost, recent parse progress is here. Lines 2-110 were read in by the program as input; lines 114 and forward are complete program output. It should be a completely capable C parser by the end of tomorrow. Note: I said "C" parser, not "C++" parser. The difference being massive.

Second off, Gary is working on our mailserver issues. New members can't register at the moment because the server is incapable of sending mail. For those of you who have attempted to register, please hold tight, we will resend your emails once the mailserver is back up.

Lastly, I have added two BBCode tags.
The first is called "bubble." [bubble]This is the default bubble[/bubble]. You can also specify your own color [bubble=red]for maximum overkill[/bubble].
The second is called "snip." I introduced this tag in the past in a custom BBParser, but now I added it to SMF. The snip tag allows you to put snippets of code inline with the rest of your sentence. To demonstrate, I will give usage.

The code [snip][bubble]Hello, world![/bubble][/snip] gives this: [bubble]Hello, world![/bubble]

The code [snip][bubble=green]Hello, world![/bubble][/snip] gives this: [bubble=green]Hello, world![/bubble]

The code [snip][snip]Hello, world![/snip ][/snip] gives this: [snip]Hello, world![/snip]

And now you know everything.

Perhaps later I will add syntax highlighting again and we can all live happily ever after. Perhaps.

Proposals / New ENIGMA Implementers' API; this concerns all developers
« on: March 15, 2012, 09:16:17 pm »
As the new parser approaches completion, it is time to start considering the implications. I have already made the executive decision of implementing half of this in the past, but what has been implemented will need some recoding, and the new parser allows for marvelous new extensions I would like to take advantage of. As such, I figure it would be good of me to draw up this proposal both to inform developers and open the floor for comments before they are implemented.

Developers heretofore have used the global [bubble]enigma::instance_event_iterator[/bubble] to determine the current instance and interface with its locals. At first glance, there's nothing wrong with this, but when we really consider its implications, we start to see its limitations:
  • Threads cannot manipulate this variable concurrently.
  • Sideways casts between virtual ancestors cannot be made correctly in other files.
  • Functions which change scope must synchronize their use of this variable.
  • This variable does not, in itself, affect the scoping of scripts and functions called therein.
We can correct all of this by having reflexive functions, such as [snip=edl]instance_destroy()[/snip], take an additional parameter, [bubble]_E_SELF[/bubble], of a particular C++ instance type (eg, [snip=edl]_OBJ_object0*[/snip]).

This is similar to the mechanism with which you are likely already familiar, the  [bubble]varargs[/bubble] type, which allows you to request an stdargs-like overload which you can treat like an array of parameters. It is similar in that each of these are semantics that can be declared in C++, but only used in EDL via the intervention of the parser.

The proposal, then, is as follows:
  • Any parameter with the type [bubble]enigma::varargs[/bubble] will be allowed to be passed an infinite number of parameters, as an array. The parser will handle packing the parameters given into the array in an efficient manner.
  • Any parameter with the name [bubble]_E_SELF[/bubble] and a pointer-to type will be invisible to the user and filled in by the compiler with a pointer to the instance in question, meaning [snip=edl]this[/snip] in events and member scripts, and [snip=edl]with->inst[/snip] in [snip=edl]with[/snip] statements.

The lexical stipulations should be my concern rather than yours. Basically, don't assume you can do anything stupid. For instance, the following is a set of legal overloads:
Code: (cpp) [Select]
int max(double, double);
int max(double, double, varargs);
While the following is ambiguous:
Code: (cpp) [Select]
int max(double, double);
int max(varargs);

The reason, of course, is that if you pass it two doubles, both functions are equally logical choices. Now, I could choose to give weight to the concrete matches precedence, but I'm asking for your opinions on that, first.

Now, as for the [bubble]_E_SELF[/bubble] parameter, if you think you have a better method of unambiguous identification for this which corrects issue (2) given above, let me know. Or, if you prefer a different name, such as just SELF, let me know as well. Otherwise, this will be the new format for the prototype:
Code: (cpp) [Select]
void instance_destroy(enigma::object_basic* _E_SELF);

So, post suggestions, or be aware that these two modifications mean changes to the API, including existing functions.

Floor's open. Be informed. Feel free to contribute.

Announcements / Why does it look like nothing's happening?
« on: March 03, 2012, 07:46:33 pm »
Yes, we're having some "Git problems." Ideka just suggested we switch to Mercurial, in fact, but it'd be pretty pathetic if some trouble with our choice of version control software was causing us all this hassle. In reality, there are a number of nasty things afoot.

Our only issue with git's capabilities is its inability to store binary files, something SVN never showed its issues with. The rest of the issues all had to happen eventually, it's just that by switching to git now, we've busted the grand problem piñata.

The other issues are all related to deployment. What's worse is that a new STDC just hit the mainstream repositories on Linux, and ENIGMA's current parser doesn't get along with it. That timing is in itself bad, because I am just now recoding that parser anyway to be able to share code with ENIGMA.

Now, the rotten, dried up cherry on top of this shit sundae is that the forum's having email trouble, so new registrants can't get their confirmation email. I can't say whether this is related to the influx of new users whom we are only managing to confuse to tears with the endless--to borrow HaRRi's word--maze that is the installation process on ANY platform now. But there's that, too.

So, everything is tangled, and along with general bugfixes, IsmAvatar and I are working hard to untangle it. In addition to that, you probably can't see the progress from the forum because the project has been split into separate pieces now. The part of the parser I am working on is a separate project in itself now. I hope that this will improve its chances of being adopted by, for example, IDEs that need definitions for code completion. This is a large-ish aspiration due to the diversity of code with which the parser needs to be able to interface, but never say never.

Proceed with Comments/Concerns/Complaints/General Hatemail.  Except cheeseboy.

Announcements / Update
« on: January 31, 2012, 12:21:23 am »
Before we acquire any more UNICORN PORN, I would just like to bring you up to speed on the happenings, which have been few and far between.

This is the tentative parser plan:

The groupings are not completely accurate as there are "logical groupings" not represented in code, but instead in dependencies. I'll draw those in after I've worked out exactly what those dependencies are.

As for the git migration status, we've had a whopping success. The IRC bot is now capable of probing any of the subprojects composing LGM and ENIGMA, which are all on Github. No changes have yet been made to the installer as installation will now be more directed. We will, before the first git release, refactor ENIGMA to not require write access to its own directory, which will enable us to install to the program files, or to /opt/ or /bin/ on Linux.

More to come, but for now, I'm tired.

Announcements / Neat Stuff
« on: January 06, 2012, 09:48:41 am »
I was working on this new parser yesterday, and I thought it'd be kind of neat to make my AST generator export SVGs. So I did.

So, given this expression: 2 << 1 + 6 / 2 - 2 / 2 << 8 % 5 + 5 / 2

The AST looks like this, step by step:

ast << create_token_dec_literal("2",1);

ast << create_token_operator("<<",2);

ast << create_token_dec_literal("1",1);

ast << create_token_operator("+",1);

ast << create_token_dec_literal("6",1);

ast << create_token_operator("/",1);

ast << create_token_dec_literal("2",1);

ast << create_token_operator("-",1);

ast << create_token_dec_literal("2",1);

ast << create_token_operator("/",1);

ast << create_token_dec_literal("2",1);

ast << create_token_operator("<<",2);

ast << create_token_dec_literal("8",1);

ast << create_token_operator("%",1);

ast << create_token_dec_literal("5",1);

ast << create_token_operator("+",1);

ast << create_token_dec_literal("5",1);

ast << create_token_operator("/",1);

ast << create_token_dec_literal("2",1);


Announcements / Happy New Year!
« on: December 31, 2011, 04:50:28 pm »
I'm tired as ass. And sick as a dog.

Really, though. I hope that 2012 is a great year for everyone. Except Yoyo, I mean. Obviously.

Announcements / Merry Christmas!
« on: December 25, 2011, 01:05:50 pm »
Just posting to wish everyone a merry Christmas and whatnot.

I've not seen Ism in a few days, but polygone and HaRRi are working on this and that, and I've committed the first revision of my new C parser. Forgoing future holiday distractions, I should be done with it in the very near future; possibly before this year is over.

Not sure about you people, but I have things to celebrate and family to visit.

Cheers, of the Christmas variety.

Announcements / Ludum Dare 22
« on: December 19, 2011, 12:52:43 pm »
So, the next Ludum Dare has come and gone. ENIGMA's entrants have nearly doubled this round, increasing from two last time to a whopping three.

DeadlyFugu's ToastCat (Which is not a total nyan-cat ripoff).
Dazappa's The Last Leech.
My own OH COME ON.

Rusky also entered, but his game is in GMHTML5 and it blows (Also, I don't have a link to it and am too lazy to ask).

This was another huge learning experience for myself. I have a laundry list of about 15 bugs to deal with, right after I get the build system more operational.


Announcements / Documentation
« on: December 13, 2011, 10:40:59 am »
We've had an influx of new members, lately, and while I can't be certain that more than a few of them are humans rather than AI-complete spam bots, much less attest to how they found us, I do know that ENIGMA's wiki is among the first (often the first) Google result for many GM functions. Issue is, our documentation on them was laid out by a bot, and thus is incomplete.

What I'm getting at is that the Wiki is likely how people have been or will be stumbling upon our site, and it doesn't look very good if we've got a thousand undocumented functions people are looking for information on. My first order of business upon finding an undocumented function in a Wiki is to curse and leave, not investigate the project.

That said, I'd like to divert some focus to it, and I'd certainly not mind help. If you would like to contribute to the project in some way, helping document the function on the Wiki would be a good one. Please refer to: Feel free to read that if you're in the mood for a novel, or just head to and start filling shit out.

Anyway, as for the state of the rest of the project:
  • Ism and I have been working on integrating the new text editor, of which we have been releasing test versions in the IRC. We won't be committing anything until we're sure nothing is getting trampled by it.
  • Polygone has been working on the 3D functions, as you can probably tell by the 3D games showing up on the EDC.
  • I've been working on the new C parser, which I will be keeping as a separate project on which ENIGMA will "depend" (we'll be keeping a copy of it in our repo, same as always, so don't worry).

So basically, the only source of commits lately has been Polygone working on 3D, since the rest of us are working on chunks of software with which to replace existing chunks.

Cheers; go work on the Wiki.

Announcements / EDL 3 Proposals
« on: December 02, 2011, 11:25:03 am »
By my calculations, this will be the third time we've changed EDL's featureset considerably. In the beginning, I was just going to support GML as laid out in 6.1. Over time, I decided, "fuck that, we need real constructs and language features." Since then, a lot has been changing, even in the world of computer science as a whole. For instance, C++'s feature set has grown sharply with the publishing of the most recent ISO. So basically, I guess we need to start discussing EDL tuneups before I go ahead and write up the new parser.

Biggest changes proposed:
  • Use of C++ struct keyword in plain EDL. Since I started that JS port, which I thought TGMG was running with but I now guess is still my problem, a lot of turbulence erupted in maintaining a useful, cross-compatible language. While the Definitions resource provides excellent extensibility to the C++ version, some elements missing from GML are too basic to require to be defined in their respective languages. What I'm saying is, JavaScript makes it a bitch to define classes unless you understand what exactly a JavaScript class is, and this is likely the case for other languages we may support. The bottom line is, it would be nice if ENIGMA provided a syntactical wrapper for useful basics like structures.
  • Rusky is getting his Lambdas. Now that C++ supports Lambdas, I don't see why not to support them in EDL.
  • Inline array declaration. EDL is in dire need of some way to put numbers into arrays adequately.
  • A more elegant preprocessor system should be available to the users. C has preprocessors that change how your code looks before it compiles. If you've used much EDL at all, you've used them, probably without noticing it. I would like to share that system with users; the issue is, C's are really ugly, and really bulky.
  • EDL's understanding of types is getting an overhaul. We will now ensure that complicated expressions don't trip up the compile because ENIGMA can't adequately cast them. With this comes support for ENIGMA's varargs class.

Now, the point of this thread is to present what we want added, get more suggestions for what to add, and also, to deliberate on how these features will interact when they are added.

For example, how do we want Lambdas to look? How do we want arrays to look? How do we want preprocessors to look?
Originally, my proposal for preprocessors was [[ifdef BUILD_WINDOWS]]do_something_with_the_registry_or_something()[[endif]].
And, well, most languages use [...] for arrays. [1, 2, 3, 4, 5].
And, C++ uses [] to indicate lambda. [](int a) { return a + 1; }

So, with a good enough parser, no worries, right? Not really; some of these get ambiguous.
What if I want a singleton array of a singleton array of a variable called pragma? [[pragma]]. Oops. Even if ENIGMA got it right, the highlighter wouldn't, so it'd be ugly as hell. So, do I ask users to simply put spaces between their brackets? I think not. The best option is to use something else for one of them. For example, [%ifdef BUILD_WINDOWS%]. Since % is a binary operator, any mention of it after a [ or before a ] is invalid. So now, how to distinguish [] as an empty array and [] as a lambda? I think that'll mostly take care of itself, since in a lambda the next token must be ().

With that, here are our current proposals:

C++ structs
Can be used in any code that uses the structure individually, declared for the whole object with local struct, or declared for the whole game with global struct. The latter will require reparse of the entire game, similar to placing the structure in definitions. As such, it may be dropped or discouraged.

Rusky's proposal for lambdas is to mirror C#'s syntax. mylambda = (x,y) => { x + y }. For simpler expressions, square = x => x*x

Inline Arrays
Basically, [] instantiates an array of variants as its own class, including a length member. There would be functions taking Array& as an argument. Var would be able to easily produce an Array& in O(1), and there would be a var::var(Array) constructor. What this means is, you'd be able to do this:
Code: (EDL) [Select]
var a = [1, 2, 3, 4, 5];
a = reverse(a);

Array assign
One of MATLAB and other language's brighter ideas, this could be enabled with a special case in the parser:
Code: (EDL) [Select]
var a, b, c;
[a, b, c] = get_abc();
Where get_abc(); returns Array.

Some things I'm presently pondering:
1. Can the new parser have the ass to choose between mean(double,double), mean(varargs&), and mean(Array)?
2. Can we scrap Array altogether and just use var, or would a separate array class be more efficient?

So anyway, if you don't like a proposal, if you have a better idea, or if you have something new you would like to see in the language, let us know.

Announcements / We can't decide
« on: November 03, 2011, 12:46:26 pm »
The ENIGMA project has hit a snag recently. Basically, our collective ideologies have become tangled.
It looks something like this:


Ism and I are both sorting issues with our projects. Ism is dealing with Java's ill-equipped generics, trying to structure LGM to be more extensible for future releases. As far as you need to be concerned, this is so we can add our Definitions and Overworld resources, as well as other potential resources down the road.

As for myself, right now I am dealing with a small issue regarding a dynamic type that implements implicit accessors and setters for generic data, which has presented a number of "how should I"s, but in the big picture, my concern is for the progression of ENIGMA's parser.

One point is certain: I need to rewrite or do serious work on the C parser. ENIGMA is presently ill-equipped to make distinctions between the following sample lines:


This has led to issues in interpreting some GM6 code unless extraneous parentheses are added, which is unacceptable to newcomers, as well as to issues implementing some of C++'s more desirable features, such as complicated ternary expressions. This is because ENIGMA needs information from C.

The purpose of the C++ parser—be it the current one, a rewrite, or Clang—is to provide ENIGMA's EDL parser with information about available types, functions, and other constructs. For example, ENIGMA would not know what var a; meant if the C++ parser couldn't understand var's header, and it would not understand what show_message was if it could not read function definitions. The parser also needs to be able to resolve complicated types for further error checking. Hence, we need some mechanism of parsing C++ sources accurately enough for ENIGMA to produce correct C++ code.

I am faced with two options which I have filtered out as the best.

  • Rewrite the C++ parser to support the new ISO and to better support the old.

    This will mean partitioning ENIGMA's compiler into two projects—one to parse EDL, and one to work with C++—and maintaining them both. I would choose to split the two so that any other party interested in parsing C++ could potentially join in, though it has proven in the past to be unlikely for this to happen.

    The benefits of doing this would include minimalistic size and features tailored specifically to ENIGMA and similar projects, meaning—if I code it right—it could potentially work faster than Clang due to a lack of need to lex and check code inside functions. The resulting project would also be less than a megabyte in size (ENIGMA's current hand-rolled C++ parser is 300 KB of source).

  • Drop the existing C parser altogether and outsource to Clang.

    Clang is an LLVM frontend. Certain members of this forum, I'm sure you're aware, blow lots of smoke about LLVM, but in general we would want to avoid it because it will run users somewhere between half a gigabyte and a complete gigabyte of disk space, and MinGW LD/MSys would still be necessary (which is presently the largest component of ENIGMA).

    Clang, and its support for LLVM, would bring unprecedented benefit to the project, but not unwarranted benefit given its size. If ENIGMA was compatible with LLVM, by nature of the huge amount of support for the LLVM project, ENIGMA would be able to use, export to, and interact with a half a dozen other languages, notably JavaScript, Lua, Python, and an interpreter for C++ which, depending on its speed, could mean a native method of doing execute_string(), or could just be something crappy to avoid (we have only just learned of its existence, and I have little faith in the ability of anything to both parse and interpret C++ in a reasonable timeframe). In short, we would be getting not only C++ functions, but Lua and JavaScript functions as well, if desired.

    The issue is not only the huge size. Ostensibly, I could invest a few hours each update into isolating the segments of Clang required to simply parse C++ and give me info about it. Therein lies the issue; I am well aware that at this point, Clang sounds like the clear choice, but whether or not I choose Clang, I am left with something to maintain. Getting just libclang, its Clang dependencies, and the necessary headers from the LLVM svn to compile alongside ENIGMA will take work, research, trial, and error, and will cost about 50MB in the SVN. Then any time Clang updates something, I have to try updating my copy without stomping all over the modifications. I can't measure at the moment how messy it will be; only that the process is not streamlined.

That said, I am torn between the two options. I need people to say, "50 MB and a potential shitton problems that aren't yours, in exchange for four languages? That sounds worth it to me!" Or to say, "for that price, just write your own."

TL;DR version:

(1) Custom(2) Clang
Tiny (Less than 1MB); fast, pointed runtime50 MB; Parses EVERYTHING, though quickly
Gives precisely the needed information, no more, no lessGives general information that can likely be used to meet all of ENIGMA's purposes.
Supports interfacing with other languages (Lua, Python, JavaScript) at the cost of hundreds of megabytes on top of Clang
Likely to be sole maintainer, responsible for all aspects including any potential errors. This would be no different from now. At worst, it could mean a second recode in the future, but ideally I would make the code sufficiently extensible to prevent that this time.Maintenance involves separating Clang from LLVM as cleanly as possible every time an update is made; any parse errors are not the responsibility of the ENIGMA team, and may or may not be dealt with in a timely manner. Potentially, we'd be facing another MinGW fiasco. (See #13297)

Additional Q/A:
dazappa: Clang is a "frontend to LLVM." So you would use Clang but not LLVM? And what's the final size decision, 1gb or 50mb?
Josh@Dreamland: Well, clang has LLVM dependencies, so I would be cutting LLVM into little pieces and throwing away the ones I don't need. 50MB is the projected size after I throw away the little pieces.

dazappa: Would you rather maintain 50mb of shit that you don't know, or 1mb of shit you do?
Josh@Dreamland: Good question. Ideally, for Clang, the maintenance would just be updating Clang headers, adding any more pieces of LLVM that become necessary, and making sure it compiles as though the configure script had run. Maintaining a megabyte of C++ parser can be just as difficult, if not more so as my responsibility extends beyond making sure it simply compiles.

dazappa: Well, you failed to write the C++ parser happily the first time, so you think you'd be able to do it better the second time? Using clang might save you time if you can get it setup and be able to easily update the headers like you think.
Josh@Dreamland: I do think I'd be able to do better the second time. As you can see, the current version succeeds for the most part, with one warning it throws three times. If I code the second version knowing everything I do from the first, and with all that shit in mind, I should be able to get it to play nice.

dazappa: ...Until you realize you have to rewrite it for a 3rd time.
Josh@Dreamland: I'm going to use a system very similar to the recursive descent scheme Rusky talks about. Basically, it would use the body of the current C parser, which invokes a function to handle the token in the context of each statement. Instead of calling this big mash-up switch statement that makes a hundred if checks, the parser would call one function based on the current context and pass it the token, and that function would deal with it appropriately. This means adding a new type of statement to the list would be pretty easy.

Go to town.

Proposals / Overworld Resource
« on: October 19, 2011, 10:13:28 am »
Formal proposal time, now that EGM is finished.

Anyone who has tried to make large, complicated rooms in Game Maker has been either bitterly disappointed or ingeniously crafty with regard to GM's rather limited room editor.

The quintessential example of a game that's fucking hard to make in GM is a Metroid platformer. There are two ways to go about the layout of a Metroid game in GM: There is the traditional method of creating a room for each little passage and cranny and using a complicated network of global variables to determine where you are coming from and where you are going, or there's the perhaps more advanced method of creating a large room of room-editor-lagging proportions and then using instances to denote regions to activate or deactivate as needed.

I have, in my longish and complicatedish game making history, made both a 2D and 3D Metroid Platformer, using a version (albeit a crude one) of the above strategies. It's quite possible that I've missed a strategy more form-fitting of Game Maker's... capabilities, but even in retrospect, I am not seeing a better way of pulling it off.

Enter EGM. Enter Overworld Resource.

Now that the EGM format is complete, we are capable of extending the existing room resource and adding a new resource on top of it.

Extending the room resource, we would allow for users to define their own "regions," as MrGriggs called them when he suggested them. These regions would be simple geometric shapes (possibly just box and circle) which, using a new set of room_region_* functions, the user would be able to test for being inside of. We then could have an instance_(de)activate_region function. Other modifications could be made to associate certain resource groups with regions, but this is part of another proposal I should probably post next.

Now, for the new resource, Overworld. Essentially, the overworld resource would allow users to place rooms into a larger room editor, the overworld editor. Ism would pre-render low-resolution previews of the room (she could fetch larger previews upon zoom) and allow users to place them in correct proportion on the Overworld map. A set of functions would be provided to get the full rectangle coordinates of a given room in the map, and contiguous rooms could be mapped together to allow quick searching for neighbors.

With that in mind, rooms could be easily reused without a complicated network of user-defined globals, such as room_to_left, room_to_right, room_above, room_below, or, worst of all, x_coming_from, y_coming_from.

Using the Overworld function set, a user could convert x-y room coordinates to x-y overworld coordinates by adding overworld_get_room_x(room_in_overworld) and overworld_get_room_y(room_in_overworld). The user could then translate those coordinates in the appropriate direction so as to leave the current room (essentially walking the character over), then make two calls to overworld_ functions to determine which room is actually going to be entered, and convert the overworld x-y pair back to room x-y pair after the room has been reassigned.

This topic is a good place for argument as to the exact functions to be made available, and this wiki page is a good place to put the results:


Announcements / Ludum Dare
« on: August 22, 2011, 02:04:12 am »
So today concluded the 21st Ludum Dare competition. I didn't make this public due to the fact that it was a last-minute decision made twelve hours into the 48 hour contest, but I decided to enter. Dazappa did as well.

Here are our games:
Dazappa's Crystal Conduit
My own Cave Escape

Okay, so my title's not that creative. Nor is my game itself, really. Point is, the two of us entered this competition.

For those who are unfamiliar, the Ludum Dare is a 48 hour game making competition. Competitors are given precisely that long to develop and "perfect" their games. Hence, my engine has serious physics and collision issues, and I imagine dazappa would have preferred more time, too. This year, with Notch from Minecraft participating, the server was so overloaded with interested peoples that they had to extend the deadline to give people a chance to wait out the server issues.

While, given the competition (especially this time around), it is astronomically unlikely for either dazappa or me to win, that was not the reason I entered (though I'd certainly not mind if one of us did win). I can't speak for dazappa, but I entered for three reasons,

1) To put ENIGMA to the test and show what it can do
2) To register a blip on the engines radar in the name of ENIGMA
3) As a learning experience for myself

At this stage, you'd think I wouldn't have that much left to learn about game design, right? Well, you're wrong, but that's beside the point. I wanted to learn not about game design itself, but game design in ENIGMA. Using only the features of ENIGMA a typical user would utilize, I discovered quickly a small number of bugs, quirks, and features that should be added. While most of the features I thought would come in handy were already planned, I did manage to come up with a few extras. Here is my list of discoveries made, bugs to fix, and features to add:

  • Any sort of iterator tampering in draw will kill you. Not just depth change; room change as well.
  • Initializers are ignored while parsing with() statements. For example, with (object) { int a = x; } will use x from the calling scope.
  • Script scoping is incorrect in with(). This->script() is used when ::script() should be instead (::script is a global copy that sets scope manually via with()).
  • LateralGM's highlighter and code editor in general suck. We should probably finish the one I mostly finished.
  • Multiple inheritance is a must for complicated games. Also, LGM has an inheritance loop checking issue in which the check seems to return parent->parent != null.
  • switch() {} doesn't coerce enums; this is an issue because switching sprite_index will be an O(N) operation unless you hard-code the IDs.
  • The instance creation codes in rooms should be bumped up in priority, and it should be easier to enumerate and manage those codes.
  • It's high time for ENIGMA array literals. And, well, a new type resolver so it can tell what's an array.
  • The room editor needs a way to drag select and move efficiently.
  • Design mode would really expedite platform gaming development, and a slow-motion feature should be added to it (something to quickly set room_speed.
  • Since the collision system depends on the positioning tier, which contains hspeed and vspeed, an option should be allowed to let the user control the two.
  • I found myself really wanting the planned "Overworld"/"Map" resource.
  • I've still not fixed local const.

Other issues: Does instance_count grow with each create event at room start in GM as it does in ENIGMA?

Other than that, I was mostly in a pissy mood at IsmAvatar, because I encountered about 60 problems that EGM would fix. No ++, no alpha channels in the default format (GM6) (This cost me another our of work), no way of declaring C-level globals.

Also, polygone's framerate fix fucked me a bit, because it only fixes it on his computer, and packing AL in with the engine made filesizes huge. Something needs done about those two, too.

At that, I'm tired. Good night.
If anyone else entered the Ludum Dare, do let me know.

Announcements / New Hardware
« on: August 17, 2011, 02:28:07 am »
In case you missed that MASSIVE fifteen minute downtime (longest fifteen minutes I've ever waited patiently through as CPanel did all the work)... *cough*

Let's try this over. Hello, everyone! We're on new hardware.

Everyone give a big thanks to the following:
= IsmAvatar for forking over half the price of the server
= Gary for installing the gobs of software we apparently depend on
= a2h for debugging his CSS and apparent dependency on the aforementioned software
= And of course, me, for my expedient remedy of all other aspects of this migration

Now you should be able to click a fucking wiki link without sixteen minutes of latency.

@a2h: these fonts are oversized and hideous. Please fix them.

Announcements / Overdue Update
« on: July 25, 2011, 11:04:21 am »
All right, with nearly a hundred revisions since our last newspost (which was quite small), Polygone recommended that I make a new one. So here it is.

What's been done?
I implemented some of GM's syntax quirks. Assignment = to comparison ==, mostly, along with about 10 bug fixes for bugs discovered in TGMG's mass compilation sprees.

As part of this, I gutted the syntax checker, which was written before we had genuine intention of supporting C++ macros. Yeah, pretty ancient. The new one is in its early childhood (meaning half of it is written).

switch() has been implemented at the repeated request of kkg; at the moment, you can switch() anything that can be stored in "variant". Down the road, you'll be able to switch anything for which there is a switch_hash() overload. As you may have gathered from that previous statement, ENIGMA's switch() is hashed, unlike Game Maker's. This introduces an incompatibility: Putting the default: label first doesn't fuck everything over. <_< Other than that, you'll find that the only incompatibility is the massive increase in performance.

Polygone and HaRRiKiRi have been hard at work implementing functions and DND actions. Polygone, as practice while learning C++, has supplied an implementation of all data structure functions (ds_*), except ds_*_read/write() and ds_set_precision, "whatever the fuck that shit is." He also went on a DND-implementing spree; more trivial, but probably more likely to be noticed (it's surprising how many people fuss about really simple DND tiles missing, just because they threw them in random places).
As for HaRRi, he would like to just point out that C++ sucks, but that he has nonetheless (In addition, of course, to the huge number of font functions he has implemented) been working on an implementation of paths. For which, apparently, IsmAvatar has coded a writer to the EXE. You can expect to be seeing those sometime "in the next 42 years," even if I have to move them somewhere afterward.

Specifically, I would move them into the extensions directory. I spent a little bit establishing a modular system for incorporating underused variables and functions which will allow users to choose which ones they need, disabling the rest which would otherwise just be wasting memory and filesize. I have already moved alarm functions there (including action_set_alarm). With a little luck, Ism will hook that system up formally before I die of old age.

TGMG has been hard at work doing minor tweaks and function implementation to up compatibility further as well. He even wrote a quick, crude implementation of tiles (Don't worry; they're probably still faster than Game Maker's). I'll be replacing his present tile storage and drawing methods with more efficient ones down the road. Specifically, precompiled ones--there's no getting faster, assuming the ratio of fill to vertices is good (which it should be). We collaborated for a while to get some more GM quirks working, and actually made really good progress.

What does this mean for the state of the project?

Presently, our GM compatibility standings are as follows: 81 percent of GM examples harvested from 64Digits compile in ENIGMA when given fillers for missing functions. That means that the system is sound enough to manage all the dynamics of GML provided only that a few more functions are implemented in the backend. Why do nearly 20% fail? "Unforseen circumstances." Namely, they fail where GM's own syntax checker failed.

For example, take these codes:
Code: (GML) [Select]
for (;;;;;i = 0;;;; i < 10;; ;; ; ;i += 1;;; ) {}
// Game Maker doesn't care about semicolons in for(;;), so people got in the habit of doing this:
for (i = 0; i < 10; i += 1;) {}
// It's still wrong, but GM supports it.

if not_a_function
  (100001).variable = true; // GM was okay with this, because instance_nearest(x,y,object0).x would cause a runtime error.

That's right,  instance_nearest(x,y,object0).x would cause a runtime error. Not a syntax error. GM's parser was so poor, it didn't know what to make of that code either. So it did it wrong, and people took advantage of that. But now ENIGMA's left with around 200 games that do that sort of shit. Not necessarily just those two; those two are just common ones that stuck with me. I have a whole laundry list of stupid shit like that to deal with.

As for the project's embrace for C++, with the syntax checker finally supporting macros, it's looking healthier than ever. I may soon add support for full-blown preprocessors.

Anyway, wish us luck. And enjoy the changes.

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 »