ENIGMA Development Environment

I even suggest using GL1 or GL3 instead of DX, as most people can run those just fine.
Anyway, with all the changes merged DX11 should compile (although without rendering anything just like before). Also Robert will probably update the installer later and all will be good with the world. Or we just broke the whole thing *flips table*.

So it shouldn't have drawn particles right?

Right now I get "graphics_get_texture_pixeldata" which might be because the particle system tries to create a sprite, but DX11 doesn't have this capability right now. So I guess I will commit even these changes, as broken DX11 isn't a tragedy (as it cannot even draw a sprite). At least when you continue to work on it the particle system would work as well.

Are you 100% sure DX11 worked for you before? Because that system lacks VERY important code to actually run. Even after I did the changes I couldn't compile it because it lacks functions like "graphics_get_texture_pixeldata" which is important for the engine. DX11 was never finished as I know, so I don't see how it even ran for you. Maybe even if it did ran, it should of just showed a blank screen.

Robert, was DX11 operational?

Thanks for the explanations, so in this example if I use the for / loop to read bytes from a big file, it would be much faster ?

Yes. There the I/O could be a bottleneck, but you should still see some kind of improvement. So you should declare types whenever you can. The general purpose "var" is very big (can be any size - from 1byte to n bytes, but maybe Josh could say more precisely) and slow (I guess because the compiler cannot easily optimize it like it would basic data types).

I thought that was the usual way of using FOR with int, it's even documented that way in GM.

Where in the GM documentation? I think you missed the point on what I did there. I changed "var" into "int". GM doesn't allow that. It only has "var". I could of changed it into "double" or "char" or "size_t" or anything else if I wanted to. But those types are what makes it so fast.

Actually you want unsigned int, because it is never negative, or size_t.

I personally think using unsigned variables are becoming a bad practice quite rapidly. They generate A LOT of errors, especially for newbies, and so they are not encouraged. They were required when you actually needed the extra "size" (like when int was only 65536), but now when int's are +-2,147,483,647 which is usually "enough". Soon it will be better to just use double everywhere. Like if you wanted the loop to work in reverse:
int counter;
counter = 0;
for (unsigned int i=1000000; i>=0; --i){
   counter+=1;
}This is would end up as infinite loop. And most newbies wouldn't even figure out why. I guess this is why there are no unsigned types in Java. Speed wise unsigned and signed is more complex. unsigned can be optimized in some interesting ways (like http://stackoverflow.com/a/12225693) but they can be slower to cast to float (http://plog.sesse.net/blog/tech/2011-07-27-10-37_the_micro_optimization_corner_unsigned_to_float.html).

But I guess if you make a forward going loop you should use size_t, as it usually also gives you a good indication on what the loop is doing (that it accesses arrays usually).

Another reason is because you would have to explicitly cast unsigned to signed for comparison. Like if you run ENIGMA the first time (when engine is compiled) the majority of warnings (and there are A LOT of them.. we should probably get on that) is because we compare signed and unsigned variables. If we used signed everywhere we wouldn't have that problem and yet the code would usually run the same (as we don't really go over 2.1 billion mark in resources, instance count, text glyphs (even with Unicode ranges) and so on).

edit:

for (int counter=0; counter<1000000; ++counter)

You could. The reason why I didn't is because an empty for loop sometimes could be just optimized out. Read this: http://punchlet.wordpress.com/2011/07/01/letter-the-eighth-bedevilling-benchmarks/
So while it probably wouldn't do it in Run mode (which isn't optimized) it maybe would do it Compile mode. So for illustrating a point I made it so the loop wouldn't be optimized out.

C++ doesn't really differ much from GML syntax wise. So while techincally you can use pure C++ (which as far as I know you still cannot, because the current parser would go insane) there is really no need. You should use EDL though, which is a combination of GML and C++. EDL supports things like specified types which can greatly increase the speed of a game. For example this code:
var counter;
counter = 0;
for (var i=0; i<1000000; ++i){
counter+=1;
}If I put that in step event I only get 74FPS. But if I change "var" to a real type like "int" by doing this:
int counter;
counter = 0;
for (int i=0; i<1000000; ++i){
counter+=1;
}I get 2250FPS. That is a performance increase of 30x. In GM you cannot do this as it has only generic variant type (which is the default one in ENIGMA as well). But in EDL by assigning a specific type C++ style you can greatly speed up the code. But then you are in C++ territory and can no longer type 'int counter = 0; counter = "Foobar"' as that would be a compilation error (only generic type "var" can be changed from real to string and string to real).
EDL in the future will also things like structs and classes, but I personally don't miss them in ENIGMA, so I don't really care.

Could someone give me some examples of how C++ code in my projects would benefit me when I have all the GML functions to use?

Also, C++ isn't really about "functions". It doesn't have any. It is a programming language, so all it provides is you with syntax and semantic to write something. It does come with some basic functionality (called STL or Standart Template Library) which include data structures like lists, maps, vectors and so on. But usually you either write everything by yourself or you use something others have written (including API's). So imagine C++ basically as ENIGMA without any built-in functions, but only support for Extensions.

That is why I also often say how you can do whatever you want in ENIGMA and lacking of some single feature doesn't make it unusable or worse. Because in C++ you either write your own or find someone who already has done so, but you don't go to C++ standard committee and tell them how you really want a shader library. So we would like users to write extensions that implement a lot of functionality, not directly needed in the engine. That also allows different implementations by different people. Like the particle system is an extension right now. So it would be possible for another person to write a particle system that uses only GPU and then you would just Enable it and Disable the old one. And whola, without changing anything in your code (or code of the base engine) you got a particle system working in a totally different way.

Well DX11 was never finished (or even close to being finished) so it doesn't even have code for basic drawing. So you shouldn't try to use it.
But DX9 should work. Try deleting /ProgramDATA/ENIGMA/.eobj folder. So it's a clean build. You can also try Build>Rebuild All, which should technically do the same.
When doing a clean build the particle example works for me in DX9. The "undefined reference to" basically means something hasn't been recompiled. If the clean build doesn't work, then try searching for "DX9primitives.o" or any other DX9 .o file it errors about. I had this some time ago, that Windows7 puts files into subfolders and then links them back. So the program finds the files, while the user has an empty directory at that folder. It's some kind of "Security"/Compatibility feature apparently.

Harri execute_string does return a value, I just tested the following in GM8.1

I know it returns a value.

spr_head = 0 (execute_string() by default return 0)

Assignment on the other hand shouldn't. This should "return spr_head=spr_some_head".