ENIGMA Development Environment

We already do that, dazappa. This relates to naming a variable the same thing as a function. No one would be complaining if the variable behind the problem were called "instance_destroy" instead of "connect," but unfortunately, "connect" names a function as well.

I think he mean "connect" needs to be changed into "obj_object_connect", so there would be no conflict. But we do it partially, but assigning function to variables should be possible, so resolving all these issues with changing the variables while parsing is not really the solution.

Those are also numeric constants. No function can return "vk_left", it can only return an integer that corresponds to vk_left.

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:

Code: [Select]

a = 5;
b = 0;
scr_init();
scr_init():
Code:

Code: [Select]

b = max(5,a);
This will say that 'a' was not declared in this scope.
On the other hand this will work fine:
Code:

Code: [Select]

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:

Code: [Select]

global var a, b;
a = 5;
b = 0;
scr_init();
scr_init():
Code:

Code: [Select]

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.

Robert...when i go to a room, objects tab and i push "instance creation code" button nothings happens...it should open the script window to write on it right?

You probably have to select an instance from the list if you do it this way. Works for me. I usually do it with mouse though - Ctrl+Right-Click->Creation Code.

Josh, still waiting on that parser..

Yeah but not everyone has a DX11 card.  let alone DX10 card.  and you do want your game to run on as many systems as possible.

I don't think things like lost device are anything to do with hardware version of DX it supports. So it should be possible to use many of the DX11 functions and syntax and still run on DX9/10 hardware.

Yeah but again I am not suggesting it is rounding, Microsoft is, I'm literally just being a parrot here, or a parakeet (no pun intended). But that still doesn't make sense, rounding is in the FPU, and changing drivers should affect it's hard-wired behavior.

I don't think anything is hard wired anymore. So I am pretty sure all of it can be changed in the drivers. GPU's don't use FFP anymore for a reason.

The problem is apparent on AMD devices as well.

Until recently no one said that. I have an AMD and I don't have that issue. For now you seem the only one.

This pissing contest attitude of Nvidia is why they are having problems pushing their shit cards into Android and other markets. I'll be glad to see their demise.

Nothing is wrong with nvidia. They are the only ones who care about OpenGL in the first place. Also, by Steam data 50% have Nvidia and 30% have AMD, which is contrary to what you mentioned. AMD is in consoles though, but Nvidia is actually the only one of the two going into Android and other markets. Nvidia is even in cars now. And spacecraft. I personally like Nvidia as a company and their products, but I have nothing against AMD either.