I have a sprite that has two costumes.
The costume reflects the state of a global variable.

If there is only one place where the global changes I might handle this using a message to the sprite.

A forever block would handle more cases, and allow easy expansion if more changes to the global are added.

But what if the costume change depends on a lengthy calculation - can I bog things down in the forever loop?
What if the global changes very rarely - does the forever loop still take a big chunk of processing time?
How smart is the interpreter about giving execution time to forever blocks?

s

(This should probably be in Help with Scripts.)

If the forever loop does lots of processing, then yes, you will slow things down, as the forever loop will get evaluated for every frame.

However, a pretty easy fix is to just remember the last state of the global variable, and only do the processing if it changes:

forever
    if <not <(global) = (last value)>> then
        . . . // lengthy processing...
        set [last value v] to (global)
    end
end

EDIT: you should probably also reset “last value” at the beginning to a value that isn't any of the values the global can take, in order to make sure the processing gets run at the beginning.

I put together a little profiler for forever loops.

If you do no visual processing in forever loops they run essentially at processor speed. (3 million or so per second on my machine)
As soon as you do any visual processing that number drops to 30 per second. Adding dozens of clones did very little to affect that number.

Here is a link to my profiler project. If the methodology is not sound please let me know.

Forever Profiler project: LeadToGold

s

LeadToGold wrote:

If the methodology is not sound please let me know.

To be honest, you're probably better off with an FPS counter. An interval of “0” isn't that helpful.

deltaTime is how many seconds it takes to run the forever loop (intervalCount - not an actual variable in my script) times.

When intervalCount is 10 (the default), that execution time is smaller than the timer resolution.

I did set intervalCount to 10000 and found that deltaTime was .003. That works out to about 3 million executions per second.

But you're right the profiler itself is not very useful. It might be better to have a true/false value letting you know if your forever loops are running at processor speed or screen update speed.

s