Rough demo of Al_Nafuur sprite data sharing code

[+Gemintronic]

So, one of my long standing wishes is to re-use a single sprite on multiple player objects.  This is especially advantageous for multi sprite kernel games where you might have to duplicate identical sprite data as each virtual sprite needs its own specific data statement.  That adds up fast when you want, say, 5 different virtual sprites to be able to be the same dragon sprite.

 

I've consulted Al_Nafuur after studying his 1942 source code to figure out how to demonstrate his technique.  I barely understand how it works.  Also, my coding style is whack.

 

Hopefully better programmers can use this is to make better examples

 

 

sharedsprite.bas

[+Gemintronic]

Two more things I've discovered since the first post.  These are just findings as I find them - not definitive in any way.  Certainly not disparaging bB.  This stuff is barely using bB as intended.

 

I found subsequent PAD_BB_SPRITE_DATA macros need to be wrapped in asm .. end statements unlike the first such data statement right after the actual macro.

   asm
   MAC PAD_BB_SPRITE_DATA
.SPRITE_HEIGHT  SET {1}
      if    (<*) > (<(*+.SPRITE_HEIGHT))
      repeat    ($100-<*)
      .byte    0
      repend
      endif
      if (<*) < 90
       repeat (90-<*)
       .byte 0
       repend
       endif
   ENDM

   PAD_BB_SPRITE_DATA 12
end

 rem //** Sprite data as normal data statement.  Note extra row of zeros at the beggining **//
 rem //** which tells the kernel to stop drawing player0 sprite **//

 data _Sprite_Draggin
 %00000000
 %01111100
 %10111111
 %00110001
 %01100001
 %00111110
 %01100000
 %01111100
 %11100000
 %11010101
 %11111111
 %01011010
 %01101100
end

 asm
   PAD_BB_SPRITE_DATA 12
end

 data _Sprite_Chalice
 %00000000
 %01111100
 %10111111
 %00110001
 %01100001
 %00111110
 %01100000
 %01111100
 %11100000
 %11010101
 %11111111
 %01011010
 %01101100
end

 

Second, I found that you can't do:

 player0pointerlo = <_Sprite_Draggin

 

You MUST use a constant for the magic to work:

 const _Player0_Draggin_low = <_Sprite_Draggin

 player0pointerlo = _Player0_Draggin_low

 

I was worried we'd run out of constants but R.T.s reference says the limit went from 50 to 500.

 

[+Gemintronic]

I discovered that manipulating playerXpointerlo works best by NOT using constants and instead storing the new value in a variable THEN feeding that to playerXpointerlo.

 

With this code I am trying to save space by having a single sprite data section with both up and down tips of an arrow.  To get an up arrow or down arrow we just shift the pointerhi/pointerlo references up or down to avoid the unwanted arrow tip.  For the down arrow it's easy: just shorten the playerXheight until the up arrow tip is gone.  For the up arrow we must also shift the window into the sprites data to avoid the down arrow tip.

 

For some reason this doesn't work:

 player0pointerlo = _Pxlo_Updown + 5

 

But, this does:

 temp5 = player0pointerlo
 player0pointerlo = temp5 + 5    

 

As a side note the arrow shaft has a blank space between arrow tips because using player0 sprite data this way needs a blank row to tell the kernel when to stop drawing the sprite.

 

 const _Pxhi_Updown     = >_Sprite_Updown    
 const _Pxlo_Updown     = <_Sprite_Updown    
 const _Pxheight_Updown     = 14

 rem Arrow Down
 player0pointerlo = _Pxlo_Updown
 player0pointerhi = _Pxhi_Updown
 player0height = _Pxheight_Updown - 5

 rem Arrow Up
 player0pointerlo = _Pxlo_Updown    
 player0pointerhi = _Pxhi_Updown
 temp5 = player0pointerlo
 player0pointerlo = temp5 + 5     
 player0height = _Pxheight_Updown - 5

 asm
   PAD_BB_SPRITE_DATA 12
end

 data _Sprite_Updown
 %00000000
 %00010000
 %00111000
 %01111100
 %11111110
 %00000000
 %00111000
 %00111000
 %00000000
 %11111110
 %01111100
 %00111000
 %00010000
end

 

[+Al_Nafuur]

I am manipulating playerXpointerlo and the playerXheight in 1942 to scroll in the enemy planes from the bottom. 

 

   if NewSpriteY[temp1] > 1 && NewSpriteY[temp1] <= playerfullheight[temp1] then playerpointerlo[temp1] = playerpointerlo[temp1] - _Plane_Y_Speed : spriteheight[temp1] = NewSpriteY[temp1]

 

[+Gemintronic]

4 minutes ago, Al_Nafuur said:

I am manipulating playerXpointerlo and the playerXheight in 1942 to scroll in the enemy planes from the bottom. 

 

   if NewSpriteY[temp1] > 1 && NewSpriteY[temp1] <= playerfullheight[temp1] then playerpointerlo[temp1] = playerpointerlo[temp1] - _Plane_Y_Speed : spriteheight[temp1] = NewSpriteY[temp1]

 

 

That gives me hope then!  I'll keep experimenting until it works as you use it. 

[KevKelley]

@Gemintronic I had been following the progress on this and trying to think of how I could use something like this and I had a thought. 

 

Do you think something like this could be applicable if I had something like 50 sprite data and that the multiple sprites would scroll from side to side and as each of the multisprites scrolls off the screen the next sprite is then randomly generated to use one of the sprites?

 

The game idea is simple but using this would greatly save space if it were to work the way I think it would. 

 

Looking at the posted code I am a little lost but I was thinking of digging into these examples some more.

Edited January 20, 2022 by KevKelley

[+Gemintronic]

@KevKelly  Yeah.  That's the awesome thing about this technique is that you can swap sprites without worrying if that particular player object has its own personal copy of the sprite data.

 

I had an idea for a "scrolling" pinball game but seems like (to me) there's no sprite clipping in the multi sprite bB kernel.  So, at the sides the whole sprite blorks of out existence.  Just one of those things.

[KevKelley]

57 minutes ago, Gemintronic said:

@KevKelly  Yeah.  That's the awesome thing about this technique is that you can swap sprites without worrying if that particular player object has its own personal copy of the sprite data.

 

I had an idea for a "scrolling" pinball game but seems like (to me) there's no sprite clipping in the multi sprite bB kernel.  So, at the sides the whole sprite blorks of out existence.  Just one of those things.

One of my grocery themed games that I had been toying with for years was Point of Sale. Just a laser checkout and things going by while you time it to zap them. But seeing your updates on this made me revisit and think it would be cool if I make this one simple game but just filling a bank with data so that combined with reflecting the sprites and maybe making double or quad sized sprites could make for a lot of variation. But if they share the data I could make even more unique sprites.

 

[KevKelley]

I've been playing around more with multisprites and Superchip. So this might be perfect for a side project.