I wasn't sure the best forum to submit this to, but given that the problem I describe below occurs when I export to HTML5, I thought I would start here.
I've created a little physics simulation/game I call "Thread the Needle" to show the relationship between distance, velocity, and acceleration. I'm used LiveCode 8.1 on a Macintosh. It works great when I run it as a standalone for the Mac, but when I export it as a standalone for Windows or HTML5, something odd happens.
Everything starts off fine. The simulation and game work just as expected. But, the program starts to speed up inexplicably with each new game or simulation try. It is important to point out that each new try begins with an "opencard" command. The program only consists of a single card. I put all of the opening scripts on the card script including a bunch of custom functions I created. This includes the main "loop" function that controls the simulation/game:
on mainEventLoop
if varRun is true then
checkGame
physicsEngine
end if
send mainEventLoop to me in 50 milliseconds
end mainEventLoop
The procedure "mainEventLoop" is originally called in the opencard script.
For the HTML5 version, if I choose to reload the page the program again works fine for the first try, but then it predictably speeds up in each successive try.
The same phenomenon occurs when I run the Windows standalone version. If I quit and relaunch the Windows standalone, it works just fine for the first try, but then the simulation/game gains speed with each successive try. It's as if the computer's processing power magically increases each time. (Given that mainEventLoop calls itself every 50 milliseconds, I would think this would create it's own speed limit.)
But again, all works fine if I stick to the Macintosh. So, this leads me to think the code is working properly, but that there is something uniquely odd with the Windows or HTML5 execution (at least when the program is built on a Macintosh).
If you want to run the program for yourself to see what I mean, here is the link to the HTML5 version of the project:
http://lrieber.coe.uga.edu/livecode/htm ... index.html
I also made a video demonstration of the simulation/game for use in my teaching at the University of Georgia, in case you just want to get a sense of how the program works. (This video was made using only a Macintosh, so the problem described above doesn't occur.)
https://www.youtube.com/watch?v=oJeXRvmT5QI
I'm guessing (hoping) that others have experienced this phenomenon also and might be able to share some insights as to what is happening and, more importantly, how to make the problem and to have the simulation/game run smoothly.
Thanks.
Lloyd Rieber
Strange Speeding Up in the Execution of a LiveCode Project
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
-
- VIP Livecode Opensource Backer
- Posts: 2262
- Joined: Thu Feb 28, 2013 11:52 pm
- Location: Göttingen, DE
Re: Strange Speeding Up in the Execution of a LiveCode Proje
Hi Lloyd,
you could try to cancel the current loop before starting a new one.
This should work on each platform and especially in the HTML5 standalone.
[Probably the Mac IDE holds, without the above cancelling, the additional mainEventLoops in a long row and absorbs them later on because the simulation needs more than the 50 millisecs of the loop's refresh.]
Hermann
p.s. Great stack!
you could try to cancel the current loop before starting a new one.
This should work on each platform and especially in the HTML5 standalone.
Code: Select all
on opencard
...
repeat 2 -- cancel current mainEventLoop
repeat for each line L in the pendingMessages
if L contains "mainEventLoop" then cancel item 1 of L
end repeat
end repeat
//Begin
mainEventLoop
end opencard
Hermann
p.s. Great stack!
shiftLock happens
-
- VIP Livecode Opensource Backer
- Posts: 4027
- Joined: Sun Jan 07, 2007 9:12 pm
- Location: Bochum, Germany
Re: Strange Speeding Up in the Execution of a LiveCode Proje
Hi Lloyd,
I agree with Hermann that the messaging seems to be the problem.
here you send "mainEventLoop" regardless of what happens, whether you show a dialog and so on. That is not necessary and piles up messages.
I tried to fix this by It effectively keeps the "mainEventloop" messages from piling up and it runs nicer in HTML5.
Note that I put a lock screen/unlock screen pair around checkGame and physicsEngine. You do a lot of screen updates in your handlers like graphics and fields. That is costly and can be avoided by locking the screen.
Furthermore your mainEventLoop does not have to run when the game is not actually running e.g. showing dialogs. I would move " send "mainEventLoop" to me in 50 milliseconds" inside the "if varRun is true" condition.
That needs a little more coding regarding varRun setting to true and false and when setting it to true to start the "mainEventLoop" again but saves a lot of processing cycles and then it does not interfere with the rest of the application.
My strategy to get some points was not to touch the arrowkeys at all. Then at least I did not have a negative score and at times I even hit a marble when it happened to be close enough to the middle line.
Kind regards
Bernd
I agree with Hermann that the messaging seems to be the problem.
Code: Select all
on mainEventLoop
if varRun is true then
checkGame
physicsEngine
end if
send mainEventLoop to me in 50 milliseconds
end mainEventLoop
I tried to fix this by
Code: Select all
on mainEventLoop
if varRun is true then
lock screen
checkGame
physicsEngine
unlock screen
end if
put the pendingMessages into tMessages
repeat for each line aLine in tMessages
if item 3 of aLine is "mainEventLoop" then cancel item 1 of aLine
end repeat
send "mainEventLoop" to me in 50 milliseconds
end mainEventLoop
Note that I put a lock screen/unlock screen pair around checkGame and physicsEngine. You do a lot of screen updates in your handlers like graphics and fields. That is costly and can be avoided by locking the screen.
Furthermore your mainEventLoop does not have to run when the game is not actually running e.g. showing dialogs. I would move " send "mainEventLoop" to me in 50 milliseconds" inside the "if varRun is true" condition.
That needs a little more coding regarding varRun setting to true and false and when setting it to true to start the "mainEventLoop" again but saves a lot of processing cycles and then it does not interfere with the rest of the application.
My strategy to get some points was not to touch the arrowkeys at all. Then at least I did not have a negative score and at times I even hit a marble when it happened to be close enough to the middle line.
Kind regards
Bernd
Re: Strange Speeding Up in the Execution of a LiveCode Proje
Thank you both, Hermann and Bernd! I finally got a chance to implement your suggestions and all now seems to be working great. Here's a link to the updated HTML5 version of my simulation/game:
http://lrieber.coe.uga.edu/livecode/htm ... index.html
It is very interesting to me how the fact that the symptoms of this problem never appeared in the Mac version, but I assume they would have eventually if the simulation was developed further.
So, thank you both for correctly diagnosing the problem and for giving me such great guidance on what code I needed to fix it.
@Bernd: Thank for sharing your "strategy" for playing the game. Perhaps there is a good metaphor here for life: Sometimes doing nothing is the right strategy! (Actually, I was thinking about adding little obstacles one must avoid in other levels, should I decide to develop this game further. But, I think I will add some code right away that keeps the target from displaying directly on the x-axis.
Finally, I'll be blogging about what I learned in designing this little project with your help and guidance. Here's the link to my blog:
http://learninglivecode.blogspot.com/
Thanks again - Lloyd
http://lrieber.coe.uga.edu/livecode/htm ... index.html
It is very interesting to me how the fact that the symptoms of this problem never appeared in the Mac version, but I assume they would have eventually if the simulation was developed further.
So, thank you both for correctly diagnosing the problem and for giving me such great guidance on what code I needed to fix it.
@Bernd: Thank for sharing your "strategy" for playing the game. Perhaps there is a good metaphor here for life: Sometimes doing nothing is the right strategy! (Actually, I was thinking about adding little obstacles one must avoid in other levels, should I decide to develop this game further. But, I think I will add some code right away that keeps the target from displaying directly on the x-axis.
Finally, I'll be blogging about what I learned in designing this little project with your help and guidance. Here's the link to my blog:
http://learninglivecode.blogspot.com/
Thanks again - Lloyd