Data Tables

[RHillFake]

Is there anywhere were I can get information on how to make data tables for sprite rotation and learn how to implement them?

Thanks!

[bogax]

The only real advantage to using
a data statement for the sprite(s)
data is that you can give it your
own name which makes it easy to
assign it to a constant so you
can save a variable.
Also you can put the data in hexadecimal
or whatever and make things more compact
in the source.

But you don't have to use a data statement

You could use the player statement.

You could use seperate player statements
for the different sprites and choose
the appropriate one with eg an
on gosub statement.

Putting them all in one decleration
saves code is all

Here I've put the data in one long
player statement. Each 7 lines/bytes
is a single sprite.

The first 7 bytes is sprite 0
the next 7 bytes is sprite 1 etc.

The sprites are just like any other sprite
they're just stacked in one sprite
declaration.

A data statement would be exactly the same
except it would be a data statement not
a player statement but the data could be
exactly the same.

The number of the sprite is shown
in the score.

sprites.bas

sprites.bin

Edited August 18, 2014 by bogax

[RHillFake]

The only real advantage to using

a data statement for the sprite(s)

data is that you can give it your

own name which makes it easy to

assign it to a constant so you

can save a variable.

Also you can put the data in hexadecimal

or whatever and make things more compact

in the source.

 

But you don't have to use a data statement

 

You could use the player statement.

 

You could use seperate player statements

for the different sprites and choose

the appropriate one with eg an

on gosub statement.

 

Putting them all in one decleration

saves code is all

 

Here I've put the data in one long

player statement. Each 7 lines/bytes

is a single sprite.

 

The first 7 bytes is sprite 0

the next 7 bytes is sprite 1 etc.

 

The sprites are just like any other sprite

they're just stacked in one sprite

declaration.

 

A data statement would be exactly the same

except it would be a data statement not

a player statement but the data could be

exactly the same.

 

The number of the sprite is shown

in the score.

 

sprites.bas

 

sprites.bin

 

 

 

Thank you

[bogax]

Maybe I should elaborate a bit.

You can use a constant with the
player statement it's just a pain
because the label is the line number
of the player statement (ignoring
white space, labels, and "end")
so if you change anything there's
a good chance you'll have to figure
out the new label for the sprite data.

Sprites can't cross page boundaries.
If you use a player statement bB
takes care of that for you automatically.
If you use a data statement the simplest
way to make sure no sprite in it crosses
a page boundary is to align the data statement
with a page boundary and be sure there's
less than a page of sprite data.
You could in principle (I think, I haven't tryed
it) let a data statement cross a page boundary
provided no individual sprite in it crossed
a page boundary.
But then you'd have to deal with the high
byte of the sprite pointer and use 16 bit math
(might be worth it if you have a lot of sprite
data).

bB sticks the sprite tables at the end of
the program I think if you're using mutiple
banks you end up with the sprite data in
the last bank. A data statement goes where
ever you put it. Presumably if you were using
a data statement for your sprites the data
statement would have to be in the last bank.

It appears that the player statement is quite
happy with hex data as long as there's not more
than 8 bytes per line.

With a player statement if you eg put in
blank lines to seperate individual sprites
each blank line ends up as a 0 byte in the data.
That doesn't happen with a data statement.

[bogax]

Just for the hell of it I tryed to parameterize
the code so one could supply the details at the
beginning of the code.

I doubt if it's really practical
I'd probably do the code differently rather than
have it so generalized.

If no_sprites, the number of sprites in the data statment,
is 10 or less bB will use a hard coded multiply routine
rather than call a mutiplication sub routine (the same as it
does for any multiplication by a constant of 10 or less)

There's a bit of assembly (lifted from the kernel)
to fill in zero bytes if necessary to keep the data
statement from crossing a page boundary.
It must go immediately before the data statement.

There's no provision for sprite colors.
I don't expect the it would be very hard to
do sprite colors (probably with a data statement).

The assembler thows some errors but the code works and
seems to be correct so I guess it's stuff that gets
resolved after a couple passes but I'm not really sure.

Here the sprites are taken from the score digits.

You step through the sprites using joy right or left
Of course that's not how you'd select the sprites
for animation (you would use a timer or something).

Works with the standard kernel I don't know if it
would work with anything else.

sprites_parameterized.bas

sprites_parameterized.bin



edit:
here's something more animated

note there are symmetries here that could be
exploited using NUSIZx as the loon was suggesting

parameterized_animation.bas

parameterized_animation.bin



another one
removed the player no parameter
and added a parameter for the number of frames
between sprites changes
player pointer is updated directly (no sprite
number and so no multiplication)

player0_parameterized.bas

player0_parameterized.bin

Edited August 21, 2014 by bogax

[bogax]

Yet another one

This uses two lists one to indicate
the sprite to display and one for
a corresponding color.

If the color is odd the sprite is reflected.

The lists are in reverse order, first item
diplayed last, last item diplayed first.

The first item/last diplayed should be the
playfield background color to blank the sprite
at the end of the animation.

The animation starts when joy0fire is pressed

(its supposed to be an explosion).

list_animation.bas

list_animation.bin

Edited August 25, 2014 by bogax