Page 1 of 1

Problem: polygon points moving/scaling 2x/4x ?

Posted: Mon Jan 21, 2019 11:57 pm
by Arvin
Dear community,

I'm working on a simulation with many small particles moving around the screen. I'm using invisible polygons graphics to do this and the particles are represented by "marker points".

It is working ok and as expected in the LiveCode IDE 8.1.9 on my MacBook Pro on MacOS El Capitan (v10.11.6), but when I create a MacOS standalone the horizontal and vertical positions of the particles (polygon marker points) seam to be positioned/moved/scaled to other positions that are 2x or 4x the distance as in the IDE. (not sure the X factor).

When I try the stack on a Mac mini 2018 with Mac OS Mojave, the 2x/4x artefact even turns up in the LiveCode IDE. Has this something to do with Retina hi-res screens? Is LiveCode confused on where to position polygon points using scripts if some screens have normal resolution while others have retina?

I have tried the usePixelScaling command but it doesn't seam to impact anything visually:

set the usePixelScaling to [true / false]

Is it something I can control so that LiveCode behaves the same in all environments? Positions of fixed UI items such as buttons and fields are correct in all environments, so the issue seams to be related to polygons and the script command:

set the points of grc "polygon" to particleList

Hope anyone has an idea what is going on.


Re: Problem: polygon points moving/scaling 2x/4x ?

Posted: Tue Jan 22, 2019 12:33 am
by Arvin
Studying this behaviour further, it looks like the screen is not updated when calling "unlock screen" in a script every time.

In some environments it is updated every time I call unlock screen (MacBook Pro with LC 8.1.9) even up to 60 fps, but in other environments such as stand alone or a faster Mac (maybe due to higher frame rates?) unlock screen seams to work asynchronous and at much slower frame rates..

Or that the unlock screen command draws the screen (the moving polygons) only every 2nd, 3rd, 4th time I call "update screen" from a script.

NB, I'm bypassing the event/messaging handling in these tests. Not using standard game loop like

send gameLoop to me in 2 ticks

Sorry if this is discussed before, but I could find any thread on it.


Re: Problem: polygon points moving/scaling 2x/4x ?

Posted: Thu Jan 24, 2019 1:02 am
by Arvin
Looking at this further, looks like stacks are forced to keep the event handling open for the screen to be drawn when calling "unlock screen" for all environments.

So my workaround is to use a standard game loop with "unlock screen" and a call like "send msg to me in x ticks". This seam to ensure that the screen is updated after every "unlock screen"", to get high frame rates.

Not using the message / event handling path seams to cause LiveCode to update screen asyncronously (relative to the "unlock screen" command, and at low frequency on certain environments like Mac stand alone and fast Macs. I still don't understand what is going on under the hood, but the workaround seams ok.

Initially I wanted the simulation with many sprites to run without the event handling to get max speed, but "send game loop to me in x milliseconds" works fast enough.

Re: Problem: polygon points moving/scaling 2x/4x ?

Posted: Thu Jan 24, 2019 10:03 am
by bogs
I sure wish I could help you out Arvin, but I've never fully understood the lock / unlock scenario and how it works in Lc. I've only ever achieved results I couldn't trust with it, and so stopped bothering with it.

People I am pretty sure *do* know more about it don't seem to visit the boards a lot, or don't use it for game loops.

The only site I've ever seen that was dedicated to gaming in Lc was this one, but I can't remember if it even went into the subject in depth (but probably does).

*Edit - I came across this as well, but not sure it applies here.

Re: Problem: polygon points moving/scaling 2x/4x ?

Posted: Thu Jan 24, 2019 8:08 pm
by Newbie4
I do not know if this helps but keep your code in the”lock/unlock” part short and do not issue any other messages/events in it.

As an example look at the code in part “C - Oops, It goes too slow” here: ... ppy-bird-3

The problem you are having seems like a timing one.

Re: Problem: polygon points moving/scaling 2x/4x ?

Posted: Thu Jan 24, 2019 10:06 pm
by Newbie4
Looking through old posts, I saw this response to one about erratic movement at viewtopic.php?f=9&t=31886&hilit=Wait+with+no+messages
.Re: erratic movement of controls with repeat
Report this post Quote
Post by jacque » Tue Dec 11, 2018 2:43 pm

Repeat loops are slow and waiting inside one is slower. The repeat loop is blocking besides, never a good thing. You could try "wait 0 with messages" which at least will allow the engine to clean up inside the loop. More importantly, set the button's layermode to dynamic and set acceleratedRendering to true so that the button will be cached.

"Move" of course is optimized for animation. You'd still want to set up acceleratedRendering and dynamic layermode for that. All animations work better when the object is cached in memory.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software |
Besides trying some of the commands mentioned above, you might try other versions of LiveCode as discussed in this post viewtopic.php?f=6&t=28591&hilit=Set+the+points

Re: Problem: polygon points moving/scaling 2x/4x ?

Posted: Mon Apr 01, 2019 10:54 am
by Arvin
Thanks for tips Newbie,

Two of the above mentioned solutions work. Just to clarify:

When using lock screen/unlock screen, the screen is not always updated when calling unlock screen. On newer/faster environments on Mac, having many moving objects moving (e.g. >1000) at higher frame rates, unlock screen will only redraw the screen 2-5 per sec - even if the lock/unlock screen combo is called with 10-60 frames per sec.

-The solution to force a screen update (drawing of the screen) after calling unlock screen, is to add one of these:

- wait 0 milliseconds with messages
- using a game loop with send (message) to me in 5 milliseconds

These solutions seams good/predictable. The engine event handling seams to force a screen update.