ENIGMA Development Environment
Website is in read-only mode due to a recent attack.

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.

Messages - Josh @ Dreamland

Announcements / Re: Another quickie
« on: March 23, 2010, 07:50:28 AM »
> I didn't know that he was this engaged in the project. Good to hear
This was only a recent thing, after this was posted on the GMC: http://gmc.yoyogames.com/index.php?showtopic=468479

He didn't post it, but it was inspired by him. Try not to laugh at the GMC nubblets.
"Yes, it's legitimate. Zach (the developer), has been working on it for a few days now."
"been working on it for a few days now."
"a few days now."

Anyway, the truth behind it is, (and I feel confident posting it here since none of the GMC nubblets will find this post and have their hearts broken) he just wrote something that loads GM resources. He did the programming of his test game himself. Since converting GML to C++ is a decent undertaking, I figured he may as well team up with us rather than put in his own individual attempt at converting the code. I'd have done the same with G-Java, except I prefer C++. He doesn't have a choice in his language. XD

> Can't you email them and ask for the source or some other kind of help?
These people are GNUs. They believe in Google and Doxygen, not in helping people.

Announcements / Another quickie
« on: March 23, 2010, 07:27:24 AM »
Boy metaphase is taking a long time (For those who are expecting it, hehe).

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

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

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

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

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

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

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

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

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

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

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

Function Peer Review / Re: Brainstorming
« on: March 23, 2010, 07:00:55 AM »
Nice to see so many people taking interest in coding things.
... :P

They probably want to wait for a new working version before they start coding. Those who will do any coding for the project at all, I mean. I don't blame them, really.

Besides, 'Whitespace' will make it so they can implement their functions in C++ just as it will look if included in the release, and will let them test their new functions themselves.

Announcements / Re: Another choice.
« on: March 21, 2010, 06:41:30 PM »
Yeah. I believe with() is Delphi, but I'm not certain. It'd make sense if it was. You can see it in JavaScript as well.

Off-Topic / Re: Essay
« on: March 19, 2010, 09:19:02 AM »
Heh, it's just where you pretend to know what you're talking about by writing a paper on a topic you may or may not have any interest in.
Anyway, I'm done now, but am currently dealing with other personal issues and should be back to work in a few hours following school today.

Announcements / Re: Another choice.
« on: March 18, 2010, 09:28:47 AM »
Posted about having to write an essay elsewhere. I'm nearly done.
Ism's getting Java to pass resources to DLLs and the like.

Off-Topic / Re: Essay
« on: March 17, 2010, 10:53:46 PM »
Yes, I did mean libraries in general, but I will use DLL because most users can relate to that name better, and I'll probably use EXE because Unix doesn't have an extension and "exe" is short for "executable" anyway.

Off-Topic / Essay
« on: March 17, 2010, 06:11:31 PM »
I'll be essaying for the next day and a half or so.

Didn't think it was worth a news post.

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

Announcements / Re: Another choice.
« on: March 17, 2010, 06:10:50 PM »
If it's of any consolation, I replied to you in the wrong thread.

Announcements / Re: Another choice.
« on: March 16, 2010, 05:41:32 PM »
Oh, you're right. I should just include the GCC with it like you first said; wouldn't want to risk the project looking "stupid" to someone.

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

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

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

Announcements / Re: Another choice.
« on: March 16, 2010, 01:13:42 PM »
Would be too big and slow to include GCC with everything. I'll need to write a fifty-some line parser to make GML look like JavaScript, then presto.

Announcements / Re: Another choice.
« on: March 16, 2010, 12:33:34 PM »
Directly converting GML to C++ is impossible. They should not expect it.

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

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

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

a = 0;
var a;
a = 3;

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

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

Did I mention it's JIT compiled?

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

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

Announcements / Re: Another choice.
« on: March 15, 2010, 08:59:34 PM »
Didn't want to bring up that difference in example code of another difference.

Announcements / Re: Quick Poll
« on: March 14, 2010, 03:39:08 PM »
Like I said, C++ people make this particular mistake a lot. It happens, and it could likely piss people off.

Announcements / Re: Another choice.
« on: March 14, 2010, 12:44:11 PM »
Game_boy: Should make that a priority, actually.

All of those will. Even global var, which will be done like so:
#define globalvar global var