Hmmm.....
...
Hmmmmm......
...
DAMNIT!
Well, I'd take localv over that. Two less letters, and such. May as well just go with local, in the end.
var i;
for (i = 0; i < 10; i += 1)
...
in ENIGMA, you'd say for (var i = 0; i < 10; i += 1)
...
OR you can say for (int i = 0; i < 10; i += 1)
...
That's an easy way to speed up your code, since int is more than 10x faster than var in ENIGMA alone (there's really no point comparing it to GM's var's speed). for (var int i = 0; i < 10; i += 1)
...
SO. If we use "local" this way, here's the layout:So writing a=0 means writing var a=0 in the sense of GM var?
local int a; //Declares variable "a" as an integer. "a" behaves like variables such as "x" and "y".
int a; //Declares variable "a" in the current script. It cannot be used in other events or codes, like "var a" in GML.
a = 0; //"a" is assumed to be a local variable, and will be given type "var" if no one else says anything.
a = 0; //"a" is assumed to be a local variable, and will be given type "var" if no one else says anything.I meant object-local that time, yes. Fix'd:
"The whole `var` class thing doesn't work the same way as GM's `var` keyword."The `var` keyword in GM is not analogous to a type name in C++.
Care to back this up with examples?
Strings: | GM Style ("\") |
Comparison: | = or == |
Operator ++: | Enabled |
struct {}: | Treat } as }; |
Strings: | GM Style ("\") |
Comparison: | = or == |
Operator ++: | Disabled |
struct {}: | Treat } as }; (inapplicable) |
/* Old: */
var i;
for (i=0; i<10; i+=1)
draw_circle(x-16+random(32),y-16+random(32),random(5)+5,1);
/* New: */
for (int i=0; i<10; i+=1)
draw_circle(x-16+random(32),y-16+random(32),random(5)+5,1);
/* Before: */
var a;
a = ds_list_create();
/* After: */
list a;
/* Before: */
a = ds_list_create();
/* After: */
local list a;
local list<int> a;
Strings: | C++ Style ("\\") |
Comparison: | == |
Operator ++: | Enabled |
struct {}: | ISO |
it's better not add it in a GM style.Which, IIRC, is the use of some badly-made GEX, and the "feature" being added is usually a little get_string box which accepts a single password to set lives to 200 or something, and does a show_message on both correct and incorrect attempts. And then people post in the topic saying "Wow, this is amazing" and "How do I install GEX?".
struct vector
{
double direction;
double magnitude;
}
vector a[100];
a[0].magnitude = 0;
a[0].direction = 0;
Pretty convenient, huh?if (true)
{
var a;
a = 3.14;
}
show_message(string(a));
show_message(string(a));
a = 3.14;
var a;
a = 2;
1) Tell Game Maker that this variable should be treated local to the script, as a keyword (Wow! that's what var does!)
2) Mark intended for "var" only to signify that the variable was local to the code.
2) Did he intend for the keyword to not be retroactive? That makes it behave more like a declaration than a keyword...
Josh @ Dreamland:
he whole dilemma here is that we don't know what Mark was thinking because he implemented it badly
retep998:
WHO CARES WHAT HE WAS THINKING????
retep998:
I LIKE IT THAT WAY
retep998:
AND IT WORKS
Josh @ Dreamland:
well, if we're going to turn this into a huge genetic fallacy we may as well have our facts straight
Josh @ Dreamland:
haha.
if (true)
{
var a;
a = 3.14;
}
show_message(string(a));
My thoughts ^Whoever uses that code in gml is retarded, who cares how gml handles it, it shouldn't be written.
Breaks this vCode: [Select]if (true)
{
var a;
a = 3.14;
}
show_message(string(a));
And by "breaks," I mean "fixes in a way that may piss off a very small percentage of GM users."
Whoever uses that code in gml is retarded, who cares how gml handles it, it shouldn't be written.
Slippery slope to all GM code being retardedThat above code is illogical it shouldn't even be used in GM, the same is not said for all gml.
if (hits > 10) { //every 10 hits, they lose all their weapons
var i;
for (i = 0; i < 5; i += 1) { weapon[i] = 0; }
}
...
i -= 1; //we're reducing the number of lives this player has
Doesn't really matter if it should or shouldn't be used - someone uses it in some game, and they expect to convert said game directly to C++ with Enigma, which is a fairly reasonable expectation.Directly converting GML to C++ is impossible. They should not expect it.
I completely agree with keeping everything compatible with gml but something like that is not a normal scenario, it's irrelevant, noone uses it and noone is supposed to use it.
It's like actively making Enigma return the previous script return value for a non-returning script like GM does. I'm not sure whether it does or not but actively making it do so would be pointless and a hindrance if that functionality is not desired in Enigma. Though it is a feature in GM and someone may perhaps use it stupidly the scenario is just not worth considering.
Will Enigma also include any bugs within GM so it is compatible?
I know it's not a 'normal' scenario, but which is easier - convincing all possible GM -> Enigma converts to code properly and recode all their old stuff properly, or just make Enigma work with it?You don't need to convince anyone as it's not going to affect anyone.
Directly converting GML to C++ is impossible. They should not expect it.
IMHO we are just trying to make C++ and GML live togheter.
By converting I mean translating, you are not going to convert GML into C++ like you convert English into French.QuoteDirectly 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() {}.
Also, I'd really like to see an English->French translator hard coded over the two languages' twelve similarities.You mean not like Google translator!?!?
I use it to work with all the instances of a given object, I'm not sure that's good coding practice, but hell it's useful.It's definitely good coding practice in gm.