WaitEvent() waits for an event from the OS, which is like: buttonpresses, mousemoves, keyhits, timers, windowresize etc.
If nothing happens, then the 'programcounter' err.. imagine an arrow pointing where the program is in the source, then all that will stay at the WaitEvent() command. So, if something happens (an event occurs) then you simply have to determine what event it is. You do this by checking on several event properties, like
EventID() the type of event that occured
EventSource() where the event came from
EventData() sometimes there's extra data like a keycode
EventX(), EventY() coordinate on a canvas-gadget
etc. (see the manual)
You can have various timers running at the same time, this multitimer stuff may look alien, but they all just create events, that's all you'll have to be concerned about. So you can have various async timers at once!
What you were trying to do was polling. That's where you have a mainloop and in it you update the gamestatus, and do the gameupdate (draw stuff etc.) always, as fast as the program can.
Polling-based programming and Event-based programming are different things, and personally I **NEVER** ever want to go back to polling! In BMaxgui the eventsystem is even better, but alas.
So, to answer your question: you could see this $4001 as a mainloop yes, at 50 fps in this case.
However, if you put everything in there (game AI update and screen update) then there wouldn't be much of a difference with what you're doing now (apart from that I really don't like polling-timers). What you could do is have 2 timers, one timer triggers the game-AI updates (like 30fps) and another does the screen updates (like 60fps), another timer (at speed 1) could be a timer to trigger a real clock etc.
That would look like this:
When a timerevent ($4001) happens, the program goes into that If-EndIf, next you check which timer it was by checking the EventSource() with your timers. So, if you were programming visually: checking on events is like having all the possible options on a large grid, and then you go narrowing the choices down until you have the right choise.
Logically it's best to narrow down in an efficient way by first filtering out the largest part of all the options.
So, this would work perfectly, but it's wrong.. :P
it *would* be ok to first check on the EventSource() when you're checking all the canvas-actions in case you're using a canvas.. then you go about;
If nothing happens, then the 'programcounter' err.. imagine an arrow pointing where the program is in the source, then all that will stay at the WaitEvent() command. So, if something happens (an event occurs) then you simply have to determine what event it is. You do this by checking on several event properties, like
EventID() the type of event that occured
EventSource() where the event came from
EventData() sometimes there's extra data like a keycode
EventX(), EventY() coordinate on a canvas-gadget
etc. (see the manual)
You can have various timers running at the same time, this multitimer stuff may look alien, but they all just create events, that's all you'll have to be concerned about. So you can have various async timers at once!
What you were trying to do was polling. That's where you have a mainloop and in it you update the gamestatus, and do the gameupdate (draw stuff etc.) always, as fast as the program can.
Polling-based programming and Event-based programming are different things, and personally I **NEVER** ever want to go back to polling! In BMaxgui the eventsystem is even better, but alas.
So, to answer your question: you could see this $4001 as a mainloop yes, at 50 fps in this case.
However, if you put everything in there (game AI update and screen update) then there wouldn't be much of a difference with what you're doing now (apart from that I really don't like polling-timers). What you could do is have 2 timers, one timer triggers the game-AI updates (like 30fps) and another does the screen updates (like 60fps), another timer (at speed 1) could be a timer to trigger a real clock etc.
That would look like this:
Open in online IDEGraphics 640,480 AItimer=CreateTimer(30) GFXtimer=CreateTimer(60) CLOCKtimer=CreateTimer(1) Repeat WaitEvent() If EventID()=$4001 If EventSource()=AItimer ; do the updates EndIf If EventSource()=GFXtimer ; do the screen update Flip EndIf If EventSource()=CLOCKtimer ; update the clock EndIf EndIf Until KeyHit(1)
When a timerevent ($4001) happens, the program goes into that If-EndIf, next you check which timer it was by checking the EventSource() with your timers. So, if you were programming visually: checking on events is like having all the possible options on a large grid, and then you go narrowing the choices down until you have the right choise.
Logically it's best to narrow down in an efficient way by first filtering out the largest part of all the options.
So, this would work perfectly, but it's wrong.. :P
WaitEvent() If EventSource()=AItimer If EventID()=$4001 ; do the updates EndIf EndIf If EventSource()=GFXtimer If EventID()=$4001 ; do the screen update Flip EndIf EndIf If EventSource()=CLOCKtimer If EventID()=$4001 ; update the clock EndIf EndIf
it *would* be ok to first check on the EventSource() when you're checking all the canvas-actions in case you're using a canvas.. then you go about;
If EventSource()=MyCanvas If EventID()=$201 EndIf If EventID()=$202 EndIf If EventID()=$203 EndIf If EventID()=$204 EndIf ; etc. EndIf