🤑 Indie game store🙌 Free games😂 Fun games😨 Horror games
👷 Game development🎨 Assets📚 Comics
🎉 Sales🎁 Bundles

Using 2-bit sprites in TIC

A topic by bert003 created 105 days ago Views: 305 Replies: 15
Viewing posts 1 to 10

I was told that 2-bit sprites can be used in TIC instead of 4-bit ones to gain an extra 512 sprites. (1024 in total)

How can this be done please?

Developer

It can't be done with the current Sprite Editor, but you can write a tool for TIC to edit and draw 2-bit sprites using poke4/peek4 by 0x4000... addr

(Edited 3 times)

Thanks for your reply.

However I still cannot understand how poke and poke4 differ.

I downloaded and tested this example:

NIBBLES_IN_SPR=8*8
SPR_SHEET_ADDR=0x4000*2
sprIx=5 
sprDataHex="a000000aa0f00f0aaaaaaaaaaafaaa6aafffaaaaaafaa6aaaaaaaaaa33333333" 
cls()
for i=1,NIBBLES_IN_SPR do
 nibble=tonumber(sprDataHex:sub(i,i),16)
 poke4(SPR_SHEET_ADDR+(NIBBLES_IN_SPR*sprIx)+i-1,nibble)
end
print("See sprite sheet, index = "..sprIx)
function TIC() end

But still the same sprite (TIC-80) logo is displayed in index 5.

Maybe someone can provide examples to show how poke4 can be used for 2-bit sprites please?

Thanks in advance

`poke4` writes nibble (half of byte, 4 bites) = pixel

`poke` writes a byte = 2 pixel

"But still the same sprite (TIC-80) logo is displayed in index 5" - there is written the contents of the string sprDataHex.
Clear the area of the sprite sheet and run the cartridge - you will see this

You can use LZW-compressor for graphics and save a lot of space, here is an example https://tic.computer/play?cart=86

Thanks for your reply alrado.

I understand that poke4 puts 1 pixel while poke puts 2 pixels

However how can you draw 2-bit (not 4-bit) sprites using poke4 please? Like the original NES sprites.

I was told by TIC support that if you use 2-bit sprites you gain an extra 512 sprites.

I would like to know how to use 0x4000 to store the 2-bit sprites and then store the 4-color palette maybe in map region 0x8000 as I was told.

I also saw your example of LZW-compressor. With 2 images it takes 16K of code. That is why I would like to use 2-bit if possible.

Imagine using 2-bit sprites with the LZW-compressor to have a lot more sprites.

An example code if possible would be great.

Thanks to all in advance for your time and help in this.

Any help on this please?

I'll write how I'll be free

I wrote an example of how you can store 2-bit sprites that take up half the amount of memory http://tic.computer/play?cart=100

(Edited 2 times)

Thanks a real lot for your time in this alrado. I really appreciate and that is exactly what I was referring to.

However I do not think I am understanding the technique you used.

In the FG I see 5 sprites with pixels of all colours. What are those? When I removed them and ran the cartridge, nothing was displayed.

And you used the BG to draw your sprites. Why?

I guess if you use the sprite editor, you are still limited to 256 sprites and 256 tiles right? How does this give us 512 sprites instead of 256?

And why are there 2 sets of sprites on screen? It is as if the whole BG area is being output as well and then the sprite at 50,50.

Excuse my lack of experience in this but I am asking to learn.

If you can find some time to add a little more comments, that would be great.

Thanks once again for your time and well done for the cartridge.

My example does the following:

1. I have a painted sprite the size of 4x3 cells, it is drawn in BG.

I put it on the screen at position 0,0. The rest of the space BG and FG is empty.

2. Now I read 2-bit pixel values from the screen, combine two values into one 4-bit value and save it in a table

3. I write down all the values from the received table into memory. For clarity, I wrote them down in the FG area, but this area can be any.

4. Now I show how you can display a 2-bit image.

Also, for clarity, I used the palette of the 2-bit CGA palette

Here you can see the animation

-- title: 2-bit sprite
-- author: Al Rado
-- desc: shows how convert native TIC-80 4-bit sprite to 2-bit
-- script: lua
-- input: gamepad
-- pal: 00000000ffffff00ffffffff000000000000000000000000000000000000000000000000000000000000000000000000

SPRITE_ADDR=0x4000*2
NIBBLES_IN_SPR=64
SPR_IX=256
ADDR=SPRITE_ADDR+NIBBLES_IN_SPR*SPR_IX

SPR_W=4*8
SPR_H=3*8

-- convert native sprite to 2-bit sprite and save to memory
cls()
spr(0,0,0,-1,1,0,0,4,3)

local nibbles={}
for i=0,SPR_W*SPR_H-1 do
 nibbles[#nibbles+1]=pix(i%SPR_W,i/SPR_W) 
end

for i=1,#nibbles,2 do
 local first=nibbles[i] << 2
 local second=nibbles[i+1]
 poke4(ADDR+i//2, first+second) 
end

-- draw 2-bit screen from memory
local posX=50
local posY=50
for i=1,SPR_W*SPR_H,2 do
 local val=peek4(ADDR+i//2)
 local first=val >> 2
 local second=val - (first << 2)
 pix(posX+(i-1)%SPR_W,posY+(i-1)/SPR_W,first)
 pix(posX+(i)%SPR_W,posY+(i)/SPR_W,second)
end

function TIC()
 -- not implemented
end

Thanks a lot. I understand better now.

However, in the beginning you have this:

SPRITE_ADDR=0x4000*2
NIBBLES_IN_SPR=64
SPR_IX=256
ADDR=SPRITE_ADDR+NIBBLES_IN_SPR*SPR_IX

You are using address 49152 (0xC000). Any reason behind this please?

Also, how does this example give me space for more sprites other than the 256 in the sprite editor? (excluding background tiles)

Thanks

ADDR - is address FG(BG addres + 256 sprites)
It may be different, at your discretion.
I agree, not quite correctly written, it will be more accurate:

SPRITE_ADDR=0x4000
BYTES_IN_SPR=32
SPR_IX=256
ADDR=(SPRITE_ADDR+BYTES_IN_SPR*SPR_IX)*2
(Edited 1 time)

Ok thanks.

So basically using 2-bit instead of 4-bit sprites does not make any difference in the number of sprites you have available. The number is always 512 (256 FG + 256 BG).

If you want more sprites, you can use the LZW compression and compress a sprite sheet as a string of text. Is that correct?

"So basically using 2-bit instead of 4-bit sprites does not make any difference in the number of sprites you have available. The number is always 512 (256 FG + 256 BG)." - this is not true.

I updated the example - https://tic.computer/play?cart=100

Now in the example the difference is more noticeable:

4-bit sprite takes 12 cells (4x3) -> 32x24 pixels -> 768 pixels

2 bit takes 6 cells (6х1) -> 48x8 pixels -> 384 pixels

But you lose the ability to view / edit graphics in the built-in editor and and API functions are not suitable for printing to the screen.

WOW! Now I understand the difference perfectly.

Thanks a million alrado for all your help and time in this!

It is exactly what I was looking for! Cannot thank you enough :)