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).