Page 1 of 1
Back to a little basic way handlers execute
Posted: Thu Aug 09, 2012 3:15 pm
by 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...?
Re: Back to a little basic way handlers execute
Posted: Thu Aug 09, 2012 3:19 pm
by Klaus
Hi Gary,
try this:
...
wait 1 tick WITH MESSAGES
...
Best
Klaus
Re: Back to a little basic way handlers execute
Posted: Thu Aug 09, 2012 4:06 pm
by 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..
Re: Back to a little basic way handlers execute
Posted: Thu Aug 09, 2012 4:11 pm
by 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
Re: Back to a little basic way handlers execute
Posted: Thu Aug 09, 2012 4:24 pm
by 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..?
Re: Back to a little basic way handlers execute
Posted: Thu Aug 09, 2012 10:24 pm
by jacque
Code is executed in order, line by line. Is the screen locked?
Re: Back to a little basic way handlers execute
Posted: Thu Aug 09, 2012 10:48 pm
by 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
Re: Back to a little basic way handlers execute
Posted: Thu Aug 09, 2012 11:11 pm
by 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.
Re: Back to a little basic way handlers execute
Posted: Thu Aug 09, 2012 11:58 pm
by 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
Re: Back to a little basic way handlers execute
Posted: Fri Aug 10, 2012 12:18 am
by 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.
Re: Back to a little basic way handlers execute
Posted: Fri Aug 10, 2012 7:30 pm
by 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.