bogax

If you're going to do it that way you'll have to use 16 bit math something like const P0cphi = player0color + 1 ; name the hi byte of the player0color pointer ; so you can use it to define a bB 8.8 player0color pointer 16 bit variable dim P0c_pointer = P0cptr.player0color ; so you can use it to do 16 bit math in bB P0c_pointer = P0c_pointer + 0.094 ; then you'd do your math something like this (24/256 = ~.094)

I'm not really sure I understand what you're doing I'd just asign a room number so that it can be used as an index then use tables untested proom = rand & 15 ; pit room droom = rand & 15 ; dragon room hrow = hroom / 4 ; hero row hcol = hroom & 3 ; hero column prow = proom / 4 pcol = proom & 3 ; if same row and if adjacent columns if hrow = prow && af[hcol] & rc[pcol] then COLUBK = $A0 : goto BK_color_done ; if same column and if adjacent rows if hcol = pcol && af[hrow] & rc[prow] then COLUBK = $A0 : goto BK_color_done drow = droom / 4 dcol = droom & 3 ; etc if hrow = drow && af[hcol] & rc[dcol] then COLUBK = $34 : goto BK_color_done if hcol = dcol && af[hrow] & rc[drow] then COLUBK = $34 BK_color_done ; row or column position flag data rc %00000001, %00000010, %00000100, %00001000 end ; adjacent position flags data af %00000010, %00000101, %00001010, %00000100 end

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]

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

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

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

show your code

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

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

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

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

line 283 of the .bas file you posted sets f{1} = 0 so presumably you want a different bit for the fire flag I've been molesting your code so I'm not sure its right but this is what I did not in order the call to park goes any where the missile is parked not just this excerpt edit: the way this code is set up, you can only fire if you're moving and it fires when you press the fire button not when its released def park_m0 = gosub pkm0 def park_m1 = gosub pkm1 pkm0 m0d = 0 : missile0x = 200 : missile0y = 200 : return pkm1 m1d = 0 : missile1x = 200 : missile1y = 200 : return ;BALL if collision(missile0,player1) then g{0} = 1 : park_m0 if collision(missile1,player0) then g{1} = 1 : park_m1 ;P0 SHOOTING if collision(ball,player0) then skip_m0_direction pj0f = j0f if joy0fire then j0f{2} = 1 else j0f{2} = 0 if pj0f{2} then skip_m0_direction if !j0f{2} then skip_m0_direction m0d = (SWCHA ^ %11111111) / 16 if m0d then missile0x = player0x + 3 : missile0y = player0y - 4 skip_m0_direction if !m0d then skip_move_m0 missile0x = missile0x + mvx[m] missile0y = missile0y + mvy[m] skip_move_m0 if collision(missile0,playfield) then park_m0 ;P1 SHOOTING if collision(ball,player1) then goto skip_m1_direction pj1f = j1f if joy1fire then j1f{3} = 1 else j1f{3} = 0 if pj1f{3} then skip_m1_direction if !j1f{3} then skip_m1_direction m1d = (SWCHA ^ %11111111) & %00001111 if m1d then missile1x = player1x + 3 : missile1y = player1y - 4 skip_m1_direction if !m1d then skip_move_m1 missile1x = missile1x + mvx[n] missile1y = missile1y + mvy[n] skip_move_m1 if collision(missile1,playfield) then park_m1 SKIP_SHOOTING_1

I'm not sure what to make of it I suspect it may be a keyboard-instead-of-joystick problem I noticed a couple other things You're doing something with bit 1 of f so you should use a different bit for the fire button flag If you're going to use a single bit you have to use a single bit in the if statments too You should move the initialization of the missile position to where missile direction gets set

yes except you need to mask out the joy0 bits of SWCHA m1d= SWCHA ^ %11111111 & %00001111

oops a flag to remember the state of joy0fire the code is written as if its a full variable, but it only needs a single bit

this is something like what I had in mind (untested) dim pj0f = temp1 dim m0d = m ; missile 0 direction pj0f = j0f ; remember if joy0fire was pressed before if joy0fire then j0f = 1 else j0f = 0 ; remember if joy0fire is pressed now if !pj0f then skip_m0_direction ; skip setting the m0 direction if joy0fire wasn't pressed before if j0f then skip_m0_direction ; joy0fire was pressed before skip setting the m0 direction if it's still pressed ; set missile 0 direction m0d = (SWCHA ^ %11111111) / 16 ; joy0 bits are rlduxxxx of SWCHA ; if a direction is active the bit is 0 eg right-up is 0110xxxx ; ^ with 1 will flip a 1 bit to 0 and a 0 bit to 1 so right-up will be 1001xxxx ; then divide by 16 to get 0000rldu so right up will be 00001001 skip_m0_direction if !m0d then skip_move_m0 ; if m0d is 0 then the missile is parked off screen don't move it ; move missile 0 missile0x = missile0x + m0x[m0d] missile0y = missile0y + m0y[m0d] skip_move_m0 ; 0 1 2 3 4 5 6 7 8 9 10 ; u d du l lu ld ldu r ru rd data m0x 0, 0, 0, 0, 0, -1, -1, 0, 1, 1, 1 end data m0y 0, -1, 1, 0, 0, -1, 1, 0, 0, -1, 1 end the value in the table is the speed

My suggestion is to read Advanced Joystick Reading with SWCHA then abandon that mess of if-then spaghetti and do your missile move with look up tables (instead of on gosub/goto as in the examples)

changing banks takes time if you were doing alot of that it could cause problems

yes the rr##'s are the individual rotation routines they just rotate three sprites (you could think of a swap as a rotation of two sprites) and the sp##'s are the sprites they're sort of place holders, exactly what they'd end up being would depend on your code they could be plain bB variables, or you could pack them as nibbles. or you could make some of them nibbles and use the sprite x,y for some (assuming the x,y positions would be (different, unique) constants. it would be sort of inside out, the positions would get shuffled among the sprites instead of the sprites shuffled amongst the positions)

I'm thinking something like this this rotates through three for each bit of rand you could probably find better choices for the three I tried swapping two but it didn't look very random (and neither does this really but it looks better than swapping) I didn't try to analyze it, I just picked some random looking stuff that is a notoriously bad idea the details would depend on exactly what you're doing there's like 500 million permutations of twelve, rand is only 8 bits and rand16 has a cycle length of 65535 dim rand16 = z rnd = rand for i = 0 to 14 step 2 p = (rnd & 1) | i on p goto rr_0 rr_1 rr_2 rr_3 rr_4 rr_5 rr_6 rr_7 rr_8 rr_9 rr10 rr11 rr12 rr13 rr14 rr15 nxt rnd = rnd/2 next rr_0 temp1 = sp0 : sp0 = sp3 : sp3 = sp10 : sp10 = temp1 : goto nxt rr_1 temp1 = sp0 : sp0 = sp6 : sp6 = sp11 : sp11 = temp1 : goto nxt rr_2 temp1 = sp1 : sp1 = sp9 : sp9 = sp10 : sp10 = temp1 : goto nxt rr_3 temp1 = sp1 : sp1 = sp4 : sp4 = sp11 : sp11 = temp1 : goto nxt rr_4 temp1 = sp2 : sp2 = sp7 : sp7 = sp10 : sp10 = temp1 : goto nxt rr_5 temp1 = sp2 : sp2 = sp10 : sp10 = sp11 : sp11 = temp1 : goto nxt rr_6 temp1 = sp3 : sp3 = sp5 : sp5 = sp10 : sp10 = temp1 : goto nxt rr_7 temp1 = sp3 : sp3 = sp6 : sp6 = sp11 : sp11 = temp1 : goto nxt rr_8 temp1 = sp4 : sp4 = sp10 : sp10 = sp10 : sp10 = temp1 : goto nxt rr_9 temp1 = sp4 : sp4 = sp6 : sp6 = sp11 : sp11 = temp1 : goto nxt rr10 temp1 = sp5 : sp5 = sp8 : sp8 = sp10 : sp10 = temp1 : goto nxt rr11 temp1 = sp5 : sp5 = sp9 : sp9 = sp11 : sp11 = temp1 : goto nxt rr12 temp1 = sp6 : sp6 = sp8 : sp8 = sp10 : sp10 = temp1 : goto nxt rr13 temp1 = sp6 : sp6 = sp9 : sp9 = sp11 : sp11 = temp1 : goto nxt rr14 temp1 = sp7 : sp7 = sp8 : sp8 = sp10 : sp10 = temp1 : goto nxt rr15 temp1 = sp7 : sp7 = sp10 : sp10 = sp11 : sp11 = temp1 : goto nxt

I found this PCG: A Family of Simple Fast Space-Efficient Statistically Good Algorithms for Random Number Generation (from this page) interesting bB rand16 is kinda like that (with an LFSR instead of LCG)

How would you get 12 sprites?

Here's some scatters I did of some LFSRs combined with a simple LCG x'=x*17+103

so you want a shuffle? that's a somewhat different problem (Wikipedia)

here (pastebin) is some javascript to do scatterplots of the bB rand LFSR(s) did this a while ago and just came back across it so you may have seen it looks like there's points clustered at the edges. that makes me wonder if it works the way it should I don't specifically recall (and I haven't looked yet) but I assume it plots this value against the previous value rand 16 looks a lot better