We Americans are about to enter into the long Thanksgiving holiday weekend, so it is time for me to pause and reflect on all of the reasons I have to be thankful. There is much on a personal level I could mention, but given that this blog centers on my professional life, I wish to give thanks to the wonderful LiveCode community. And, the topic of this post is definitely in the spirit of my blog's title - learning LiveCode.
Recall I had been experiencing a strange speeding up within a little physics simulation/game I had created back in July. This problem baffled me, so I decided to post a note about the problem within the HTML5 LiveCode Forum. Two longtime LiveCode users, Hermann and Bernd, quickly responded. Each immediately zeroed in on the cause of the problem. My looping strategy has a major flaw in it. It creates a build up of pending messages. Each one restarts the loop, resulting in a sort of amplification effect. Instead of only one loop being in control at all times, multiple loops are created with each having an effect on the speed of the simulation. Through their kind assistance, Hermann and Bernd helped me to understand a little better the nuances of the pending messages feature in LiveCode. For more details, I've included below a copy of my post to the LiveCode HTML5 Forum along with the replies from Hermann and Bernd.
My physics simulation now runs great on all platforms, including HTML5. Click here to check it out for yourself. (The download takes awhile, so be patient.)
Most of my time over these past two months have been devoted to work on my Q sort app. I will post an update on that project soon, but I believe a problem that only Windows users had been experiencing is also related to this pending messages problem caused by my looping strategy. I haven't been able to test the new version of the Q Sort app thoroughly yet, so I'll withhold judgment until later if this is, in fact, the cause of the problem. But, I definitely was executing the looping strategy incorrectly in the Q sort app, so fixing it can only be a good thing.
This is just a nice example of how increased understanding of a problem in one LiveCode project - even a toy project - can be used to solve a problem in another, more serious, project.
A quick side note: Last week I gave a presentation at the E-Learn 2016 Conference in Alexandria, Virginia, about my Q sort research project. I think it went well. Most satisfying was the fact that no one in the audience had ever heard of the Q methodology. I like being the one to first alert people to this very interesting way to study subjectivity.
I like to tell people that Thanksgiving is my most favorite holiday of the year, with July 4th coming in a close second. Thanksgiving is all about family and July 4th is all about community. Also, we have yet to figure out a way to commercialize these two holidays. (Yes, the encroachment of the Christmas buying season on Thanksgiving has been a problem, but even that is finally beginning to be rolled back.) But for academics - faculty and students alike - Thanksgiving also provides a well-timed moment to both catch our breath and catch up. This post is a good case in point. I actually began writing it in mid-September. The past two months have been very busy and hectic. So, it is nice to finally give thanks publicly to Hermann and Bernd.
Finally, take note of the last paragraph by Bernd. He cleverly found a way to "hack" my little game, something I'll be sure to patch up if I continue working on it.
Postscript
I'm mindful of the fact that the Macy's Thanksgiving Day Parade may be the greatest example of commercialism. But hey, it's an American tradition!
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:
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/html5/lloyd_physics_game/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
Recall I had been experiencing a strange speeding up within a little physics simulation/game I had created back in July. This problem baffled me, so I decided to post a note about the problem within the HTML5 LiveCode Forum. Two longtime LiveCode users, Hermann and Bernd, quickly responded. Each immediately zeroed in on the cause of the problem. My looping strategy has a major flaw in it. It creates a build up of pending messages. Each one restarts the loop, resulting in a sort of amplification effect. Instead of only one loop being in control at all times, multiple loops are created with each having an effect on the speed of the simulation. Through their kind assistance, Hermann and Bernd helped me to understand a little better the nuances of the pending messages feature in LiveCode. For more details, I've included below a copy of my post to the LiveCode HTML5 Forum along with the replies from Hermann and Bernd.
My physics simulation now runs great on all platforms, including HTML5. Click here to check it out for yourself. (The download takes awhile, so be patient.)
Knowledge Transfer: Solving a Similar Problem in My Q Sort App
Most of my time over these past two months have been devoted to work on my Q sort app. I will post an update on that project soon, but I believe a problem that only Windows users had been experiencing is also related to this pending messages problem caused by my looping strategy. I haven't been able to test the new version of the Q Sort app thoroughly yet, so I'll withhold judgment until later if this is, in fact, the cause of the problem. But, I definitely was executing the looping strategy incorrectly in the Q sort app, so fixing it can only be a good thing.
This is just a nice example of how increased understanding of a problem in one LiveCode project - even a toy project - can be used to solve a problem in another, more serious, project.
A quick side note: Last week I gave a presentation at the E-Learn 2016 Conference in Alexandria, Virginia, about my Q sort research project. I think it went well. Most satisfying was the fact that no one in the audience had ever heard of the Q methodology. I like being the one to first alert people to this very interesting way to study subjectivity.
Final Thoughts
I like to tell people that Thanksgiving is my most favorite holiday of the year, with July 4th coming in a close second. Thanksgiving is all about family and July 4th is all about community. Also, we have yet to figure out a way to commercialize these two holidays. (Yes, the encroachment of the Christmas buying season on Thanksgiving has been a problem, but even that is finally beginning to be rolled back.) But for academics - faculty and students alike - Thanksgiving also provides a well-timed moment to both catch our breath and catch up. This post is a good case in point. I actually began writing it in mid-September. The past two months have been very busy and hectic. So, it is nice to finally give thanks publicly to Hermann and Bernd.
Finally, take note of the last paragraph by Bernd. He cleverly found a way to "hack" my little game, something I'll be sure to patch up if I continue working on it.
Postscript
I'm mindful of the fact that the Macy's Thanksgiving Day Parade may be the greatest example of commercialism. But hey, it's an American tradition!
My LiveCode Forum Post
Strange Speeding Up in the Execution of a LiveCode Project
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/html5/lloyd_physics_game/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
Re: Strange Speeding Up in the Execution of a LiveCode Project
Postby [-hh] » Sat Sep 17, 2016 8:55 pm
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.
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
[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!
Postby bn » Sun Sep 18, 2016 4:44 am
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
Re: Strange Speeding Up in the Execution of a LiveCode Project
Postby bn » Sun Sep 18, 2016 4:44 am
Hi Lloyd,
I agree with Hermann that the messaging seems to be the problem.
on mainEventLoop
if varRun is true then
checkGame
physicsEngine
end if
send mainEventLoop to me in 50 milliseconds
end mainEventLoop
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
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
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
