CV BASIC - NEED HELP WITH SPRITES

[drfloyd]

Hello

Begiiner with CV Basic

Why the game display 2 times the same sprite ?????

 

SPRITE 0 & SPRITE 1 display the first same figure, the first one.. cannot understand why

 

' REGATES

DEFINE SPRITE 0,2,sprites_bitmaps

CLS
PRINT AT 10,"SUPER REGATES"

dim x(4)
dim y(4)
x(1)=50
y(1)=50

x(2)=150
y(2)=150

game_loop:
	WAIT

	SPRITE 0,y(1),x(1),0,9
	SPRITE 1,y(2),x(2),0,10

	IF cont.left THEN x(1)=x(1)-1
	IF cont.right THEN x(1)=x(1)+1
	IF cont.up THEN y(1)=y(1)-1
	IF cont.down THEN y(1)=y(1)+1

	GOTO game_loop


sprites_bitmaps:
	BITMAP ".......XX......."
	BITMAP ".....XXXXXX....."
	BITMAP "....XXXXXXXX...."
	BITMAP "...XXXXXXXXXX..."
	BITMAP "..XXXXXXXXXXXX.."
	BITMAP ".XXXXXXXXXXXXXX."
	BITMAP ".XXXXXXXXXXXXXX."
	BITMAP "XXXXXXXXXXXXXXXX"
	BITMAP ".......XX......."
	BITMAP "XXXXXXXXXXXXXXXX"
	BITMAP ".......XX......."
	BITMAP ".......XX......."
	BITMAP "XXXXXXXXXXXXXXXX"
	BITMAP "XXXX.XXXXXX.XXXX"
	BITMAP ".XXXXXXXXXXXXXX."
	BITMAP "..XXXXXXXXXXXX.."

	BITMAP "................"
	BITMAP "................"
	BITMAP "....XXXXXXXX...."
	BITMAP "...XXXXXXXXXX..."
	BITMAP "..XXXXXXXXXXXX.."
	BITMAP ".XXXXXXXXXXXXXX."
	BITMAP ".XXXXXXXXXXXXXX."
	BITMAP "XXXXXXXXXXXXXXXX"
	BITMAP ".......XX......."
	BITMAP ".XXXXXXXXXXXXXX."
	BITMAP ".......XX......."
	BITMAP ".......XX......."
	BITMAP "XXXXXXXXXXXXXXXX"
	BITMAP "XXXXXXXXXXXXXXXX"
	BITMAP ".XXXXXXXXXXXXXX."
	BITMAP "..XXXXXXXXXXXX.."

 

[+5-11under]

SPRITE index,y,x,f,c

 

f is the sprite "frame". From the manual: F contains the sprite frame. You must multiply the desired sprite definition (0-63) by 4 to show the right sprite.

 

Try: SPRITE 1,y(2),x(2),4,10

It should show the 2nd pattern now

[+5-11under]

Also, maybe you knew this already, but when you say dim x(4), that creates 4 instances of x, i.e. x(0), x(1), x(2), and x(3).

It might make more sense to have sprite 0 at location x(0), so it's all 0, rather than having sprite 0 at location x(1), which could be confusing.

/It's demo code, though, so, like I said, maybe nothing new for you here.

[drfloyd]

ok thanks, indeed i should indicate 4 for the second Sprite... little strange... but OK it works

 

0 to 63 step 4.... Does it means that we are limite to 16 different sprites ???

Edited May 8 by drfloyd

[+nanochess]

59 minutes ago, drfloyd said:

ok thanks, indeed i should indicate 4 for the second Sprite... little strange... but OK it works

 

0 to 63 step 4.... Does it means that we are limite to 16 different sprites ???

 

The sprite bitmap definitions are contained in a 2K block in the VRAM. For CVBasic this is set up to VRAM addresses $3800-$3fff.

 

The VDP allows a seldom used 8x8 pixels sprite mode, so by default, CVBasic starts with 16x16 pixels sprite mode. Each 16x16 sprite uses the space of four 8x8 sprites.

 

When defining sprites the first argument of DEFINE SPRITE is a sprite number 0-63, and CVBasic internally maps this to the VRAM where each 16x16 sprite uses 32 bytes of VRAM, for a total of 64 different sprite bitmaps.

 

However, the SPRITE statement data is written directly to the VDP, and the argument to select the sprite bitmap should be multiplied by 4 to account for the fact that each 16x16 sprites uses the space of four 8x8 sprites.

 

[drfloyd]

Thank you NanoChess ! It's clear

[drfloyd]

additionnal question :

 

As my RPG game will by 8x8 tiles, I would like to use 8x8 sprites in complement

How can I process for 8x8 sprites ?

[+nanochess]

There is no direct support for 8x8 sprites in CVBasic.

 

This will set the 8x8 sprite mode.

 

ASM halt
ASM ld bc,$C001
ASM call WRTVDP

 

When you define sprites, just remember CVBasic defines them in blocks of 4 sprites. So DEFINE SPRITE 0,64 would define the whole of the 256 sprites (64x4).

 

 

[Jess Ragan]

I get why the sprite ID jumps in increments of four (each sprite consists of 4 blocks of 8x8 graphic data), but I don't get why the X and Y coordinates are reversed in the SPRITE command. Isn't it common to specify horizontal, then vertical coordinates?

[+nanochess]

26 minutes ago, Jess Ragan said:

I get why the sprite ID jumps in increments of four (each sprite consists of 4 blocks of 8x8 graphic data), but I don't get why the X and Y coordinates are reversed in the SPRITE command. Isn't it common to specify horizontal, then vertical coordinates?

It is because that is the order in the VRAM memory.

[Pixelboy]

12 hours ago, Jess Ragan said:

I get why the sprite ID jumps in increments of four (each sprite consists of 4 blocks of 8x8 graphic data), but I don't get why the X and Y coordinates are reversed in the SPRITE command. Isn't it common to specify horizontal, then vertical coordinates?

It's a technical quick of the graphics chip, and the reason for it has to do with the "207 code": In the sprite attribute table, when the VDP encounters the value "207" as the "y" value, it interprets this as "end of sprite list", and it will ignore the rest of the data in the sprite attribute table.

 

So for example, let's say you have only two sprites to display on the screen, you place the 207 value in the "y" value of the third sprite, and only those two sprites will be displayed.

 

For this to work properly, the "y" value has to be the first byte of each sprite in the table, so that's why "y" comes before "x". It makes life simpler for the VDP.

 

[+nanochess]

The correct value to end sprite processing is 208.

 

However, CVBasic currently does sprite flicker by default (rearranging sprites on the screen), so you need to invoke SPRITE FLICKER OFF to use the 208 value.

 

[Pixelboy]

Ah, I stand corrected. I was sure it was 207. 

 

[drfloyd]

hi,

 

How diseable the display of a sprite on the screen ? Except by putting it out of the screen ?

 

It's strange, when a change BANK to another BANK, the sprite of the last Bank is still displayed on the screen

[Pixelboy]

Banks only apply to the cartridge, while VRAM (video RAM) is located inside the ColecoVision console. Once you place data in VRAM, it stays there until you change it. Switching to a different bank does nothing to VRAM all by itself.

 

EDIT: To answer your sprite question, the VDP will always display all 32 sprites in the sprite attribute table during every screen refresh cycle unless you place the y=208 marker somewhere in that table. So if the number of sprites to display on screen varies as your game progresses (adding/removing projectiles, or whatever) then you just have to manage your usage of the sprite attribute table properly.

 

EDIT #2:

 

"However, CVBasic currently does sprite flicker by default (rearranging sprites on the screen), so you need to invoke SPRITE FLICKER OFF to use the 208 value."

 

Ah, so where CVBasic is concerned, "sprite flicker management" means "automatic sprite attribute table management". Good to know. 

 

Edited May 11 by Pixelboy

[+nanochess]

6 hours ago, drfloyd said:

hi,

 

How diseable the display of a sprite on the screen ? Except by putting it out of the screen ?

 

It's strange, when a change BANK to another BANK, the sprite of the last Bank is still displayed on the screen

 

Anything you write to VRAM (DEFINE CHAR, DEFINE BITMAP, DEFINE SPRITE, SPRITE, SCREEN) is "eternal" until you erase it. It doesn't matter if you change banks, as these are local to CPU, and the VRAM is completely separate.

 

The correct way to disable a sprite is by using SPRITE num,$D1,0,0,0

 

For example, you can see an example in Camelot Knights source code where I erase sprites 4 to 31.

 

	FOR c = 4 TO 31
		SPRITE c, $d1, 0, 0, 0
	NEXT c

 

[AnalogKid]

On 5/9/2024 at 5:48 PM, Jess Ragan said:

I get why the sprite ID jumps in increments of four (each sprite consists of 4 blocks of 8x8 graphic data), but I don't get why the X and Y coordinates are reversed in the SPRITE command. Isn't it common to specify horizontal, then vertical coordinates?

The VDP expects to be fed the sprite bytes in the order y, x, pattern, color.  When calculating position in linear bitmap memory it's convenient to have y come first because it's y*horiz resolution + x

[drfloyd]

On 5/9/2024 at 6:37 PM, nanochess said:

There is no direct support for 8x8 sprites in CVBasic.

 

This will set the 8x8 sprite mode.

 

ASM halt
ASM ld bc,$C001
ASM call WRTVDP

 

When you define sprites, just remember CVBasic defines them in blocks of 4 sprites. So DEFINE SPRITE 0,64 would define the whole of the 256 sprites (64x4).

 

 

 

I put the 3 ASM lines this at the beginning of my code (to come back to 8x8 sprites)

 

But it generate freeze of my program

[youki]

I did not have the time yet to try CV Basic.

 

But may be ,  you have to  save and restore your BC Register.

 

Try to put :

 

ASM push bc       at the start of your ASM lines

 

and 

 

ASM pop bc   at the end.

 

 

[+nanochess]

Don't put assembler at the very start of your program, put at least one executable statement like MODE or CLS.

 

[drfloyd]

still do not work,

 

Not urgent, i keep my 16x16 sprites for now....

 

I will show you a part of the code later, to understand what is wrong.

[Mike Lee]

Sorry for bringing this old thread up but it was directly related to a question I had.  What if there was a 3rd bitmap?  Maybe I've been staring at it too long, and I get 0 and 4 values for the 1st two, but 8 or 12 doesn't seem right for the 3rd. I know I'm reading too much in to it.  What am I missing?

[+nanochess]

30 minutes ago, Mike Lee said:

Sorry for bringing this old thread up but it was directly related to a question I had.  What if there was a 3rd bitmap?  Maybe I've been staring at it too long, and I get 0 and 4 values for the 1st two, but 8 or 12 doesn't seem right for the 3rd. I know I'm reading too much in to it.  What am I missing?

Let us suppose you are drawing a triple-color sprite:

 

DEFINE 16, 3, sprite_bitmaps      ' Use slots 16-18 for 3 sprites (16x16 each one)

SPRITE 0, y - 1, x, 16 * 4, 9     ' First one in pink color, for face.
SPRITE 1, y - 1, x, 17 * 4, 5     ' Second one in blue color, for pants.
SPRITE 2, y - 1, x, 18 * 4, 3     ' Third one in green color, for shirt.

sprite_bitmaps:
      ' Put here three 16x16 bitmaps.
      ' First one should be the face and hands.
      ' Second one should be the pants.
      ' Third one should be the shirt.

 

I've used different numbers so you can see exactly what are you doing.

 

The VDP memory can contain 64 different sprite definitions, we use the space for definition 16, 17, and 18.

 

Now we use three sprite attributes to display these, and you can see the "magic expression" multiplying by 4 in order for the VDP to access the correct sprite.

 

You could use more SPRITE statements and replicate the same sprite in other position. Because the memory for sprite display (32 sprites) is independent of the table for sprite bitmaps (64 bitmap definitions). For example:

 

SPRITE 3, y - 1, x + 32, 16 * 4, 9     ' First one in pink color, for face.
SPRITE 4, y - 1, x + 32, 17 * 4, 7     ' Second one in turquoise color, for pants.
SPRITE 5, y - 1, x + 32, 18 * 4, 13     ' Third one in magenta color, for shirt.

 

[Mike Lee]

Thanks for the visual representation.  It's more clear to me now.  I guess I needed a visual aid...

 

Made a quick bit of code to try it out but I'm having trouble getting the 3rd sprite to display properly (it's the top one on screen, bottom in code).  Sorry copy and paste kills the formatting.

 

' Test

    CLS

    DEFINE SPRITE 16, 3, bitmaps

 

    ' Sprite 0    
    x = 120
    y = 175

 

    ' Sprite 1
    x1 = 120
    y1 = 90    

 

    ' Sprite 2
    x2 = 120
    y2 = 40
    
main_loop:
    
    SPRITE 0, y - 1, x, 16 * 4, 10
    SPRITE 1, y1 - 1, x1, 17 * 4, 8
    SPRITE 2, y2 - 1, x2, 18 * 4, 8

 

    WAIT 
    
    GOTO main_loop

 

bitmaps:
    BITMAP "................"
    BITMAP ".......XX......."
    BITMAP ".......XX......."
    BITMAP ".......XX......."
    BITMAP ".......XX......."
    BITMAP "......XXXX......"
    BITMAP "X....XX..XX....X"
    BITMAP "X...XXX..XXX...X"
    BITMAP "X..XXX....XXX..X"
    BITMAP "XXXXXX....XXXXXX"
    BITMAP "XXXXXXX..XXXXXXX"
    BITMAP "..XXXXXXXXXXXX.."
    BITMAP "..XX.XXXXXX.XX.."
    BITMAP "...XX......XX..."
    BITMAP "....XXXXXXXX...."
    BITMAP "......XXXX......"

 

    BITMAP "................"
    BITMAP "................"
    BITMAP "................"
    BITMAP "................"
    BITMAP "......XXXX......"
    BITMAP ".....X....X....."
    BITMAP "....X.X..X.X...."
    BITMAP "...X........X..."
    BITMAP "...X..X..X..X..."
    BITMAP "....X..XX..X...."
    BITMAP ".....X....X....."
    BITMAP "......XXXX......"
    BITMAP "................"
    BITMAP "................"
    BITMAP "................"
    BITMAP "................"

 

    BITMAP "......XXXX......"
    BITMAP "....XXXXXXXX...."
    BITMAP "...XX......XX..."
    BITMAP "..XX.XXXXXX.XX.."
    BITMAP "..XXXXXXXXXXXX.."
    BITMAP "XXXXXXX..XXXXXXX"
    BITMAP "XXXXXX....XXXXXX"
    BITMAP "X..XXX....XXX..X"
    BITMAP "X...XXX..XXX...X"
    BITMAP "X....XX..XX....X"
    BITMAP "......XXXX......"
    BITMAP ".......XX......."
    BITMAP ".......XX......."
    BITMAP ".......XX......."
    BITMAP ".......XX......."
 

 

[+nanochess]

I can see you defined three sprites, but the third one is simply the spaceship turned upside-down instead of the third color sprite.