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

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

rand is just a counter that counts in a funny sequence if you start from the same spot it will count through the same sequence

heh I just realized you're telling it to turn on the 12th line in phline (you want row 10)

1line13.bas has 10 lines in the playfield definition I don't know why pfhline isn't working, but maybe that has something to do with it

this is untested assuming a set of flags in ram consisting of 18 consecutive bytes (for a 16 x 9 matrix) here starting with h also assumes the puzzle is in the middle two byte columns ie the flags are for pfpixels 8..23 x 1..9 with pfpixel 7, 0 being puzzle 0, 0 visited(col, row) will return true (non zero) for a set pixel flag (kinda like pfread) and setvf(col, row) should set a flag the parameters are column x row in pfpixels and assume that the upper right corner of the puzzle matrix is at 1, 1 (at least that's what they're meant to do, like I said, untested) dim vfx = temp1 dim vfy = temp2 dim vfptr = temp3 const vbase = h ; z - 18 const midsb = setbyte + 8 function visited() vfx = vfx - 1 vfptr = (vfy - 1) * 2 vfptr = vfx / 8 | vfptr vfptr = midsb[vfx] & vbase[vfptr] return function setvf() vfx = vfx - 1 vfptr = (vfy - 1) * 2 vfptr = vfx / 8 | vfptr vbase[vfptr] = midsb[vfx] | vbase[vfptr] return

I think this is what you want you need to increment by 1 and write another byte then increment by 3 I put some junk on the right of the first one to show where it's going asm ldx level ; ballx ldy x11,x ; level x 11 look up ldx #$0A lda #>col0_dat sta temp4 lda #<col0_dat sta temp3 loop_col0 lda (temp3),y sta var0,x iny inx lda (temp3),y sta var0,x iny inx inx inx cpx #$26 bne loop_col0 end return otherbank data x11 0, 14, 28, 42, 56, 70 end data col0_dat %01111110, %00000000 %01000010, %00000000 %01110110, %11100001 %01101110, %10000001 %01000010, %10000001 %01111110, %11100001 %00000000, %00000000 %00100100, %00000000 %01100110, %00000000 %00111100, %00000000 %00100100, %00000000 %00011000, %00000000 %01100110, %00000000 %00000000, %00000000 %00111100, %00000000 %01011010, %00000000 %01111110, %00000000 %01011010, %00000000 %01100110, %00000000 %00111100, %00000000 %00000000, %00000000 %01000010, %00000000 %01111110, %00000000 %01001010, %00000000 %01111110, %00000000 %01010010, %00000000 %01111110, %00000000 %00000000, %00000000 %01000010, %00000000 %00110010, %00000000 %01011010, %00000000 %01011010, %00000000 %01001100, %00000000 %01000010, %00000000 %00000000, %00000000 %01111111, %00000111 %01111111, %00000111 %01111111, %00000111 %01111111, %00000111 %01111111, %00000111 %01111111, %00000111 %00000000, %00000000 end

not sure what you mean by overlay you could just swap the pixel visited flags with the play field and/or flicker them

well there's the aux1..aux6 variables which are part of the stack you can probably use (some of) them if you don't go to deep on the stack (I think the score uses some of the aux variables) there's var44..var47 don't know but they may be available if you're only using one sprite there maybe some associated space there you could use my point was, doesn't seem like you would need that much

hmm you need a byte for game state you use 2 bytes for the audio you need 2 bytes for cursor position you need a byte for the level (depending on how many levels, could be part of game state?) (did I miss anything?) that would leave you 20 bytes (and there might be a few others around, stack space or something) assuming you keep 11 rows with a free row and column for 16 X 9 pixels you'd need 18 bytes for pixel visited flags it looks like the cursor moves in pf pixels I think I'd keep the movement/position in pf pixels and translate to sprite coordinates just for display if the puzzle matrix was 16 x 9 and you have free space bordering you need 18 x 11 for position or 5 and 4 bits so you'd have 3 and 4 bits you could use for eg game state you could put the puzzle matrix in the middle of the screen so you'd be dealing with whole bytes

worse than that I think is it's harder to read and keep track of

OK one more y is now the page and temp2 the level index that saves a couple of bytes and a couple cycles in the loop back to incrementing x branches into the loop to avoid an unneeded increment of the pointers load_new_level3 const number_of_levels = 4 ; initialize the playfield asm ldx #$2B loop_pf lda pf_dat,x ; col0 will be over written but it's probably not worth trying to avoid sta var0,x dex bpl loop_pf ; initialize pointers ldy #<col_dat lda level sta temp1 lda #>col_dat sta temp2 ldx #var8 bne enter_col0_loop loop_col ; increment the data pointer tya clc adc #number_of_levels tay bcc increment_playfield_pointer inc temp2 increment_playfield_pointer inx inx inx inx enter_col0_loop ; move the column 0 data lda (temp1),y sta $00,x cpx #var28 bne loop_col end return otherbank data pf_dat %11111111, %11111111, %11111111, %11111111 %00000000, %00000001, %00000000, %00000000 %00000000, %00001001, %01000101, %01110100 %00000000, %00001101, %01000101, %00010101 %00000000, %00001001, %01000101, %00010110 %00000000, %11001001, %01000101, %01110100 %00000000, %00001001, %01000101, %00010100 %00000000, %00011101, %01110101, %01110100 %00000000, %00000001, %00000000, %00000000 %11111111, %11111111, %11111111, %11111111 %11111111, %11111111, %11111111, %11111111 end data col_dat %01111110, %00100100, %00111100, %01000010 %01000010, %01100110, %01011010, %01111110 %01110110, %00111100, %01111110, %01001010 %01101110, %00100100, %01011010, %01111110 %01000010, %00011000, %01100110, %01010010 %01111110, %01100110, %00111100, %01111110 end