ENIGMA Forums
Contributing to ENIGMA => Proposals => Topic started by: ludamad on November 23, 2008, 01:56:12 pm
-
GML as it is in GM should definitely only be in a special compatibility mode. Instead, the real EDL language should have some more logical restrictions, and better organization of functions.
GM Code:
if variable_local_exists("Counter")
{
Counter+=1
ds_list_add(myList,Counter)
}
else
{
Counter=0
myList = ds_list_create()
}
EDL Equivalent
//Static variables are used instead, this code can be thought of 'only executing the first time', it is not set to 0 every time it is run
static int Counter = 0;//=0 is optional, in C++ static variables are always initialized to 0
static list myList; //creates an empty list if one is not created
Counter++
push(myList,Counter)
-
for now:
cpp { static counter; }
for later, static would be marvelous
-
Don't you mean:
cpp{static int counter;}
-
I don't see why this should go in "ENIGMA Einsteins."
In fact, I don't know why we even have three different forums to ask for help.
The forums are turning into the GMC.
-
EDL design is an issue that only ENIGMA Einsteins can discuss, duh.
-
whatever static int static notint whatever.
But yeah, how about just one forum for discussion plz? At least atm, there really is no need for more. maybe 2.
-
But yeah, how about just one forum for discussion plz? At least atm, there really is no need for more. maybe 2.
wut
>_>
<_<
<_>
-
ENIGMA has to be fully Game Maker compatible otherwise its use will be confined to a very small group. We need to have ENIGMA as a drop-in replacement that any GM user could pick up and understand. The only visible difference to the average user should be the gamemaker_registered=1 constant.
I fail to see how your thing couldn't be done using the C++ tags.
-
allowing things besides var would leave it just as backwards compatible, it would just also add new features.
-
allowing things besides var would leave it just as backwards compatible, it would just also add new features.
If that was in reply to me, I know that. I'm only against 'deprecation', i.e. not being able to even use the previous format.
-
Deprecated means discouraged but still supported; alternatives will be preferred, and you need to specify that you want to turn deprecation warnings off, and then you can GM all you want. However, you might accidentally do something like attach an interpreter to your executable (how else will josh do execute_string?).
-
a compiler instead!
-
I fear you'll find static doesn't get along with instances.
Stays the same after you delete an instance and recreate it.
In other words
Abandon all hope.
-
Just as good would be if localv int Counter = 0; was placed in the constructor - that is, the variable was initialized in the constructor instead of the code piece.
-
Well, localv was meant to be used in create, but I could rig static to behave like localv except in constructor. That's only if I have to, though.
Using localv in the create event is virtually the same thing. The create event's been bouncing in and out of the constructor in my mind, but it actually is in the constructor in R3. (It won't be next release, because it'd save time to call it in instance_create instead of checking that we aren't in a room create later. If it's in a room create, I need to make sure all the instances exist before calling create events, I think. I need to run tests...)
-
Any Game Maker game should compile in ENIGMA and run 500x faster.
Although that doesn't mean all ENIGMA games need to be able to save in Game Maker and run.
-
Any Game Maker game should compile in ENIGMA and run 500x faster.
Although that doesn't mean all ENIGMA games need to be able to save in Game Maker and run.
Unless it contains execute_script?
-
yes, change that to nearly any. including gcc and the parser is not allowed, neither is including an interpreter.
-
execute_script() is probably the shittiest excuse for a function ever.
-
It's very useful. It allows you to pass a script as a callback to an object or another script.
-
You can do callback without having to stick an interpreter onto the exe.
-
It's very useful. It allows you to pass a script as a callback to an object or another script.
with (obj)
{
function();
}
-
he's probably thinking more along the lines of giving the other object or script something to execute in some of its code. in most languages, callback is done by giving the name of the function. you can do that in gml by using the name of the script, because it's just a resource id constant.
make a script
then do this
script(otherscriptname);
-
Ah.
Still useless.
-
Yes, execute_string/file are useless- because of what I just said. So "still useless" was what I was agreeing with.
-
It's useless, all right.
switch function()
{
case 0: script0()
case 1: script1()
case 2: script2()
}
That's the only piece of code it could replace.
I suppose execute_script would be easy enough to implement. So as soon as I see it on the request page, I'll do it. Ha
-
...there's a request page?
Also,
http://enigma-dev.org/forums/index.php?topic=221.msg1283
-
It's useless, all right.
switch function()
{
case 0: script0()
case 1: script1()
case 2: script2()
}
That's the only piece of code it could replace.
but how often do you need that?
-
Practically never.
-
Point proven. YYG is just trying to add useless functions to make the function list look bigger.
-
now that was stupid. those functions were there long before yyg.
-
I use object_add to save space in the editor
Luda used execute_script in his AI comp manager
-
Like I said, real easy to implement. Assuming I don't run into any problems getting a pointer to a function with 16 optional arguments, other than the shear size of the type name.
But it still seems pretty worthless. And no wonder you complain about speed, serpy. Mark never bothers to tokenize new object code ahead of time, or something. New objects are much, much slower than regular ones.
-
EDL as it is in GM should definitely only be in a special compatibility mode. Instead, the real EDL language should have some more logical restrictions, and better organization of functions.
GM Code:
if variable_local_exists("Counter")
{
Counter+=1
ds_list_add(myList,Counter)
}
else
{
Counter=0
myList = ds_list_create()
}
EDL Equivalent
//Static variables are used instead, this code can be thought of 'only executing the first time', it is not set to 0 every time it is run
static int Counter = 0;//=0 is optional, in C++ static variables are always initialized to 0
static list myList; //creates an empty list if one is not created
Counter++
push(myList,Counter)
Why push() instead of ds_list_add() in EDL?
-
I think your G
ML to EDL conversion thing really screwed up on this topic.
-
Why push() instead of ds_list_add() in EDL?
Because Luda thinks that Rusky's not-done-yet data structures are insuperior.
-
The list ones are >(
And I just did it the way GM did >(
But I like being able to use list as a type and including GM functions only for compatibility. Maybe after version 1.0 is released in 7 years plus an imaginary one.
>>>>>>(
-
>=o
*undoes the filter thing*