ENIGMA Development Environment

So in terms of performance would I be better off using data structs ? I notice with the ds you can insert, move, copy, delete individual, find, etc, far more efficient than the arrays,

They just have functions for that. In case of regular arrays you would have to do that yourself, so depending on your own implementation it can be both slower and faster. Usually regular arrays are faster than ds, because data structures are classes with their own overhead. So if you just want to store stuff, then regular arrays would probably be faster (even if the array is big). If you want to remove/add elements, shuffle or sort, then using a data structure would be better (mostly because they already have those functions). There is problem with current data structures though - for GM compatibility they usually don't use a regular class (the std container), but some custom one. So the performance of ds_list, for example, could be worse than using std::list in C++.

You can see std containers here: http://www.cplusplus.com/reference/stl/
They have a good information on differences between them. So you can see how std::list (which is a dynamic array) is different from std::vector (which is also a dynamic array). One is fast at inserting, other is fast at lookup, the third is fast at sorting. So depending on your need you would take the one works fastest. In ENIGMA most of the ds are std::map as far as I remember. And that is actually quite slow.

Is that draw event triggered anytime, even outside the boundaries of the screen?

Yes, draw event is triggered always. That is because you can draw anywhere inside the draw event no matter where the instance is located. Like you could put "x = y = -100;" (so it's outside the room), but still draw_sprite(spr,0,10,10) (so draw it 10,10). That is why we cannot optimize that. If you use the default draw event, then we could technically take sprite into account and not draw that, but that is also not done now (I think). It's possible any performance gains would be minimal (the only advantage would be possibly less texture switching as we don't have a texture atlas). But if you draw sprites only at instance positions, then you can use things like instance deactivation to not render things outside view.

Apparently has been fixed now. The circle function had to be changed. Blend modes worked fine.

If the "visible" box is checked, then it draws the "Draw event". The default Draw event (which you cannot see) has just "draw_self()" in it which draws self. On the other hand if override that event (by adding your own code/D&D actions or just a comment to the "Draw event"), then the default one will not run and nothing will be drawn. You should be able to see that yourself in the game. If you don't see anything, then it probably doesn't draw anything. Of course if you haven't assigned a sprite to the object, then it won't draw anything either.

On an expert level yes I used BASIC and I can swear on my life that it worked differently.

The difference is that in Basic you probably didn't have an engine. I think you didn't even draw anything to a rendering context. All you did was output to console. That is a lot different then rendering to screen. That is where your misunderstanding came from. If you had used some graphics engine with BASIC you would have noticed the same thing you noticed here.

Understood.  So, in this example, how can I make an object move 100 pixels (1 pixel at a time) using a for / loop then ? 

If you actually want to see the object move, then you shouldn't use a for loop (unless you want to use the screen_redraw() "hack"). If you want 1 pixel at a time, then that means you need to increment the position 1 pixel per step. That means adding x+=1 to a step event. That's it.

So in which cases then would a for loop be properly used in a step event ?

Well, whenever you have to loop something. Like looping over objects or looping over arrays. Previously you showed a code used for a collision that used the while loop. That is a very popular place to use it. Basically you use it the same places you would in C++ or BASIC or anything else. If you wanted to move a box 1 pixel at a time and render that movement on the screen, then you wouldn't use a for(){} in BASIC either.

Now, I applied what I learned in how for loop works in other languages and done something with arrays.

You could just put the loop in create. No need to have it in step if you only run it once.

Is it correct what I did above  ? Is the coding clean
or is there a better way to do the above?

It's ok. I would probably just use an alarm.

So to recap. This is what your code looks like in ENIGMA (or any game engine):
while (true){
    //start logic, like your step event
    for (i=0; i < 99; i++)
    {
draw_text(10,10,"Count: "+string(i));
    }
    //end logic

    screen_redraw();
}So it's a loop inside a loop. The first loop is the main one and executes once per step. The inner one is your step event that gets executed. And screen_redraw() is the function that actually draws something on the screen. You should notice from this example why your previous codes didn't work as you expected. When you understand you are already in an infinite loop, then it should be easier for you to make things. Like if you wanted your object to move to x = 100 with 1 pixel per step, then you just do this:
//Create event
x = 0;

//Step event
if (x<100) ++x;So this is actually easier and shorter than what you wanted to do with the for loop.

edit:
Also, you could technically do what you want with threading. You could create a script and place something like this in it (haven't tested it):
for (var i=0; i<100; ++i){
   obj_someobject.x = i;
   sleep(1/room_speed);
}And then call that with script_thread() (probably in Create event). What this would do is change the object's x position, the go to sleep for 1 step during which time the screen should redraw in the main thread. Then you modify the position again and sleep again. Until the loop is finished. But this isn't a good solution, as it can cause race conditions, consume more resources and create jerky movement (like it's possible during a slowdown that the object moves twice in one step instead of once).

I think you replied to the wrong thread. By the power of deduction I think you wanted to post in the thread about Dropbox Packrat?

Now, there are other ways of doing this, and initially I tried using for but it did not work

What you posted are NOT other ways to do that. They do something completely different.

This does not work......for some odd reason i starts at 100.

It's not odd at all. A for loop repeats the code inside it until a condition is met (http://en.wikipedia.org/wiki/For_loop). In this case that means drawing 100 times (numbers from 0 to 99) in one step. After that loop i will be 99 (because it will have added one 99 times to it in that step). The next step it will be reset to 0 (the initializer in the for loop) and then draw 100 times again. After which i will be again 99.

Does nothing, nothing gets drawn so this proves the code is not being executed.

It does draw something. It draw the text (like in the for loop) for one step (the very first one). After which the i is more than 99 and the while(){} never executes again in the next steps (because unlike in the for loop, the i is never reset to 0 in this case).

Looked in GMS's docs, and that is how they document while and how it's supposed to be used.

I think you don't really understand how cycles work. Or how steps work. The code you put in events like draw or step are executed once every frame (called step in GM). By default there are 30 frames per second (changeable in room settings). Create event (where you set i to 0) is ran only once, when the object is created (in the beginning of the room). So all of the codes you posted work just fine. They would work like that in GM, ENIGMA, C++, Basic, Python or anywhere else.

This works, so why does a simple counter loop with while does not ?

It works just like you coded it. There are no bugs or problems with while, for or repeat cycles.

In this example the object should move 1 pixel at a time until it moved 100 total pixels.

No it shouldn't. As I mentioned before Draw event (the one actually drawing to the screen) is executed once per frame. While the for(){} you have created here executes 100 times per frame. So when using that loop you should see the object at x=100 in every frame.
Imagine the code like this:
//In step 10 here x = 100
for (i=0; i<100; i++){ //Here x = 0
 x = i; //Here it is changed 100 times
}
//Here x = 100 again

//Here the draw happens and you actually see the object drawn at x,y position which is always 100As you can see x will always be 100 in this case and the object will always be on the same position.

Result when run, i is 100 instantly,

As it should be.

Read up on loops. You said you used Basic before, I think they had loops too.

edit:

This should start counting from 0 and increment i by 1 every step.

No, it shouldn't. Your for(){} cycle is executed inside ONE step. You execute it every step from the beginning. You cannot have one script execute spanning multiple steps. Like this is impossible:
//Step event code

x = 0;
//Now do some magic to change steps
x = 1; The "magic" part is impossible.

What you can do is call screen redraw manually. Like you could do this:
//Step event
for (i=0; i < 99; i++)
{
screen_redraw();
}

//Draw event
draw_text(10,10,"Count: "+string(i));But that wouldn't change the step or execute any other code. It would just call all draw events. So that would work like the original code, but consume a lot more resources (as there isn't a frame rate limit here) and if you put screen_redraw() in draw, then that causes an infinite loop that crashes the game (that is normal as you are calling a draw event from a draw event from a draw event...). The screen_redraw() is most used to render screen to a surface:
//Step event
surface_set_target(screen_surf);
screen_redraw();
surface_reset_target();This would draw everything that is on the screen to the surface. Another popular use for screen_redraw() in the old days was to create loading bars. As GM didn't have threading, then the game usually froze when executing an intensive script (like loading a large level from a file). To create a loading bar you needed to redraw the screen while the script was executing and that was done via screen_redraw(). Like so:
//Script that is slow
loading_bar = 0;
//Load models or something that takes 2 seconds
loading_bar = 10;
screen_redraw();
//Load map that takes 5 seconds
loading_bar = 50;
screen_redraw();
//Do some init or something that takes 7 seconds
loading_bar = 100;
scree_redraw();

//Draw event
draw_rectangle(10,10,10+loading_bar,50,0); //Draws the loading barSo in this case even though the same script is executing in the same thread, the loading bar is still drawn as animating. No other events or scripts are called though (unless they happen in the draw event). So no "step" has actually happened.
In ENIGMA we have functions like script_thread() that would be a more proper way to do this.

The only thing I have ever used for C++ is MinGW. I just take any IDE (Code::Blocks being my favorite, but you can also use Notepad++ or just plain freaking notepad) and I compile everything with makefiles and cmd. So i'm pretty old school with all that. But I know even IDE's like MS Visual Studio support MinGW in one respect or another. At least it supports compiling on Linux machines remotely (I used VisualGDB plugin to do that for RaspberryPi from Windows). I think there is a plugin or something like that to interface with MinGW as well. This would give you access to Intellisense and maybe even makefile generation, while still using plain C++ and MinGW compiler.