Sprite Order Rules

[matt7]

I was having some unexpected difficulties with sprite ordering, but I could not find in the documentation or anywhere here on the forum that provided detailed information on how sprite ordering works. Can two sprites have the same order? Or does manually assigning an order shift other sprites above and below that order? What about ordering across multiple pages? What about deleting sprites before others are created? How come some of my sprite show and sprite order commands seemed to be doing nothing?!?

So I decided to sit down and systematically test sprite ordering behavior in order to get the facts straight and figure out which assumptions I was making were incorrect. Below are my findings (I started with the basics described in the documentation and then got more complex as I went). The last two are the ones that were giving me problems in my program, but a lot of these were a surprise and are good to know!


1. Sprite with a higher order index is displayed above sprite with a lower order index.

Sprite "a" has order 0
Sprite "b" has order 1 -> "b" appears above "a"

2. Default sprite order depends on the order of creation (order index starts at 0).

Sprite "a" created -> "a" has order 0
Sprite "b" created -> "b" has order 1
Sprite "c" created -> "c" has order 2

3. Sprites can be assigned an order index manually using command SPRITE N$ ORDER K.

Sprite "a" created -> "a" has order 0
Sprite "b" created -> "b" has order 1
Sprite "c" created -> "c" has order 2
Sprite "a" order set to 3 -> "a" has order 3

4. Sprites can be assigned to an order index that other sprites also have, in which case the reordered sprite appears above all other sprites of that order index.

Sprite "a" created -> "a" has order 0
Sprite "b" created -> "b" has order 1
Sprite "c" created -> "c" has order 2
Sprite "a" order set to 1 -> "a" has order 1 ("a" appears above "b")

5. If multiple sprites have the same order index, a sprite can jump to the top of its order index group if one of the following events occur:

a. It is resized

Sprite "a" created -> "a" has order 0
Sprite "b" created -> "b" has order 1
Sprite "c" created -> "c" has order 2
Sprite "a" order set to 1 -> "a" has order 1 ("a" appears above "b")
Sprite "b" resized ("b" appears above "a")

b. It is made visible after previously being hidden

Sprite "a" created -> "a" has order 0
Sprite "b" created -> "b" has order 1
Sprite "c" created -> "c" has order 2
Sprite "a" order set to 1 -> "a" has order 1 ("a" appears above "b")
Sprite "b" hidden
Sprite "b" shown ("b" appears above "a")

c. It is copied (the copy jumps to the top)

Sprite "a" created -> "a" has order 0
Sprite "b" created -> "b" has order 1
Sprite "c" created -> "c" has order 2
Sprite "a" order set to 1 -> "a" has order 1 ("a" appears above "b")
Sprite "b" copy to "b2" -> "b2" has order 1 ("b2" appears above "a")

6. If a sprite is copied, the copy will have the same order index as the original (see "b" to "b2" above)

7. If the last created sprite is deleted, the next created sprite will reuse the last order number.

Sprite "a" created -> "a" has order 0
Sprite "b" created -> "b" has order 1
Sprite "c" created -> "c" has order 2
Sprite "c" deleted
Sprite "d" created -> "d" has order 2

(Sprite "d" has order 3 if "c" is not deleted, and "d" stays at order 3 if "c" is deleted after "d" is created)

8. If a sprite created before the last sprite is deleted, the next created sprite will continue with the next order number.

Sprite "a" created -> "a" has order 0
Sprite "b" created -> "b" has order 1
Sprite "c" created -> "c" has order 2
Sprite "b" deleted
Sprite "d" created -> "d" has order 3

9. If a sprite is reordered to the order index for the next sprite that will be created, the next sprite will still use that order index.

Sprite "a" created -> "a" has order 0
Sprite "b" created -> "b" has order 1
Sprite "c" created -> "c" has order 2
Sprite "a" order set to 3 -> "a" has order 3
Sprite "d" created -> "d" has order 3

10. Default sprite order index for next sprite to be created is maintained across pages.

Page "P1" set
Sprite "a" created -> "a" has order 0
Sprite "b" created -> "b" has order 1
Sprite "c" created -> "c" has order 2
Page "P2" set
Sprite "d" created -> "d" has order 3
Sprite "e" created -> "e" has order 4
Sprite "f" created -> "f" has order 5

11. Sprite order cannot be manually assigned if the page it belongs to is not set as the active page.

Page "P1" set
Sprite "a" created -> "a" has order 0
Sprite "b" created -> "b" has order 1
Sprite "c" created -> "c" has order 2
Page "P2" set
Sprite "a" order set to 3 -> "a" has order 0 (no effect)

12. Sprite will jump to the currently active page if it is shown after previously being hidden

Page "P1" set
Sprite "a" created -> "a" has order 0
Sprite "b" created -> "b" has order 1
Sprite "c" created -> "c" has order 2
Page "P2" set
Sprite "a" shown (no effect)
Sprite "a" hidden
Sprite "a" shown -> "a" now appears on page "P2" (with the same coordinates but now relative to page "P2")


#11 was my main problem, as I had no clue why some of my sprite order commands were working (I didn't realize this was only on the active page) while other sprite order commands seemed to be doing nothing (on pages that were visible but weren't the active page).

#12 was also a surprise and turned out to also be giving me problems, as it helped explain why some of my sprites weren't reappearing with a sprite show command. They were being moved to another page that happened to be hidden! (In my case, this was an active page that was hidden because it contains all my touch controls/touch targets that I wanted to be invisible.)

[matt7]

I was just rereading what I had written, and had a new thought about #11. I ran a new test and I believe I found a bug. (Mr. K, feel free to move this entire thread to the Bug reports subforum.)

Run the below code:

Code: Select all

DEF P()
  PAUSE 1
END DEF

DEF S()
  STOP
END DEF

'============================================================== 

PAGE "P1" SET
PAGE "P1" FRAME 120, 30, 200, 200
PAGE "P1" COLOR 0.6, 0.6, 0.6, 1

SPRITE "a" BEGIN 50,50      ' a: 0
  GRAPHICS CLEAR 1,0,0
SPRITE END
SPRITE "a" AT 50,50
SPRITE "a" SHOW

SPRITE "b" BEGIN 50,50      ' b: 1
  GRAPHICS CLEAR 0,1,0
SPRITE END
SPRITE "b" AT 60,80
SPRITE "b" SHOW

SPRITE "c" BEGIN 50,50      ' c: 2
  GRAPHICS CLEAR 0,0,1
SPRITE END
SPRITE "c" AT 90,60
SPRITE "c" SHOW

P

PAGE "P2" SET
PAGE "P2" FRAME 30, 180, 200, 200
PAGE "P2" COLOR 0.8, 0.8, 0.8, 1

SPRITE "d" BEGIN 50,50      ' d: 4
  GRAPHICS CLEAR 1,1,0
SPRITE END
SPRITE "d" AT 70,40
SPRITE "d" SHOW

SPRITE "e" BEGIN 50,50      ' e: 5
  GRAPHICS CLEAR 0,1,1
SPRITE END
SPRITE "e" AT 80,70
SPRITE "e" SHOW

SPRITE "f" BEGIN 50,50      ' f: 6
  GRAPHICS CLEAR 1,0,1
SPRITE END
SPRITE "f" AT 100,50
SPRITE "f" SHOW

P

SPRITE "b" ORDER 10

P

SPRITE "a" HIDE
SPRITE "a" SHOW

S

The line SPRITE "b" ORDER 10 actually sets the order of Sprite "e", so smartBASIC appears to know that "b" is the second sprite created on the page it resides on, but instead of setting the sprite order of "b", it sets the sprite order of "e" (the second sprite created on the currently active page). The same can be done with "a" and "d" (the first sprites created on each page), and presumably also with "c" and "f" (if there were a sprite above it to prove it was being reordered).

[Mr. Kibernetik]

Thank you for your sample and report.
Obviously this is a bug - sB cannot properly reorder sprites in non-active pages.

[Dutchman]

I have added subchapter "Sprite order rules" on page 55 in the PDF-manual