freshbrood Posted December 31, 2020 Share Posted December 31, 2020 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? Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted December 31, 2020 Share Posted December 31, 2020 Most of the DPC+ sprites can share color data: https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#dpc_sprite_colors 1 Quote Link to comment Share on other sites More sharing options...
freshbrood Posted January 1, 2021 Author Share Posted January 1, 2021 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. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted January 1, 2021 Share Posted January 1, 2021 I don't see anything on the bB page about it, so probably not. Quote Link to comment Share on other sites More sharing options...
bogax Posted January 1, 2021 Share Posted January 1, 2021 (edited) 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 2 Quote Link to comment Share on other sites More sharing options...
freshbrood Posted January 2, 2021 Author Share Posted January 2, 2021 Wow thanks bogax I will try this! I haven't even seen some of these commands in batari. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted January 2, 2021 Share Posted January 2, 2021 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 1 Quote Link to comment Share on other sites More sharing options...
bogax Posted January 2, 2021 Share Posted January 2, 2021 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
bogax Posted January 2, 2021 Share Posted January 2, 2021 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 2 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted January 2, 2021 Share Posted January 2, 2021 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). 1 Quote Link to comment Share on other sites More sharing options...
bogax Posted January 3, 2021 Share Posted January 3, 2021 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
freshbrood Posted January 9, 2021 Author Share Posted January 9, 2021 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. Quote Link to comment Share on other sites More sharing options...
bogax Posted January 9, 2021 Share Posted January 9, 2021 show your code Quote Link to comment Share on other sites More sharing options...
freshbrood Posted January 9, 2021 Author Share Posted January 9, 2021 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 Quote Link to comment Share on other sites More sharing options...
bogax Posted January 9, 2021 Share Posted January 9, 2021 (edited) 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 Quote Link to comment Share on other sites More sharing options...
bogax Posted January 9, 2021 Share Posted January 9, 2021 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
freshbrood Posted January 10, 2021 Author Share Posted January 10, 2021 (edited) 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 Quote Link to comment Share on other sites More sharing options...
bogax Posted January 10, 2021 Share Posted January 10, 2021 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 1 Quote Link to comment Share on other sites More sharing options...
freshbrood Posted January 14, 2021 Author Share Posted January 14, 2021 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? Quote Link to comment Share on other sites More sharing options...
bogax Posted January 15, 2021 Share Posted January 15, 2021 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] 1 Quote Link to comment Share on other sites More sharing options...
freshbrood Posted January 17, 2021 Author Share Posted January 17, 2021 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 Quote Link to comment Share on other sites More sharing options...
freshbrood Posted January 17, 2021 Author Share Posted January 17, 2021 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. Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted January 17, 2021 Share Posted January 17, 2021 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: Quote Link to comment Share on other sites More sharing options...
freshbrood Posted January 17, 2021 Author Share Posted January 17, 2021 (edited) 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 Quote Link to comment Share on other sites More sharing options...
freshbrood Posted January 17, 2021 Author Share Posted January 17, 2021 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.