ory and speed. If we modify the program to confine the ellipses in one third of the screen (vertically speaking), we we can only use 16K at a time making the program playback much faster. This is essentially the same thing the first program did using the *RAMdisk*. That one however appears jerky because there are not enough frames of animation to make our eyes be fooled by the illusion of smooth movement. We can do that using **BANK LAYER** which is used to quickly copy data from a memory bank to the screen or vice versa. *The syntax is as follows:* **BANK** *n* **LAYER** *x,y,w,h* |*offset* **TO** [*raster_op*] *offset*|*x,y,w,h* which can copy any rectangular "window" of the current *layer* defined by *x,y,w* and *h* into a memory bank and back. **BANK LAYER** also supports effects defined by *raster_op* which can further enhance the display of the "window" you're copying making animation transitions even more interesting. More information regarding **BANK … LAYER** can be found in *Chapter 23 – The Memory*. ### Animation with the Sprite System The third way of animating things in *NextBASIC* is via the use of the *Sprite System*. *Sprites* are visual objects of a rectangular shape that can be placed anywhere in the screen and animated by moving them about but also perform animation within the object by rapidly replacing the object's bitmap (the image –or *pattern*– it displays). There are two kinds of *sprites* on the ZX Spectrum Next, 8-bit and 4-bit. The first can display 256 colours at once while the second 16. There is a maximum of 128 *sprites* and 64 *sprite patterns* in 8-bit mode and 128 in 4-bit mode. *NextBASIC* only supports the 8-bit mode *sprites* so we'll only discuss these. For more information regarding the use of 4-bit *sprites*, refer to *Chapter 22* and online at **specnext.com**. Information on 4-bit sprites is also included in the second volume of this manual. *Sprites* are 16 x 16 pixels in size and can be mirrored and rotated. They can also be anchored together to make a bigger sprite. The *Sprite System* has it's own RAM, located inside the FPGA that's at the core of the computer, which not accessible from the outside via standard **PEEK** and **POKE**; one can only write to it via **REG** commands and the special *sprite ports* (See *Chapter 22 for details), so we need to keep a copy of our sprites* in memory if we want to modify and send them to be displayed anew. ### Creating Sprites Sprites are created very similar to the way UDGs are created as we saw in Chapter 13. There are three major differeces however: - UDGs are 1-bit only while sprites (for *NextBASIC*) are 8-bit - UDGs are 8 x 8 while sprites are 16 x 16 pixels - UDGs are manipulated within the main memory map while sprites need to be stored in a bank in order to be used. The similarities however are obvious. Sprites can be easily made with **DATA** statements which –if using one of the wider display modes– can even be seen visually via the numbers. So where for a UDG you wrote 8 **DATA** statements of 8 bits each, for a sprite you write 16 **DATA** statements of 16 bytes each; the same essential thing but scaled up.