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 choice.
« on: March 12, 2010, 11:17:19 AM »

Yep. Hence the poll.

I'd rather not distinguish between events, though.

Announcements / Re: Another choice.
« on: March 12, 2010, 10:51:08 AM »
That was what I was thinking at first, but then I realized that I would be saying "var int" a lot more often than "local int." And if I forgot the "var," I'd be in danger of bizarre performance.


for (var int i = 0; i < 10; i++)
for (int i = 0; i < 10; i++)

If ENIGMA moved the initialization of the local in the second example to the constructor of the object (as it should, technically), "i" would resume at 10 and the loop wouldn't do anything. That would be bad. :v:

Not to mention you'd be wasting the memory if you forgot the var. Though, that goes both ways.

Not anymore, I don't think. GM7(?) implements this syntax:

global var a;

Which they advertise as eliminating the need to use "global." in future references.
Implementing "local int a" would be no different.

Announcements / Another choice.
« on: March 12, 2010, 09:45:55 AM »
In R3, you were allowed to say "int a;" in a code piece to declare "a" as C++'s fastest type. To declare it as a local variable to the object, however, I made you say "localv int a;". Well, that system was brutally easy to implement. However, it's not so convenient to type.

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

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

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

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

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

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

Anyway, same drill as last time.

Announcements / Re: I hate the last ten days before a release.
« on: March 12, 2010, 09:35:02 AM »
The 11th plague of Egypt, retep998--
When R4 is compiling again, I'll match the list of functions from the parser against the list of functions that need done, and anyone who can code can look for a function or set of functions they feel they are capable of implementing. If you're not good with community projects, I can look them over and implement them for you.

Fetching the list of unfinished functions after that will be as simple as matching the list with the tree again.

Those who do have experience with SVN, I can probably give you permissions to commit code.

Announcements / Re: Quick Poll
« on: March 12, 2010, 09:30:52 AM »
They'll be stored in the file format for when ENIGMA queries for them.

I'm going to have a check box / radio button to decide whether to treat } as }; or not. It'll be defaulted to };. This way, we don't have users pissed off about the only feature of EDL that depends on newlines.

Announcements / Re: I hate the last ten days before a release.
« on: March 12, 2010, 08:37:01 AM »
Same difference.

Announcements / Re: I hate the last ten days before a release.
« on: March 11, 2010, 03:22:09 PM »
I'll need a bunch of people who know a good amount of C++ shortly. Will help when mass-producing GM's dumber functions.

Am hoping it's impressive (though not the first thing I release for testing, which will just be a spruced up R3 [extra parenthesis for no reason]).

Git does look rather nice, but I have yet to set up whatever key it wants me to have in order to use it, so that's a hassle. It's also not on SourceForge, so I have to change habits to use it.

Announcements / I hate the last ten days before a release.
« on: March 11, 2010, 08:52:16 AM »
Consistently, the last ten days before a release grow to twenty and then maybe thirty due to lack of coordination. It's a wonder I managed to hit within 15 hours of R3's deadline, honestly.

As has been reported, the C parser is done. There's been no reason to modify it so far, and I'm hoping never to run into such a reason.
A great deal of the other two parsers is done; more than 75% of each.
I'm to the point where I would like to start testing everything working together before progressing on either parser, however, we have a problem with that.

LateralGM has three members.
Ism's on spring break, spending time with people somewhere. I don't want to ruin it for her; she could probably use the vacation after the earthquake following the release of GM8 (which honestly, I wasn't expecting at all; don't know if she was or not).
Quadduc is apparently working on other (somewhat cooler, admittedly) projects.
Clam is pretending to go to college (Really, he's running a social experiment to see what the worst thing he can wake up to is after passing out drunk).

The good news is, Ism intends to help during boring times of spring break, and to actually come back afterward.  :v:

As for me, my college courses are on spring break as well. High school ones aren't, so I have to show up to them for two hours a day anyway. What's annoying, though, is being unable to hook ENIGMA up to LGM without Ism; there's just been too much change... And it's so close to just being done...

Presently, Ism is trying to get a simple DLL working from Java. I'm hoping JNA will allow ENIGMA to ask LGM for resource information instead of relying on it to be sent... We'll see how it turns out. The last phase could be messy.

I guess I'll continue to work half-blindly on my parser... I do wish for the batch passing of scripts to it, but whatever. There's also a timing issue with serp. He's done some impressive work on ENIGMA's library while I was working on those parsers. They're on GIT, which I hate working with. I don't know when to check out, is the problem. Having a revision system is supposed to fix that, I thought. ;_; 'S what we get for having two of them.

I'm running a couple checks for old mistakes that I corrected long ago but never released a patch for. Heh, what a ride. It's nice to be this close again.

Announcements / Re: Quick Poll
« on: March 09, 2010, 02:33:36 PM »
I meant the poll. I can't just have a checkbox for whether you want the compiler to bitch about that; you're bound to make the mistake again even once you're aware anyway.

I see what you mean now, and I like it.

Of the 14 who voted, 10 thought that it should either be the user's responsibility or that immediate instantiation should be disallowed; about a 50-50 split between those. That being the case, I think it'd behoove me to make it a checkbox between the two, defaulted to the one with more votes. So, by default, } will be };, but that can be turned off.

Announcements / Re: Quick Poll
« on: March 09, 2010, 02:16:25 PM »
Ah, only when there's a newline, hm... That can probably be arranged, but I think it'd confuse the hell out of people due to potentially appearing inconsistent. I'll add an option for it.

That's basically the principle on which JavaScript was founded, though, so...

Announcements / Re: Pride
« on: March 08, 2010, 11:01:08 PM »
I understood it to be machine-independent code that is optimized and loaded native, JIT.
I assume it should be at least somewhat faster than code compiled for a particular architecture but not optimized for a particular system. I'd like to know by how much on average it's faster, to see if it at all justifies its use.

Memory is cheap. I can't know which objects will use a certain resource, everything's an integer. Doing so by sprites I know will be used is begging for trouble.

Assuming Haskell and C's performance boosts are the same, that's not a bad gain, but I'm not sure it's worth the effort.

Announcements / Re: Pride
« on: March 08, 2010, 10:26:55 PM »
But the bytes coding for those may vary. Now we know it doesn't; to write a decompiler for one is to have one secured for them all. There is only one.
And by stats, I meant benchmarks of LLVM-JIT code versus native on different platforms and architectures. Not just a list of over-elaborated features.

Also, I don't want to do a check to see if the sprite or background has been loaded every time you draw it. The less such checks, the better.
If GM offers such (which I think it may), it will be replaced with a more hands-on system, driven by functions or user-defined events.

Announcements / Re: Pride
« on: March 08, 2010, 09:37:58 PM »
"So can pointers in C++. Does that mean that C++ can't be garbage collected?"
"So there's no strings, surfaces, data structures, sounds or images that you could ever possibly delete?"

C++ could be garbage collected if I replaced all calls to malloc with my own. It is because GM integers are only incremented by one, and are completely ambiguous. Case-in-point: object0 == sprite0, sprite0 == sound0, sound0 == path0. The only unique IDs are for instances, and, well, that's the only thing I come close to garbage collecting. People often shortcut and reference some sprites by integer instead of full identifier. I have also seen choose(spritex,spritey...), and with that, of course, random() used in the mix. There's no garbage collecting resources that are identified like that. My best bet is to assume they are in use until _destroy is called. Good garbage collectors work by tracking references rather than pointers, especially ambiguous ID's representing pointers in an array.

"I think I made myself fairly clear on the nature of the VM I was describing."
Yes, reading that over, now that my expectations for a good reason to use such a VM are zero, I see what you are describing. I was just looking for something to set it off as a better idea than native code. Granted that being able to discover the architecture the program is on and run some specific optimizations for it at load time is nice. However, I don't see it as necessary for the extra work on the platforms for which I would/could include it.

"LLVM has its website to back itself up"
I don't see a single statistic, though it is a nice site compared to others of its breed. They even invested in background textures.

"LLVM isn't much higher-level than normal assembly; it's just not machine-specific"
Which makes it a fraction of the work to write a decompiler for. Though I suppose that can be dropped as a concern since they do optimize it some at compile/link time.

"Anyway, the whole decompilation and obfuscation issue is moronic. Who cares if people can decompile your game and see its source code? What are they going to do with it? Claim it's their own? How are they going to get away with that? Steal the ideas in the code? Don't flatter yourself."
Everyone says that. I agree with most of it. Doesn't mean everyone will kiss ENIGMA's ass for using that same excuse. Some people just like feeling more secure.

Anyway, all this future talk. Clearly, the closest thing Clang has to what I need is its parser, assuming it can really tell me what can be used as a type, and verify if X is a member of Y with a decent complexity. I will add that to my list of considerations for if the one I wrote should ever fail to be enough. Until then, I don't need it, and other than that, the project is no use to me.

Announcements / Re: Pride
« on: March 08, 2010, 05:38:54 PM »
So your argument against including GC is that real programmers don't use GC? In that case, you should stop using C++, because real programmers use butterflies. It would be really stupid not to include some way to get rid of the crap that users allocate. That's one of the reasons GM takes up so much memory, and I thought a main goal of this project was to make a more efficient GM.
I didn't say I wanted to act anything like a real programmer, I said that garbage collecting my own code was lazy and that GML doesn't have anything worth garbage collecting, especially being so spontaneous as a language. Again, GM users don't allocate anything. I've sometimes opened files and forgotten to close them, yes, but that can't be garbage collected. Nothing in GM can be, because everything is an integer. There is no reference, weak or strong. A reference can be pulled out of one's ass.

You're completely failing. A VM is not something that has to be installed on the user's computer. The Lua VM is very, very small, and it's almost always embedded in the programs that use it. Look at Löve2D.
I'm aware. I couldn't tell what in specific Rusky was promoting, probably due to the fact that he claims not to be advocating anything in specific.

Clang parses the whole thing for you, so you would be done already with what you've been working on for... how many months?
Almost half a year, thanks. Probably less than Clang spent on theirs, or has left before they say it supports all of C++.

GM also uses a lot of memory; why would you use what it does as justification? Also, manually allocating and freeing requires a different kind of heap than what GC usually uses. It's not really faster, it's just got the load in a different place. Have you ever written malloc? The only difference is that GC puts the load on freeing while manual puts the work on allocation. If the collector ran at the right time or in a different thread, it could potentially be faster. Finally, I never suggested making Enigma's internals garbage collected, only the parts that the user interfaces with or writes.
That wasn't meant to be justification in the sense that it was excuse; I should have been more specific. I can't just load and dump resources as they come in and out of need, simply because I never really know when they're needed. GM always keeps them in memory; when the user wants them, they are there instantly. The best I can do is provide functions to give the user more control of that.

Like I said, not much in the GML really needs freed. GM offers no method of freeing anything except through functions ending in _destroy. I suppose those could have threaded frees, but I'm not sure it'd be worth it to do so.

Ack. Having a once-compiled module is one advantage, yes. But the user would not have to install the VM on their system. Just like GM games include the runner and Enigma links the engine to the game, it could be included with the game. Literally nobody has LLVM installed, because it's a library intended to work exactly this way. There are also several other advantages of a VM. The game module could be easily separated for use with different runners simultaneously like instant-play. Optimization can be more aggressive with JIT. The engine's API, the runner and the games would be decoupled.
I know little about LLVM. Simply have no interest in it, especially seeing that the only advantage it seems to have is a potentially more aggressive optimization, which no one has backed up (in advance: "it's a fact" will not back this up). That separation doesn't seem to be an advantage. In fact, I take it for more of a problem; the same problem half the GMC was screaming about. ENIGMA games compress to fit inside 300 KB. Last I recall, they compress to fit in just over 100. This sounds like another attack on compression and step back toward decompilation-made-simple. Yes, obfuscation... Just like Yoyo's been promising but never delivered... Not good enough if they did.

Clang is GCC compatible. The platform it's built on supports PowerPC. There's no reason for it not to support Wii in the future (just like it will support the rest of C++ in the future). I did not suggest using Clang right now. However, Clang has a separate library that will parse C++ for you, which would save you the work of having to do it yourself as well as allow future versions to cooperate with the Clang compiler to get rid of all the unnecessary work.
GCC compatibility is a plus you'd not yet advertised. You did mention it supports PowerPC, but just because there is no reason for something not to happen does not mean it is going to happen. There's also no reason for it to support Wii in the future. Just because you are enamored with it, and maybe others are, doesn't mean someone will take the effort to do for it what they did for GCC. The work is done, and people are happy with it. Passing the parse work off to clang would have been nice if I knew I could trust it and I knew so from the beginning. Since my parser's done now, and in the format I like, I have no reason to switch to anything else from here on out. Unless something really stupid happens.

Again, I didn't ask for a design. I wrote my own, and it's done now. I don't want to hear about other techniques unless they are genuinely worth the work to replace what I have with them.

Announcements / Re: Quick Poll
« on: March 08, 2010, 02:27:17 PM »
Correct. This doesn't even affect anyone who does use the resource; only those who want to declare structures in individual events, which is a hassle anyway.

Yes. Didn't want to complicate things with a second new vocabulary word that's essentially synonymous to the first.

The 11th plague of Egypt:
The problem with that is figuring out when you're ready to remove the training wheels and stop hearing that particular error. It'd confuse people when pressing the syntax check button revealed a warning. What about the rest of the document? Is this the only problem? Perhaps clicking the syntax button again would suppress that warning... I really don't have an intuitive system planned out for it, though.