So I'm well versed in BASIC programs, but am new to BASIC libraries, assembly programming, and home screen graphics. I just started trying to learn about how to use DoorsCSE to make more graphics based programs, but can't seem to get sprites to work. I tried to get the calculator to just display a few 8x8 tiles but it's displaying them 8x16 (twice as tall). Here's what I have:

Code:

This is to make a string to represent an entire lime green tile. Then I try to load and display it:

Code:

However, instead of displaying a 32x32 green square at the coordinates 50,50, I get a 32x64 rectangle at 50,100. I've done some tests involving trying to display only one tile, adding a design to the tile, etc., and I've found that every single pixel I have in the Ans string is corresponding to two displayed pixels, so it's basically stretching everything I do (tiles, coordinates, etc.) vertically by a factor of 2. Is there some value messed up somewhere? Am I using the commands incorrectly? What's going on?

Looks like someone didn't set half-res mode . My guess is that you are actually getting the correct height and half the width. Running real(0,1,1) before drawing the sprite should enable it. Don't forget to disable it at the end with real(0,1,0,1)

You were right thank you!
However I noticed that now that it is in half-res mode, when it displays an 8x8 tile it's actually using 16x16 pixels. So when half-res is disabled 8x8 tile is displayed on 8x16 pixels and when enabled it uses 16x16 pixels. Is there a way to have it display an 8x8 tile in only 8x8 pixels (meaning you could use each of the 320x240 pixels separately), or is 160x120 the highest resolution available?

The xLIBC commands won't be able to do it. Even if you try squashing your sprites so that they appear normally in full-res, you will only be able to get it to look right in one direction, not the other. However, Celtic's BufSprite (det(9,width,X,Y))command is meant to be used in full-res mode so it will display an 8x8 tile in an 8x8 block of pixels. It doesn't expect the same kind of input as the xLIBC commands you've been using though. You can read about how to use BufSprite here

Ok thank you. I'm looking at the documentation for BufSprite though and it doesn't have examples like the xLIBC ones do and I'm having trouble figuring out what it's asking for in Str9... I understand what it's saying with the 0 transparency and the H transparency, but not about the format of the sprite data. Is it using the same color pallet as xLIBC? If I were trying to create the same 8x8 green (07 on xLIBC color pallet) square as before, what would my Str9 look like if I'm using BufSprite?

No, it uses the OS's palette, and each pixel is one nibble (a single hex char). Here is how you would draw an 8x8 green square at (50,50).

Code:

Each 5 in Str9 represents a pixel. The height can be computed from the width so you don't need to specify it, hence why there is only one 8.