Is it possible to share sprite color data?

[freshbrood]

 

 

Using only the standard kernel with playercolors,

 

I tried creating

 

 

data _Colors 1,2,3,4,5,6,7,8

end

 

and then plugging

 

player0colors: _Colors_length

end

 

and it compiles but doesn't read it. Is there a similar way to share multiline color data for both sprites?
 

[+Random Terrain]

Most of the DPC+ sprites can share color data:

 

https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#dpc_sprite_colors

[freshbrood]

I'm aware DPC+ can do it, thank you. But is there any way to do so in the standard kernel? Even if a bit more complicated. I'm trying to save memory and cycles.
 

[+Random Terrain]

I don't see anything on the bB page about it, so probably not.

[bogax]

 

This appears to work

but if I put the playfield declaration inline
instead of in the init_PF subroutine bB complains

 

missing "end" keyword at end of playfield declaration

 

 

it compiles and it looks right but I didnt go any farther than that

  set kernel_options player1colors playercolors pfcolors

  const Px_color_data_lo = <Pxc_data
  const Px_color_data_hi = >Pxc_data


  gosub init_PF

  player0:
  %11111111
  %01111110
  %00111100
  %00011000
  %00011000
  %00111100
  %01111110
  %11111111
end


  player1:
  %00011000
  %00111100
  %01111110
  %11111111
  %11111111
  %01111110
  %00111100
  %00011000
end

  player0color    = Px_color_data_lo
  player0color[1] = Px_color_data_hi

  player1color    = Px_color_data_lo
  player1color[1] = Px_color_data_hi

  player0x = 80 : player1x = 104
  player0y = 35 : player1y = 35

   COLUBK = 0

mainloop

   COLUPF = $94

  drawscreen

  goto mainloop


  data Pxc_data
  $02, $0A, $12, $1A, $22, $2A, $32, $3A
end 


init_PF

   playfield:
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   X..............................X
   X..............................X
   X..............................X
   X..............................X
   X..............................X
   X..............................X
   X..............................X
   X..............................X
   X..............................X
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
end

   pfcolors:
   $94
   $96
   $98
   $9A
   $9C
   $9E
   $A8
   $A6
   $A4
   $A2
   $A0
end

 return

share_sprite_colors_02.bas share_sprite_colors_02.bas.bin

Edited January 1, 2021 by bogax

[freshbrood]

Wow thanks bogax I will try this! I haven't even seen some of these commands in batari.
 

[+Random Terrain]

6 minutes ago, freshbrood said:

Wow thanks bogax I will try this! I haven't even seen some of these commands in batari.

 

When you get a chance, you might want to compare it with using normal color data and see which uses more ROM space or more cycles or both.

 

https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#memory_compilation_completed

[bogax]

The way it's done there it costs 4 bytes and 8 cycles (or something like that) for the indexing

bB reports the same ROM remaining so I assume it gets lost in the padding for the tables

This should be the same as normal code I think and so save the full color table, in this case, 8 bytes instead of four.  Same cycles
It's just a little more convoluted

  set kernel_options player1colors playercolors pfcolors

  const Px_color_data_lo = <Pxc_data
  const Px_color_data_hi = >Pxc_data

  dim   P0_c_pointer_lo  = player0color
  dim   P0_c_pointer_hi  = player0color + 1
  dim   P1_c_pointer_lo  = player1color
  dim   P1_c_pointer_hi  = player1color + 1

  gosub init_PF

  player0:
  %11111111
  %01111110
  %00111100
  %00011000
  %00011000
  %00111100
  %01111110
  %11111111
end


  player1:
  %00011000
  %00111100
  %01111110
  %11111111
  %11111111
  %01111110
  %00111100
  %00011000
end

  P0_c_pointer_lo = Px_color_data_lo
  P0_c_pointer_hi = Px_color_data_hi

  P1_c_pointer_lo = Px_color_data_lo
  P1_c_pointer_hi = Px_color_data_hi

  player0x = 80 : player1x = 104
  player0y = 35 : player1y = 35

   COLUBK = 0

mainloop

   COLUPF = $94

  drawscreen

  goto mainloop


  data Pxc_data
  $02, $0A, $12, $1A, $22, $2A, $32, $3A
end 


init_PF

   playfield:
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   X..............................X
   X..............................X
   X..............................X
   X..............................X
   X..............................X
   X..............................X
   X..............................X
   X..............................X
   X..............................X
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
end

   pfcolors:
   $94
   $96
   $98
   $9A
   $9C
   $9E
   $A8
   $A6
   $A4
   $A2
   $A0
end

 return

Edited January 2, 2021 by bogax

[bogax]

Hmm

Should change

  P0_c_pointer_lo = Px_color_data_lo
  P0_c_pointer_hi = Px_color_data_hi

  P1_c_pointer_lo = Px_color_data_lo
  P1_c_pointer_hi = Px_color_data_hi

to

  P0_c_pointer_lo = Px_color_data_lo : P1_c_pointer_lo = Px_color_data_lo
  P0_c_pointer_hi = Px_color_data_hi : P1_c_pointer_hi = Px_color_data_hi

That should save 4 bytes and 4 cycles

[+Random Terrain]

I'm sure that somebody will ask in the future if your code could be adapted so that instead of both sprites sharing color data, if the colors of both sprites separately could be changed using variables (unless that has already been done).

[bogax]

I forgot to mention

presumably the color table needs to be wholey contained within a page and not straddle a page boundary

if it does it'll probably mess up the kernel timing

so you may need to add you own padding or page align the table or just move it

Edited January 3, 2021 by bogax

[freshbrood]

So I did try this and it compiles but the colors are strange and scrambled. Not at all what is in the data table and there is no discernable pattern to what causes them. I'm guessing as you said it has something to do with timing but I have no clue to know if I am straddling a page boundary in bbasic.

[bogax]

show your code

[freshbrood]

2 hours ago, bogax said:

show your code

  set romsize 32k : set kernel_options player1colors playercolors pfcolors : scorecolor=80

  const _c_frame10lo=#<frame10 : const _c_frame10hi=#>frame10 : const Px_color_data_lo = <Pxc_data : const Px_color_data_hi = >Pxc_data
  rem dim   P0_c_pointer_lo  = player0color
  rem dim   P0_c_pointer_hi  = player0color + 1
  rem dim   P1_c_pointer_lo  = player1color
  rem dim   P1_c_pointer_hi  = player1color + 1
  data Pxc_data
  $0A, $0A, $0A, $FE, $FE, $FE, $FE, $FE, $00, $00, $00, $00, $00, $46, $FE, $FE, $FE, $FE, $FE, $FE, $FE, $FE, $00, $F2
end

   set smartbranching on

  playfield:
 .XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.
 .XXX........................XXX.
 .XXX........................XXX.
 .XXX........................XXX.
 .XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.
 .XXX........................XXX.
 .XXX........................XXX.
 .XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.
 .XXX........................XXX.
 .XXX........................XXX.
 .XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.
end

__Main
  drawscreen
    goto __P0 bank2

    bank 2
__P0


   player0x=50 : player0y=50
   player0color=player0color+1 :  player0pointerlo=_c_frame10lo : player0pointerhi=_c_frame10hi : player0height=22



  player0color = Px_color_data_lo : player0color[1] = Px_color_data_hi



  goto __P11 bank3
   bank 3
__P11

   goto __Fore bank4
   bank 4
__Fore

   goto __Start bank5
    bank 5
__Start

  goto __Main bank1

   bank 6
   bank 7
   bank 8
   data frame10
   %11000011
   %11000110
   %00000110
   %11000000
   %11000010
   %01100011
   %01100011
   %00110011
   %00110111
   %00111011
   %00111010
   %00111010
   %00011101
   %00000011
   %00011100
   %00101110
   %01011111
   %11111011
   %11110011
   %10011100
   %01001110
   %01101110
   %00001110
end

 

[bogax]

the color table has to be in the graphics bank (the last bank I think)

bank 8 in this case

 

same as the other sprite data

Edited January 9, 2021 by bogax

[bogax]

See if this is something like what you want

 

I had to add some padding (the zpad table) to get the Pxc data into the next page

 

Your code as copied and pasted was sort of munged
Maybe the forum code is corrupting it
I only fixed it enough so it would compile for me

 

I don't know what's going on with the playfield declaration
bB still complains about a missing end statement
so I just loaded it from a table

 

I added the noinline data optimization
 

FBs_share_01.bas FBs_share_01.bas.bin

Edited January 9, 2021 by bogax

[freshbrood]

I was just being lazy with the lack of playfield colors but it's cool to know that works too.

"set optimization inlinerand" won't compile for me. There's a ton of other code I've plugged into those banks. Also is using the Temp1 variable necessary? I was really hoping to use every spare variable I could squeeze.

 

What practical application is there for creating a data table for playfield colors? Sharing sprite color data makes sense to me since 2 sprites can use one color table, but there's only one playfield at a time. I'm not using scrolling.

 

Edited January 10, 2021 by freshbrood

[bogax]

You could put rand into a bB function either as bB code or as a bit of asm

 

You don't absolutely need a temp variable to copy data from a data statement to the playfield
But you only need it long enough for the actual copying

 

Not a good idea to expect temp variables to be persistent
Drawscreen and some of the built in functions use them
 

[freshbrood]

So it does save a ton of memory, nearly 600kb! compared to how I was doing it before, with no noticable cycle increase (It didn't roll or count over 262 more than before), but it still doesn't do exactly what I wanted it to.

 

 

 

In my more bloated code, I had a player0height=20 and about 200 lines of color in player0color: and I would simply do a player0color = player0color + 20 to shift the color bar up by 20 or more. It worked without issue, execpt I had to redraw the same colors twice for p1. Using the data table method of yours, the colors completely mess up if I shift the colors up more than 45. I'm not sure if you're familiar with the Ninja Kombat game I'm working on, but the code I have so far is basically if p0 = 1 through 7 then it goes to either __Label1p0color player0color: through __Label7p0color player0color:...

 

 

The issue is for p1 using the exact same characters, I have to duplicate all the player1color: lines, and I was hoping I could just create them once each. But using the const method you showed me seems to only lock down one set of shared colors and I can't cycle through other sets. I share one set of sprites but show 2 different frames simultaneously. I'd like something similar with the colors. If one guy is in a purple outfit I want the other guy to be able to be in a yellow outfit or if he chooses, the same purple outfit but pulling from the same purple color table instead of having to draw a duplicate set of colors for him. Is that possible?
 

 

 
 

[bogax]

Show your code

 

 

My first guess would be that your color table is straddling a page bounary
presumably at 45 bytes in

 

So if that's the case

 

The pointers are 16 bits so you need 16 bit math for the carry to the next page

The individual player color frames need to be page boundary aligned
That is to say each color frame must be wholey contained in a page 
The table over all does not
The boundary from this page to the next page must align with a boundary
between color frames

 

So if the color frames are 0 based your color frames 0,1 are contained in
in the first page but color frame 2 straddles the page boundary

 

I think the simplest and probably fastest and least code (in ROM not necessarily the source))
way would be use a look up table and get the assembler to do the 16 bit math at compile time
in the data statements
And add 5 (or remove 15) bytes of padding to the color frames table

 

  data cf_lo
  <Pxc_data, <Pxc_data+20, <Pxc_data+40, <Pxc_data+60, <Pxc_data+80
end

  data cf_hi
  >Pxc_data, >Pxc_data+20, >Pxc_data+40, >Pxc_data+60, >Pxc_data+80
end

 

Then you'd choose your color_frame something like

 

   player0color = cf_lo[cf_no] : player0color[1] = cf_hi[cf_no]

[freshbrood]

Is there a better way to paste code here that doesn't mess up indenting?

 

This seems to work for me, so you get the idea of what I'm trying to do precisicely. "o" and "u" determine which character p0 and p1 are supposed to be respectively. (1 through 8 are standard human chacters, 9 and 10 have different heights so I'll need to add different code to adjust for those.)

 

As you can see, it multiplies o by 24 to land on the correct "standing idle" color. (I add a plus 1 because the colors are 1 line taller for a punching ani later).

 

As you can also see, p0 and p1 both use the same 10 color sets for the characters, so to need 20 sets seems like a waste. I'm not sure how "page boundaries" work and apparently my code keeps going over because my method only seems to work using the preset color bars and not the const examples you've provided. I tried both iterations and they still only work up to the first couple increases then they are completely distorted. I'm not sure the trouble to re-write and integrate it into my code would be worth the space savings at this point, although it's signficant.

 

   set romsize 32k : set kernel_options player1colors playercolors pfcolors : COLUBK = 2
   const _c_frame10lo=#<frame10 : const _c_frame10hi=#>frame10

  player0x = 50 : player0y = 50 : player1x = 70 : player1y = 50

__Main
  goto __P0 bank2

    bank 2
__P0

  player0color:
 10
 10
 10
 254
 254
 254
 254
 254
 0
 0
 0
 0
 0
 70
 254
 254
 254
 254
 254
 254
 254
 254
 0
 242
 56
 56
 56
 56
 56
 56
 14
 10
 14
 14
 14
 14
 14
 0
 254
 14
 14
 56
 14
 254
 254
 254
 12
 12
 10
 10
 10
 8
 14
 14
 14
 14
 14
 14
 14
 14
 14
 0
 0
 14
 14
 14
 14
 14
 0
 0
 0
 0
 14
 14
 14
 14
 0
 0
 0
 0
 0
 0
 0
 0
 0
 0
 0
 254
 254
 254
 254
 254
 254
 254
 254
 0
 0
 0
 0
 0
 30
 30
 30
 0
 0
 0
 0
 0
 0
 30
 0
 30
 30
 30
 30
 30
 0
 30
 0
 0
 0
 0
 0
 0
 156
 156
 156
 0
 0
 0
 0
 0
 0
 156
 0
 156
 156
 156
 156
 156
 0
 156
 0
 0
 14
 14
 14
 14
 14
 46
 194
 194
 194
 194
 194
 194
 0
 0
 46
 46
 46
 194
 196
 46
 46
 46
 196
 30
 0
 0
 0
 0
 202
 202
 202
 0
 0
 0
 0    
 0
 0
 202
 0
 202
 202
 202
 202
 202
 0
 202
 0
 0
 62
 62
 62
 12
 12
 62
 62
 62
 62
 62
 62
 62
 68
 62
 62
 62
 62
 62
 62
 62
 62
 62
 62
 62
 62
 62
 62
 12
 246
 246
 246
 246
 246
 246
 246
 246
 246
 246
 116
 116
 116
 116
 14
 116
 116
 116
 116
 116
 14
 14
 14
 14
 14
end

  player1color:
 10
 10
 10
 254
 254
 254
 254
 254
 0
 0
 0
 0
 0
 70
 254
 254
 254
 254
 254
 254
 254
 254
 0
 242
 56
 56
 56
 56
 56
 56
 14
 10
 14
 14
 14
 14
 14
 0
 254
 14
 14
 56
 14
 254
 254
 254
 12
 12
 10
 10
 10
 8
 14
 14
 14
 14
 14
 14
 14
 14
 14
 0
 0
 14
 14
 14
 14
 14
 0
 0
 0
 0
 14
 14
 14
 14
 0
 0
 0
 0
 0
 0
 0
 0
 0
 0
 0
 254
 254
 254
 254
 254
 254
 254
 254
 0
 0
 0
 0
 0
 30
 30
 30
 0
 0
 0
 0
 0
 0
 30
 0
 30
 30
 30
 30
 30
 0
 30
 0
 0
 0
 0
 0
 0
 156
 156
 156
 0
 0
 0
 0
 0
 0
 156
 0
 156
 156
 156
 156
 156
 0
 156
 0
 0
 14
 14
 14
 14
 14
 46
 194
 194
 194
 194
 194
 194
 0
 0
 46
 46
 46
 194
 196
 46
 46
 46
 196
 30
 0
 0
 0
 0
 202
 202
 202
 0
 0
 0
 0    
 0
 0
 202
 0
 202
 202
 202
 202
 202
 0
 202
 0
 0
 62
 62
 62
 12
 12
 62
 62
 62
 62
 62
 62
 62
 68
 62
 62
 62
 62
 62
 62
 62
 62
 62
 62
 62
 62
 62
 62
 12
 246
 246
 246
 246
 246
 246
 246
 246
 246
 246
 116
 116
 116
 116
 14
 116
 116
 116
 116
 116
 14
 14
 14
 14
 14
end

  o = 6
  player0color = player0color + (o*24) - 24 + 1 : player0pointerlo=_c_frame10lo : player0pointerhi=_c_frame10hi : player0height=22

  u = 8
  player1color = player1color + (u*24) - 24 + 1 : player1pointerlo=_c_frame10lo : player1pointerhi=_c_frame10hi : player1height=22

  drawscreen

  goto __Three bank3

  bank 3
__Three

  goto __Four bank4
 
  bank 4
__Four

  goto __Start bank5

    bank 5
__Start

  goto __Main bank1

   bank 6
   bank 7
   bank 8
   data frame10 ; (STAND)
   %11000011
   %11000110
   %00000110
   %11000000
   %11000010
   %01100011
   %01100011
   %00110011
   %00110111
   %00111011
   %00111010
   %00111010
   %00011101
   %00000011
   %00011100
   %00101110
   %01011111
   %11111011
   %11110011
   %10011100
   %01001110
   %01101110
   %00001110
end

 

[freshbrood]

I also tried your suggestion above.
 

   player0color = cf_lo[cf_no] : player0color[1] = cf_hi[cf_no]

I wasn't sure if I was doing it right, every number I plugged in gave me corrupted colors. I also have absolutely no clue to know how close  I am going over a page boundary. So far the only way that has worked for me is to use two separate colors bars for each player. I know theoretically it shouldn't be that hard to share the same color bar but I can't figure it out. I'm not a coder and all I know is what I've learned using basic.
 

[+Random Terrain]

16 minutes ago, freshbrood said:

Is there a better way to paste code here that doesn't mess up indenting?

 

It's pretty much the same as before the forum upgrade. Click on the icon that looks like this:

 

</>

 

When you move your mouse pointer over the icons, a box pops up telling you what each one means.

 

Example:

 

[freshbrood]

30 minutes ago, Random Terrain said:

 

It's pretty much the same as before the forum upgrade. Click on the icon that looks like this:

 

</>

 

When you move your mouse pointer over the icons, a box pops up telling you what each one means.

 

Example:

 

Where am I supposed to see that icon? in the bbasic or text editor? I just copied and pasted directly from bbasic and I'm on a reduced data browser that may not show up all the regular javascript buttons.

 

Edited January 17, 2021 by freshbrood

[freshbrood]