Demonstration of reusing sprite data inside larger sprite

[+Gemintronic]

Here is a demonstration of abusing using player0pointerlo to apparently squeeze more sprites out of your sprite data. Your sprite data can be larger than the sprite itself. By changing the lowest position inside the sprite data to start drawing your sprite we can make it appear like a different sprite.

 

The important bits of code are here:

 rem /** p0lo saves the starting value of the bottom position **/
 rem /** inside player0 sprite data **/
 p0lo = player0pointerlo

and here:

change_player0
 rem /** Randomize player0 x/y values **/
 player0x = rand
 player0y = rand&31
 rem /** Change the bottom starting point in the larger **/
 rem /** player0 sprite data **/
 player0pointerlo = (p0lo +(rand&3))
 rem /** Randomize the player0 size and duplication **/
 monsize = rand
 goto after_col

changespr.bas

changespr.bin

[bogax]

If you put your sprite data in to
a data stament you'll have a name
that you can use to refer to the
sprite data and you won't have to
use a variable to save the pointer.
You also save a few bytes of code
that sets up the pointers which you
would be duplicating.
But you have to make sure the data
doesn't cross a page boundary or at
least make sure no individual sprite
crosses a page boundary (in which case
you'ld have to deal with all 16 bits
of the pointer).(I'll have to play
with it some more but it sounds like
page crossings may not be a problem
with the DPC+ kernel)
Making sure the data doesn't cross
a page boundary is just a small bit
of asm and not a problem.
simplest I think is to just tell DASM
to page align it.

 asm
 align 256
end
 

That may not be needed in which case it'll
just waste space. If the total of your sprite
data approaches 256 bytes (so that there's
a good chance that it would cross a page
boundary) might as well put it all in one
place and use the page alignment
and of course the asm needs to go immediately
before the block of data you're aligning.

This (which I lifted from a list file)
fills with 0 bytes if the data would
cross a page boundary. You have to
supply it with the length of the data.

  rem fills in with zero bytes if necesary so that
  rem the sprite table doesn't cross a page boundary

  asm
  if (<*) > (<(*+datalength))
  repeat ($100-<*)
  .byte 0
  repend
  endif
end

If you use the usual player definiton
for the data you can still use a constant
and save the variable, but it's trickier
because the name is the line number
so pretty much any change to the program
will likely change the name.
You can dig into the asm listing and find
the address or you could read it from the
player pointer (then put it in a constant).
I think once you get the sprite data settled,
if bB is putting it into it's own bank,
the address will remain the same provided
the length of the actual data doesn't change.

Edited September 8, 2014 by bogax

[+Gemintronic]

I might need an example.bas to fully understand yer technique. The one variable used here is a tradeoff indeed. I suspect that there's a way to use the already allocated player0pointerlo but I never got it to work right :/

[bogax]

There's some of that here.

player0_parameterized.bas uses player0pointer

I forgot to mention that using a player statement
has the advantage that bB takes care of the
page boundaries


http://basicplay.netau.net/


I don't have one there that uses a constant with a
player statement but I've got one somewhere.

Really the easiest thing is just to assign the low byte
of the player pointer to a playfield variable and read
it that way (which assumes you have playfield variables
you can assign to). Of course you have to decipher the
binary then and it takes 4 bytes which you may have to
subtract when you remove the assignment.

edit

oops player0_parameterized.bas was the wong file

now fixed and augmented (see below) and uses

a player0 statement with a constant.

Edited September 8, 2014 by bogax

[+Gemintronic]

Thank you, sir! Bookmarked and perusing

[bogax]

here's something you could try

I've added it to the player0_parameterized.bas
mentioned above (and changed it to use a
player0 statement with a constant)

  rem this will read a byte into the score
  rem it's padded to exactly one page so it
  rem shouldn't change the page alignment
  rem if it's removed
  rem you will have to change the assignment of
  rem temp4 to whatever you want to read, of course
  rem and it will have to be a simple variable
  rem or a constant, indexing will throw the total off


  temp4 = player0pointer
  score = 0
  if temp4{7} then score = score + 128
  if temp4{6} then score = score + 64
  if temp4{5} then score = score + 32
  if temp4{4} then score = score + 16
  if temp4{3} then score = score + 8
  if temp4{2} then score = score + 4
  if temp4{1} then score = score + 2
  if temp4{0} then score = score + 1
  rem this is just padding
  temp4 = 0 : temp4 = 1 : temp4 = 2 : temp4 = 3
  temp4 = 4 : temp4 = temp4[0] + 6

[bogax]

this might be something

 

 

animated_sprite.bas

animated_sprite.bin

parameterized_animation.bas

parameterized_animation.bin

player0_parameterized.bas

player0_parameterized.bin

[wallaby]

 

 

this might be something

 

I have rabbit holed so far down this it isn't even funny anymore.

 

Your example works. So then I thought, why not make it so I store the lo and hi bits in data. Then I can use some fancy coding to select player 1 or 2 or whatever.

 

Storing the lo bit:

 

const player_0_lo = <playerpointers ;WORKS.

 

data player_pointers_lo

<playerpointers ;DOESN'T WORK

end

 

I thought it would be more elegant to change the player lo bit with a data table. Because you could type: player0pointerlo = player_pointers_lo[0] + 8

And that would work for player 0.

 

Instead of having to use a constant e.g: player0pointerlo = player_0_lo + 8

 

But, after typing that out. I don't think it matters. You probably save more space using a constant anyway. As long as I'm not going crazy with animation frames constants would work, I guess.

 

I keep getting dragged into a marathon battle with this game.