Back to a little basic way handlers execute

[doobox]

Hi there,

One of my handlers is currently puzzling me...

Code: Select all

on stopGame
   if the environment is "mobile" then 
      mobileStopPlayingOnChannel "game"
   end if
   playSound "gameover.wav"
   put false into sBubbleGameIsRunning
   show button "backToMenu"
   show button "gameOver"
   show button "replay"
   wait 1 tick // I would expect at this point i would see the game over button and replay button
   // but i dont until checkIfHighScore below has finished doing it's stuff
   checkIfHighScore
end stopGame

I should note that "checkIfHighScore" has an ask function in there. But still why is the code getting ahead of it's self here, and showing me the ask dialogue before doing the stuff instructed in the "stopGame" handler...?

[Klaus]

Hi Gary,

try this:
...
wait 1 tick WITH MESSAGES
...


Best

Klaus

[doobox]

That does not work either Klaus.even this does not work "5 ticks"

Code: Select all

on stopGame
   if the environment is "mobile" then 
      mobileStopPlayingOnChannel "game"
   end if
   playSound "gameover.wav"
   put false into sBubbleGameIsRunning
   show button "backToMenu"
   show button "gameOver"
   show button "replay"
   wait 5 ticks with messages
   checkIfHighScore
end stopGame

It's definetely jumping straight onto the "checkIfHighScore" handler where the ask function resides.
Because after you answer the ask, you then see the 5 tick pause before it shows the buttons it was meant to show before jumping into the "checkIfHighScore" handler..

[doobox]

Could it be something to do with the way i call "stopGame" and then the "makeBubbleRed" handler at virtually the same time.
"makeBubbleRed" is not really slow though :

Code: Select all

on makeBubbleRed tTheNumber
   set the backgroundColor of graphic ("bubbleGraphic" &  tTheNumber) of group ("bubbleGroup" & tTheNumber) to "#ff0000"
   set the blendLevel of graphic ("bubbleGraphic" &  tTheNumber) of group ("bubbleGroup" & tTheNumber)  to 50
end makeBubbleRed

Code: Select all

on handleBubbles
         repeat for each key tBubbleGroupName in sBubbleNames
            set the top of group tBubbleGroupName to the top of group tBubbleGroupName - 2
            if random(2) is 1 then
               set the left of group tBubbleGroupName to the left of group tBubbleGroupName + 1
            else
               set the left of group tBubbleGroupName to the left of group tBubbleGroupName - 1
            end if
            
            if the top of group tBubbleGroupName < the top of this card + 80 then
               stopGame
               put char -1 of tBubbleGroupName into tTheNumber
               makeBubbleRed tTheNumber
            end if
         end repeat
end handleBubbles

[doobox]

I just tried something that revealed even more unexpected results to me:

I switched the 2 handler calls in the "HandleBubbles" handler around. So it now call "makeBubbleRed" before "stopGame"
Holey moley...! it now jumps to "stopGame" before "makeBubbleRed" in the "HandleBubbles" handler.
This of course still jumps ahead of its self as before in the "stopGame" Handler. So you now see the ask dialogue yet another handler to early.

So what seems to be the case here.. is the code is always jumping ahead and checking through all the upcoming handlers, before executing any code in the current handler. and if it finds an ask function anywhere down the road ahead, it jumps right to that ask function, before continuing.
This cant be expected behavior is it..?

[jacque]

Code is executed in order, line by line. Is the screen locked?

[doobox]

Hi Jacque,
The screen was not locked by me purposely, but at the time my handlers are executing, i am still running the "updateScreen" code as in the game academy.
That has a handler in there that locks the screen on each iteration. I believe this is running at 50 iterations a second :

Code: Select all

on dispatchUpdateScreen
   local tThisFrameTime
   put the long seconds into tThisFrameTime
   
   if sStartUpdateTime is 0 then
      put the long seconds into sStartUpdateTime
   end if
   
   lock screen
   dispatch "updateScreen" to this card with tThisFrameTime
   unlock screen
   
   local tTheTimeNow
   put the long seconds into tTheTimeNow
   
   local tNextFrameCount
   put round((tTheTimeNow - sStartUpdateTime) * sFrameRate + 0.5) into tNextFrameCount
   send "dispatchUpdateScreen" to me in (sStartUpdateTime + (tNextFrameCount * (1 / sFrameRate)) - tTheTimeNow) seconds
   put the result into sUpdateMessageId
end dispatchUpdateScreen

Still unsure why it would effect the way my handlers execute, if the screen happens to be locked by that "dispatchUpdateScreen" handler..?

I got round my issue in this case by using "send" for my handler. But i would love to understand why i have had to do this.

Code: Select all

on stopGame
   if the environment is "mobile" then 
      mobileStopPlayingOnChannel "game"
   end if
   playSound "gameover.wav"
   put false into sBubbleGameIsRunning
   show button "backToMenu"
   show button "gameOver"
   show button "replay"
   lock screen
   send checkIfHighScore to this card in  500 milliseconds
   unlock screen
end stopGame

So just for clarity.. the below handler, executed the "checkIfHighScore" before anything else in the handler:

Code: Select all

on stopGame
   if the environment is "mobile" then 
      mobileStopPlayingOnChannel "game"
   end if
   playSound "gameover.wav"
   put false into sBubbleGameIsRunning
   show button "backToMenu"
   show button "gameOver"
   show button "replay"
   wait 1 tick with messages
   checkIfHighScore
end stopGame

[doobox]

It does not appear to be related to any Lock screen functions, as i just tested with an ammended handler that instigates the stopGame handler, to stop the game loop with the lock screen function in it, before moving on to call "stopGame".. Same results.

Code: Select all

      if the top of group tBubbleGroupName < the top of this card + 80 then
         put true into sBubbleGameIsRunning // this stops this handler looping
         stopUpdatingTheScreen // this stops the game loop entirely 
         stopGame
         put char -1 of tBubbleGroupName into tTheNumber
         makeBubbleRed tTheNumber
      end if
   end repeat
end handleBubbles

There are no other lock screen functions in the code.

[doobox]

Added some visual checks to really see whats going on...
new code places the order of execution into a field named "test".
Test results :

Code: Select all

on handleBubbles
   repeat for each key tBubbleGroupName in sBubbleNames
      set the top of group tBubbleGroupName to the top of group tBubbleGroupName - 2
      if random(2) is 1 then
         set the left of group tBubbleGroupName to the left of group tBubbleGroupName + 1
      else
         set the left of group tBubbleGroupName to the left of group tBubbleGroupName - 1
      end if
      
      if the top of group tBubbleGroupName < the top of this card + 80 then
         put char -1 of tBubbleGroupName into tTheNumber
         put "1" & cr into field "test"
         makeBubbleRed tTheNumber
         put "2" & cr after field "test"
         stopGame
         put "3" & cr after field "test"
      end if
   end repeat
end handleBubbles

Code: Select all

on stopGame
   put "4" & cr after field "test"
   if the environment is "mobile" then 
      mobileStopPlayingOnChannel "game"
   end if
   put "5" & cr after field "test"
   playSound "gameover.wav"
   put "6" & cr after field "test"
   put false into sBubbleGameIsRunning
   put "7" & cr after field "test"
   show button "backToMenu"
   put "8" & cr after field "test"
   show button "gameOver"
   put "9" & cr after field "test"
   show button "replay"
   put "10" & cr after field "test"
   lock screen
   send checkIfHighScore to this card in  500 milliseconds // put "11" & cr after field "test" is inside this handler
   unlock screen
   put "12" & cr after field "test"
end stopGame

The test field after the game stops shows not what you would expect :

1
2
4
5
6
7
8
9
10
12
3
11

[doobox]

Ah.. ha..! Sorted..

I was so close earlier thanks to You pointing out the screen maybe locked.

I added code to stop the screen updates that contain a loop with lock unlock screen in there.
But neglected to realize that when i stopped the screen updates, the loop is running so fast it may have terminated in a locked screen position.
Sod's law..! during my tests it looks like that is what was happening.
Every time i tested i was stopping in a 2/1 chance screen locked position.

So now i do :

Code: Select all

      if the top of group tBubbleGroupName < the top of this card + 80 then
         send stopUpdatingTheScreen to this stack in 0 milliseconds
         unlock screen
         put char -1 of tBubbleGroupName into tTheNumber
         makeBubbleRed tTheNumber
         stopGame
      end if
   end repeat
end handleBubbles

unlock screen, just after stopping the screen updates, just in case it has stopped in a screen locked position. 2/1 chance.

[jacque]

Glad you got it solved. BTW, the results you got in the numbering scripts are what I'd expect. The handler will detour through the stopGame handler before it executes the last line of the handleBubbles handler, which is why the numbers are in that order.