Foever Block vs Run In Background

micro:bit
1

HI

I am starting to code a very simple invaders type game that uses a rotary encoder as a controller & an external Neopixel matrix as the display …

I have code that constantly updates the position of the base / enemy - currently its in a couple of FOREVER block

I am wondering what would be the pros/cons of using the RUN IN BACKGROUND block instead - would anyone be so kind as to explain what the difference is between these 2 ways of running code?

1 Like
2

Hi
I’m having the same question now. I’ve searched for a bit and stood upon your post. So i want to ask if you found something about the difference. Thanks in advance

3

no explanation as yet…

will chase it up on other forums

5

I think that forever is calling runForever, which creates a forever_stub to execute the code forever. The given code is the (Action)a in the following:

void forever_stub(void *a) {
    while (true) {
        runAction0((Action)a);
        fiber_sleep(20);
    }
}

So it runs the given code forever, with 20 millisecond breaks between each time it runs the code. (I don’t know the motivation for the specific delay, but there’s another thread on this forum where I made some guesses).

inBackground() calls runInParallel():

void runInParallel(Action a) {
    if (a != 0) {
        incr(a);
        registerGCPtr(a);
        create_fiber((void (*)(void *))runAction0, (void *)a, fiberDone);
    }
}

If the code itself doesn’t have a loop, it will run just one time.

The two main differences:

  1. forever includes a 20ms delay between each run of the provided code. run in background does not.
  2. forever includes the infinite loop to run the code forever. run in background requires the programmer to include the loop themselves or it’ll just run once (or until the loop is done).

The delay in forever is actually really beneficial. Without a delay other activities are “starved”. Here’s the basic idea:

  1. This Example uses in background without a delay. Button A is never detected because the loop is constantly running and it never gets a chance to respond to the button.
  2. This version works as expected (responds to Button A) because of the pause in the loop, which allows it to respond to other things.

I hope that helps!
Bill

2 Likes
6

@bsiever is completely correct!

1 Like
7

@bsiever thankyou for yet another excellent & informative reply

2 Likes
8

As he always seems to be !

1 Like
9

Since @bsiever’s answer is very good and I confused the discussion I linked to with one of its links, I instead provide only the links I found helpful for this subject:

@bsiever: Do you have the link to the thread with your guesses(and I believe I remember measurements), if relevant? I remember it was good, but always difficult to find again…

Trying to get a grasp of this myself…

10

@Vegz78 Here’s the prior, related discussion: Micro:bit analog read is agonizingly slow? (my first reply and second reply)

As part of that discussion I created a “faster forever” that has less of a delay and, consequently, is a little faster. It’s merely a proof-of-concept, but it’s at: https://github.com/bsiever/pxt-fastloops . There are two variations: a fast forever that can run about 250 times per second (depending on the code within it) and a faster forever with pause that can be even faster, but it’s more likely to starve out other tasks or miss events.

I was also starting on a variation that’s here: https://github.com/bsiever/pxt-fiberutils … It’s a little faster (360Hz), but doesn’t detect most events. It seems like the additional difficulty of using it would outweigh any benefits in most cases. (If/when time permits, I may look into event handling a bit more)

1 Like
11

Thanks for all the good help here, @bsiever, and sorry everyone for not being able to let go of this subject!

But I was intrigued by an assignment we got at a teacher’s seminar to program a reaction game using the micro:bit and some wires and aluminum foil. However, regardless of how much we tried to optimize the code there, and some efforts made in a discussion forum afterwards, I cannot get it to not feel somewhat sluggish nor shake the impression that the game is not entirely fair, depending the order of checking in the code and/or the intricacies of how the micro:bit hardware/system works, given everything very well described here:
https://makecode.microbit.org/device/reactive

Even though I am a noob without access to the required measuring equipment to test this scientifically and not yet have enough technical/coding skills to achieve this on my own, I am still motivated to start afresh to make a fairly good reaction game on the micro:bit.

Does anyone know if it with MakeCode on the micro:bit actually is possible to make a reaction game which is (or already has such working code to share):

  1. Quick enough?
  2. Fair? (uniform distribution or undecided if inputs happen exactly simultaneously (or within reasonable short intervals of eachother)
  3. Excact? (first input always wins, only one input per player, not possible to fill buffers with inputs, disqualified if input arrives before start signal)

(Or, at least, emulates well enough to feel like all of the above.)

I would guess that some of @bsiever’s fast loops above might help, and maybe something like @joshkeys19’s debouncer is required? But my attempts so far have not been especially reactive or exact / fair, and are now thrown away awaiting a fresh start / perspective.

Any help would be greatly appreciated!