Great explanation and break down Richard. I very much enjoyed this.
-- Tom McGrath III
http://lazyriver.on-rev.com
3mcgr...@comcast.net
On Oct 12, 2011, at 9:54 AM, Richard Gaskin wrote:
James Hurley wrote:
Thank you for this Bernd. It is going to take me a while to digest these new
Thank you for this Bernd. It is going to take me a while to digest these new
graphic features in 5.0. I confess I am unaware of the interaction between RR
code and the display on the screen. That's probably important. :-)
Like you, I don't see much improvement of 5.0 over 4.6 in animation.
James Hurley wrote:
Thank you for this Bernd. It is going to take me a while to digest these new
graphic features in 5.0. I confess I am unaware of the interaction between RR
code and the display on the screen. That's probably important. :-)
Like you, I don't see much improvement of 5.0 over
Hi Richard,
thank you for outlining the architecture of the new 5.0 LiveCode graphics
engine. That shurely helps to take advantage of it. And as you pointed out
we will have to experiment to find a setting that suits a particular
situation.
It just happens that Jim brought up the problem of
On 10/12/11 8:10 AM, James Hurley wrote:
I would like to see a little help from RR on these new features--by
way of a demonstration stack perhaps.
We all would. Richard's explanation was very good and with a few
guidelines I think we'll all catch on eventually and jaws will drop. I
know
These are exciting times for RR.
I am grateful to all who have responded to this thread--Bernd, Bob, Kevin,
Jacque, Ken, et. al.
And special thanks to Richard for taking the time for his expansive discussion
of the new features. THANK YOU.
I am grateful, but. I am not satisfied. I would
heh heh. nice.
On Oct 10, 2011, at 6:16 PM, Mark Wieder wrote:
Bob-
Monday, October 10, 2011, 4:59:15 PM, you wrote:
I guess the logic is, All that is not true is false.
Didn't Gödel disprove that?
--
-Mark Wieder
mwie...@ahsoftware.net
Hi,
to anyone who is interested in the stack moving two graphics and different
settings of syncrate, a handler that calls itself and does a lock screen
wait for syncrate milliseconds and unlock screen
and the Livecode 5.0 options of compositortype/tile/cache and layer mode and
wants to test all
I suspect this is a problem peculiar to the Mac.
When I run:
set the lockmoves to true
move grc Oval to tPoints without waiting
move grc rectangle to tNewPoints without waiting
set the lockmoves to false
The oval moves reasonably smoothly, but the rectangle take several abrupt
On 10/10/2011 10:22 PM, James Hurley wrote:
I suspect this is a problem peculiar to the Mac.
When I run:
set the lockmoves to true
move grc Oval to tPoints without waiting
move grc rectangle to tNewPoints without waiting
set the lockmoves to false
The oval moves reasonably
I should have said that this is a Mac OS 10 problem.
I suspect this is a problem peculiar to the Mac.
When I run:
set the lockmoves to true
move grc Oval to tPoints without waiting
move grc rectangle to tNewPoints without waiting
set the lockmoves to false
The oval moves
On Oct 10, 2011, at 2:22 PM, James Hurley wrote:
I suspect this is a problem peculiar to the Mac.
When I run:
set the lockmoves to true
move grc Oval to tPoints without waiting
move grc rectangle to tNewPoints without waiting
set the lockmoves to false
The oval moves
Ken,
Thanks for your careful test. This is driving me nuts and I can't find a
work-around.
I think the problem is RR not doing a screen refresh after each of the MULTIPLE
steps. (I have always, in OS 10) had to do a refresh after EACH step.
Would you please try this for me:
on mouseUp
put
Ok I get the first button moving smoothly and the second button jerky. If I run
each move individually without the other, then both are smooth. The horizontal
move leaves vertical line artifacts, which is not good. I get the same effect
even after commenting out the lock moves/unlock moves
A variation of this script shows that lockmoves is getting set to false before
the first move command. Given:
on mouseUp
put 200 into x
put 200 into y
put 2 into dx
put 1 into dy
repeat 100 times
put x,y cr after tPoints
add dx to x
Bob,
Here is what I get on the lockMove messages. (I'm on the email digest so I have
trouble copying your message.)
on mouseUp
put 200 into x
put 200 into y
put 2 into dx
put 1 into dy
repeat 100 times
put x,y cr after tPoints
add dx to x
end repeat
put 200
Hi Bob,
wouldn't
put comma and the lockmoves after mmsg
be rather
put comma the lockmoves after mmsg
?
in your version of the code you ask for the logical AND and this returns
false
Kind regards
Bernd
--
View this message in context:
Hi Jim,
I sent you a stack that decreases the syncrate and has a self-calling
routine with lock screen, wait x milliseconds unlock screen that smoothes
the movement of the two graphics moving along a path of 180 points
considerably.
Kind regards
Bernd
--
View this message in context:
DOH! of course.
Bob
On Oct 10, 2011, at 4:47 PM, BNig wrote:
Hi Bob,
wouldn't
put comma and the lockmoves after mmsg
be rather
put comma the lockmoves after mmsg
?
in your version of the code you ask for the logical AND and this returns
false
Kind regards
Bernd
--
yeah I had a brain fart and used AND instead of . DOH! I wonder then why
ANDING comma and true does not produce an error? Adding 1 to green certainly
does! I guess the logic is, All that is not true is false.
Bob
On Oct 10, 2011, at 4:44 PM, James Hurley wrote:
Bob,
Here is what I get
Bob-
Monday, October 10, 2011, 4:59:15 PM, you wrote:
I guess the logic is, All that is not true is false.
Didn't Gödel disprove that?
--
-Mark Wieder
mwie...@ahsoftware.net
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please
On Oct 10, 2011, at 6:04 PM, James Hurley wrote:
Ken,
Thanks for your careful test. This is driving me nuts and I can't find a
work-around.
I think the problem is RR not doing a screen refresh after each of the
MULTIPLE steps. (I have always, in OS 10) had to do a refresh after EACH
Ken,
The script I sent you was just an example and I simplified what I ultimately
would like to try.
I would like, for example, to simulate dynamical motion, for example projectile
motion, and that requires fairly close spacing of the points. Or motion around
an elliptical orbit. Generally
I just got a personal note from Benrd Niggemann who has experimented with a
number of parameters affecting the smoothness of the motion. He has found,
and I I have just confirmed it myself, that setting the syncrate (I was
totally unaware of such a property) to 6 rather than the default of
On 10/10/11 6:04 PM, James Hurley wrote:
Ken,
Thanks for your careful test. This is driving me nuts and I can't
find a work-around.
The workaround might be LiveCode 5.0, where animation has been greatly
enhanced.
That said, I have a script that moves two objects together that also
Ken-
Monday, October 10, 2011, 7:58:39 PM, you wrote:
that setting the syncrate (I was totally unaware of such a
I wasn't aware of syncRate either!
That makes a lot more sense than when I first read it as syn-crate.
--
-Mark Wieder
mwie...@ahsoftware.net
I just tried some values, and it appears that the documentation is wrong. The
example given of setting it to 12, makes you think that it's 12 frames per
second. Saying that 20 is the default and that decreasing the rate will reduce
CPU load, but may make things jerky, confirms that the help is
27 matches
Mail list logo
