draw event versus step event?

R

RealsLife

Guest
If been trying to make bigger and advanced menu's with 2d array but it seems like I never fully understood the whole process?

I always thought first the step event was checked and after that the draw event was executed. For example some small code that needs to be explained(if you can).
Code:
//create event
arr_lengte = array_length_2d(arr_creationmenu, i)-1;
arr_hoogte = array_height_2d(arr_creationmenu)-1;
Code:
if(keyboard_check_pressed(down)){
i = 0;
a = 1;
if(echte_arr_size +1 < 3)
{
b = 0;
}
else
{
b = 2;
}

j++;
   }
Code:
      if(j == t && i == z)//the current selection
                {
           
                        if(j > 1 && j < 5)
                        {    
                                   
                        draw_sprite_ext(arr_creationmenu[j,i],0,100,50*t,1,1,0,c_white,1);
                        draw_sprite_ext(arr_creationmenu[j,i+a],0,150,50*t,1.5,1.5,0,c_lime,1);
                        draw_sprite_ext(arr_creationmenu[j,i+b],0,200,50*t,1,1,0,c_white,1);                                            
                        }
                        else
                        {
                        draw_sprite_ext(arr_creationmenu[j,i],0,100+50*z,50*t,1,1,1,c_white,1);
                        }  
                }

if I put it like this I will get an error because for some reason b will stay 2 and after it is drawn it is checked but if I remove the if(echte_arr_size+1 <3) then b will be 0 and it will work but I mean why does b change without the echte_arr_size check but not with it. The echte_arr_size var is correct I think and works like this

Code:
    aantal = 0;
    for(k =3;0 <= k;k--)
    {
    if(arr_creationmenu[j,k] == -1){aantal += 1;}
    }
    vorige_j = j;

echte_arr_size = arr_lengte-aantal;
I've much more code but this is just enough to show you this small example. I've been busy with a character creation menu for weeks ugh I just don't get it I tried checking before a variable changes I tried checking it after and yes if I put a check in the draw event the whole thing will already work partly but I don't think I get the whole picture can someone explain this?



EDIT:
yea draw event is for drawing
step event is for checking but read my post first I don't get it... :/
 

TheouAegis

Member
Event order is for all intents and purposes DRAW then STEP. Yes, the manual says otherwise and that may very well be how the program is actually coded, but the the fact remains that DRAW always comes before STEP (the manual does indeed say this as well, but whatever).
 
J

jr carey

Guest
well theres a couple of problems with your code, the reason "b" isn't changing is because from what I see its not incrementing, its just being set, another thing is, its not being defined in the create event,
and why are you using 2d arrays? a 1d array would work the same, and is easier for you to handle, though an even easier way would just use a single variable instead of an array, that would make it even faster,
theres many ways to go about this issue, but your code needs to be written, also

for(k =3;0 <= k;k--)
{
if(arr_creationmenu[j,k] == -1){aantal += 1;}
}

this isn't a very good loop, because your testing 0 against k, it should be the other way around

also

please try to stray from doing heavy math in the draw event (your not doing any heavy math so your okay),
try to keep all math in the step event, the draw event isn't made to deal with very much math or a very complex algorithm
 
R

RealsLife

Guest
well theres a couple of problems with your code, the reason "b" isn't changing is because from what I see its not incrementing, its just being set, another thing is, its not being defined in the create event,
and why are you using 2d arrays? a 1d array would work the same, and is easier for you to handle, though an even easier way would just use a single variable instead of an array, that would make it even faster,
theres many ways to go about this issue, but your code needs to be written, also

for(k =3;0 <= k;k--)
{
if(arr_creationmenu[j,k] == -1){aantal += 1;}
}

this isn't a very good loop, because your testing 0 against k, it should be the other way around

also

please try to stray from doing heavy math in the draw event (your not doing any heavy math so your okay),
try to keep all math in the step event, the draw event isn't made to deal with very much math or a very complex algorithm
Like I said I don't show all my code I need the 2d array believe me. I think I started doing loops like this because if you make an array and use the highest number I guess it goes faster because the engine knows the array size or somthing :p(oh wait nvm you mean somthing like k >= 0 right? Not sure why there is a difference in that but k :p). True b isn't incrementing in the code I showed but I assigned a new value to it so my code should change but like TheouAegis pointed out the draw event occurs often before the step event.

Edit: jr carey also the real problem began when I started trying to make a more advanced menu where in my draw menu you have i another i+1 and another i-1 or i,i+1 and i+2. Anyway I will probably use more if structures in the draw event I guess. There is some advanced math involved but it's some kind of an advanced character creation menu so I guess it's normal, but now i'm more sure about the details I think I can make it work.
 
M

Monsi

Guest
Event order is for all intents and purposes DRAW then STEP. Yes, the manual says otherwise and that may very well be how the program is actually coded, but the the fact remains that DRAW always comes before STEP (the manual does indeed say this as well, but whatever).
Maybe I'm misunderstanding something here but.... Are you sure?
 

TheouAegis

Member
where did you put those codes? because what bugs me is you don't even have the create event showing up in your debugger.

if they changed the coding around that much, then it means they got sick of people asking why draw came first.
 

CMAllen

Member
where did you put those codes? because what bugs me is you don't even have the create event showing up in your debugger.

if they changed the coding around that much, then it means they got sick of people asking why draw came first.
It's there. It's just a few lines up from the other two.
 
M

Monsi

Guest
where did you put those codes? because what bugs me is you don't even have the create event showing up in your debugger.
I marked each event with a green spot. Create events trigger before the main loop if they're in the room already. I don't know how to say this without sounding condescending, so my apologies in advance, but are you sure your sources are valid?

Presumably it was done differently in the past, but to me it just doesn't make logical sense for the draw event to happen first. In my case at least, nothing would be set up yet, because updating code only happens in the step event (to avoid writing code twice). So there would be one frame where everything was in the wrong place.
 
it has always been my experience that the first step event happens before the first draw event. After that point I suppose you could say that either / neither comes first, since they will basically be alternating, right?
 
M

Monsi

Guest
you could say that either / neither comes first, since they will basically be alternating, right?
I disagree. I think it's more like a stack of liquorice

Although it repeats, there's a definite start and end to each one. But now I'm hungry
 

TheouAegis

Member
Well then they changed it at some point, because it used to be Draw then Step. Maybe it's been that way in Studio all along, but I never noticed the change myself; perhaps it had to do with the use of the application_surface. All the legacy versions ran the Draw before the Step event. Like I said, they probably changed it because of all the people whining that variables set in the Step event and read in the Draw event were always unrecognized because they hadn't read the manual entry that advised against that.
 

CMAllen

Member
Well then they changed it at some point, because it used to be Draw then Step. Maybe it's been that way in Studio all along, but I never noticed the change myself; perhaps it had to do with the use of the application_surface. All the legacy versions ran the Draw before the Step event. Like I said, they probably changed it because of all the people whining that variables set in the Step event and read in the Draw event were always unrecognized because they hadn't read the manual entry that advised against that.
Probably, but it also doesn't make much sense to execute the draw event -- before objects have a chance to actually do anything -- before the step event. Of course, you shouldn't be declaring variables in the step event that you intend to re-use in other events or in subsequent step events. That's bad form.
 

TheouAegis

Member
The Draw Event was handled before the Step Event because the room had to be rendered before anything else. In the original mindset, if you were going to put tiles and backgrounds in the room, you may as well draw them. And then if an instance was going to be placed in the room at particular coordinates, it should be drawn at those coordinates; whereas if the step event runs first, the instance could be at different coordinates than where the programmer placed it. To make an unfitting analogy: legacy versions started at 0, whereas Studio starts at 1.
 
S

signal

Guest
Using 1.4 here and I'm noticing that Draw happens before Step. I'm using an array to preload large texture pages at the start of a level. Each of the following sprites belongs to a different texture page.

General:
Code:
mSprite[0] = sprOne;
mSprite[1] = sprTwo;
mSprite[2] = sprThree;

Create:
Code:
mVariable = 0;
Step:
Code:
mVariable += 1;
Draw:
Code:
draw_sprite(mSprite[mVariable], image_index, x, y);

If the Step event happens before Draw, the first sprite would never get pre-loaded.. but it does.

EDIT:
Using show_debug_message() as @Monsi did, confirms that DRAW happens before STEP in 1.4.1763. It may be situational, though. One would have to do more tests to confirm that it always behaves this way.
 
Last edited by a moderator:
M

Monsi

Guest
I am also running 1.4.1763, so this is very odd. Maybe it's a setting?
 
S

signal

Guest
It might depend on WHEN an instance is created. If an instance gets created in the step event of another instance, does the new instance also run its step event that STEP?
 

CMAllen

Member
It might depend on WHEN an instance is created. If an instance gets created in the step event of another instance, does the new instance also run its step event that STEP?
I don't think there's an easy way to test that. Mostly because there's no easy way to get the execution order of run-time created objects.
 
M

Monsi

Guest
When an instance is created by another object only it's CREATE event is run, not the STEP event[/USER]
No, but now that the instance is "on the list", it's own step event and draw event might be added. If step events are called in the order of instance creation, that would mean the new instances step event would be called last (which hasn't happened yet).

However if an instance was created in a draw event (I feel like this is a bad practice), it will obviously skip the step event, but depending on its depth might call a draw event. Hence, the draw event happening before the step event.[/user]
 

TheouAegis

Member
The test i ran when I conceded Studio does Step first was to have an instance already placed in the room. That instance had a show_debug_message() for each event. At the end of the Draw GUI event I put "instance_destroy()". So if the Draw event happened first, the Draw GUI event would cancel the Step event from running. If the Step event ran first, then I'd see all events post to the debugger. I ran the test and all events showed up in order of STEP-DRAW-GUI.

But then I noticed something odd: The create event didn't show up. So that means the initial events didn't show. So I added a second object that would restart the room. The Create event showed up, but Step still ran before Draw. So then I tried restarting the game. Same thing. I even tried restarting the room from different events. No change.
 

TheouAegis

Member
you might be right about the initialization spam, because when you do a game restart it will show the create event before the memory allocation. I'm on the road now.
 
Top