egofree
|
|
Posted on: June 05, 2014, 04:10:24 pm |
|
|
Joined: Jun 2013
Posts: 601
|
Hello, I would like to modify the wiki page about EDL specification. Instead of: Arrays
EDL inherits JavaScript-like arrays rather than C++-like arrays. This is so an array can serve as an lvalue, as in the following code: [x,y] = get_coordinates(); var fruits = ["apples", "oranges", "cherries"]; In the above case, x and y are set to the first and second elements in the array returned by get_coordinates(), respectively. The second line then declares a var and assigns the given array values to it. How this is accomplished after compile is outside the scope of this specification. Consult the appropriate export language plug-in page for details on implementation. What about : Arrays
An array is always declared as a variant data type with the keyword var, followed by its name. Variant variables are not restricted to a specific data type and can hold any value you want. In order to access the element of an array, you add after its name the element index rounded by square brackets.
Example :
var myarray;
myarray[1] = 10; It seems better for me, as i think users of ENIGMA/GM are often beginners in programming and don't know much about others languages. I would like to modify the wiki, but i am afraid i am not fluent in english. What do you think of my proposal ?
|
|
« Last Edit: June 05, 2014, 04:18:19 pm by egofree »
|
Logged
|
|
|
|
Goombert
|
|
Reply #1 Posted on: June 05, 2014, 07:35:31 pm |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
Meh, I am going to say that is up to Josh, I am not sure if he wants the specification to be introductory or more focused on technical jargon with a watered down version as a side article. Send him a PM is my suggestion.
|
|
« Last Edit: June 05, 2014, 07:47:47 pm by Robert B Colton »
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
Josh @ Dreamland
|
|
Reply #2 Posted on: June 05, 2014, 09:03:49 pm |
|
|
Prince of all Goldfish
Location: Pittsburgh, PA, USA Joined: Feb 2008
Posts: 2950
|
That page was detailing the new specification, which is mostly implemented in the other branch. Your statements do not apply to it, though they are more relevant for now. I would recommend inserting that before the current paragraph, right under "Arrays."
It'd be good to note that the lvalue-array specification is not currently implemented.
|
|
|
Logged
|
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble "I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
|
|
|
|
|
|
|
|
|
|
TheExDeus
|
|
Reply #10 Posted on: June 07, 2014, 09:20:24 am |
|
|
Joined: Apr 2008
Posts: 1860
|
If you want to add functions, then no, they are just pure C++ in ENIGMAsystem folders. They also include extensions, new graphics systems and even platforms. What parser does (and it's in CompilerSource) is it converts your GML/EDL to C++. This is what allows you to use static types (int, double) together with GM's one type var. It is what what implements EDL specification (it's on the wiki), but as we all know it's not implemented completely. Like we still can't use structs, even though it is in the specification. The parser is also responsible for many of the compile bugs, like when you use "globalvar a = 0" in create and then try "a = 2" in a script. It will probably fail now, but in reality it shouldn't. So it's not anything to do with your game (so speed, size or anything else shouldn't change), but how you can code it. Like there is a topic on "Staff Board" about parser bugs. Should have probably posted in "Issues" so everyone can see. I decided to make a quick topic here to mention the parser bugs I keep having in hopes that when Josh finished his new parser he could test these cases. They should be mentioned in the ENIGMA bug tracker as well somewhere, but I think they are buried now. So this is not a bug report as Josh should be already aware of these. It's just so we can point out what is fixed and what isn't.
They all for now are something to do with scripts. I remember having bugs outside scripts as well, but I sadly forgot them. That is why I am making this topic.
1) Local scope problems in scripts when using variadic functions. Example: Create event: Code:
a = 5; b = 0; scr_init(); scr_init(): Code:
b = max(5,a); This will say that 'a' was not declared in this scope. On the other hand this will work fine: Code:
var tmp; tmp = a; b = max(5,tmp); //or this b = fmax(5,a); So we cannot use object local variables directly in variadic functions (they are min,max,median,mean etc.).
2) We cannot use global variables defined by "global var" in scripts. I mentioned this bug before, but Josh dismissed it, so he might not be aware of it: Create event: Code: global var a, b; a = 5; b = 0; scr_init(); scr_init(): Code: b = 5; This will error 'struct enigma::OBJ_obj_0' has no member named 'b'. This is because in the script it actually tries to access local b even though there is no such thing as local b. If I type "global." in front of all of them, then the problem disappears. This is a problem I actually have in the Circuit Drawer port (had it a year ago when I tried to port it the first time and I have it now), because I actually use a lot of "global var" (at least one for each element type).
I will post more when I remember or find more bugs.
|
|
« Last Edit: June 07, 2014, 09:24:31 am by TheExDeus »
|
Logged
|
|
|
|
|