What may be confusing you is how to come up with the hex data, if you are using BatLib or the BASIC sprite drawing routine I alluded to in a past topic. It works like this:

Look at the number 153. That is 1*10^{2}+5*10^{1}+3*10^{0}. Here is a binary number (binary only uses 1s and 0s since it is base 2):

10011001_{2} = 1*2^{7}+0*2^{6}+0*2^{5}+1*2^{4}+1*2^{3}+0*2^{2}+0*2^{1}+1*2^{0}=153

Now look at hexadecimal (base 16)

99_{16}=9*16^{1}+9*16^{0}=153

To create a sprite, you look at its pixels and convert them to binary. Pixel ON=1, Pixel OFF=0. From there, you convert it to hexadecimal. Luckily, every group of 4 binary digits equates to precisely 1 hexadecimal digit. In the above example, we used 10011001_{2}. Split that in groups of 4, starting on the left (the lowest digits), you get 1001_{b} and 1001_{b}, both of which are 9. This tells us that the hex for those 8 pixels is 99_{h}.

But what happens if you have something like 1101_{b}? In decimal (base 10), that is 13, but in hexadecimal, we need 16 single digits. We use letters A~F to represent the extra digits, where A=10, B=11, C=12,…, so 1101_{b}=D_{h} :)

Using asm libraries, you will almost always be creating sprites with a multiple of 8 pixels in each row (8 pixels = 8 **b**inary dig**its** = 8 bits = 1 byte). SO here is a sprite!

```
00111100 =3Ch
01000010 =42h
10000001 =81h
10000001 =81h
10000001 =81h
10000001 =81h
01000010 =42h
00111100 =3Ch
```

Combining all of the hex starting from the top, you get 3C4281818181423C, and this is your sprite data :)

This is how Axe, Grammer, BatLib, and Celtic3 do it, as well as other Assembly tools.

I happen to know BatLib pretty well, so I will show you how to use the command (reading the documentation):

`52-HexSprite dim(52,[option],"Hex",Height,X,Y,Logic)`

This tells us the arguments.

option is 1 if you are using pixel coordinates. **I suggest you use this if you want to move the sprite around. Use 0 if you are drawing tiles.**

"Hex" is the hex data for the sprite.** I gave an example of "3C4281818181423C"

Height is the height of the sprite in pixels. **In this case, 8.

X is the X coordinate of the sprite (0 to 11 unless using pixel coordinates) **We are using Option=1, so use pixel coordinates**

Y is the Y coordinate of the sprite. Use 0 to 63

Logic is the method of drawing the sprite:

0-Overwrite **simply overwrites the preexisting data**

1-AND **If wither the pixel on the screen is OFF or the pixel in the sprite is OFF, the pixel output will be OFF. Think of it like multiplication, 0x0=0, 0x1=0, 1x0=0, 1x1=1**

2-XOR **Any pixels ON in the sprite will invert the pixel on the screen**

3-OR **Any pixels ON in the sprite will draw ON on the screen. Does not erase pixels**

4-Erase **Any pixels ON in the sprite will erase the pixel on the screen**

There is no width input because it uses the length of the data divided by the

height to find the width (area/width=height). (it rounds up if there isn't

enough data). When using the regular draw mode, the X coordinate is multiplied

by 8. This is to maintain backwards compatibility with older versions of BatLib.

So put it all together:

dim(52,1,"3C4281818181423C",8,X,Y,2

That will invert the sprite on the screen. Do it again to leave no net change on the screen :D

Also, with BatLib, you will need to tell it when to update the screen, using dim(99. This allows for smoother (non flickering) graphics and lets you draw everything you need and not shoe the ser the whole process (this also massively speeds up drawing). This is true for most assembly graphics routines. In BatLib, you can simply combine the two commands. Then, because we want to draw it again, we can combine all three commands:

dim(52,1,"3C4281818181423C",8,X,Y,2,**99**,52,1,"3C4281818181423C",8,X,Y,2

I would personally keep the sprite date in Ans, to save memory and speed things up.