bogax

You're using the standard kernel with no funny stuff right? And your playfield is very simple I think you could shave a few more bytes if you replace your playfield statement with this. There's only one value in your playfield (here called pfedge) other than zero this just pokes it directly in a loop with out having to duplicate it in the code to fill the playfield. Hope I got those locations right (untested) const pfedge = $80 const pfleft = $A4 const pfright = $A7 pfclear for i = 0 to 48 step 4 pfleft[i] = pfedge : pfright[i] = pfedge next anyway, you could try it edit: oops one line short, fixed now I think edit again after reading theloon's post I forgot the pfvariables have names so using them it would be const pfedge = $80 pfclear for i = 0 to 48 step 4 var0[i] = pfedge : var3[i] = pfedge next

Did you remember to reset angle off when you spawn a new ball? You might want to use a different offset if you'vealready bounced Do you really want an out of bounds to go to bad hit?

If you bounce, there's still only one possible block to collide with the possible target block will be +4 +8 +12 of what it was in terms of block number, but there's still only one possibility for a given angle. Which of those three depends on how the angle changed I think you only change position by +-one max on each pass? So if you collide with a block on it's left edge and it's not destroyed, and you bounce to the right won't you collide again on the next pass because you haven't moved the four (or what ever) positions you need to take you beyond the right edge. Also, if you limted the collisions by angle you wouldn't be able to collide with the same block again.

I think you could shave a few bytes here (untested) rem player movement code rem if joy0right then direction = 1 if joy0left then direction = 0 if !joy0left && !joy0right && direction && velocityx then velocityx=velocityx-0.0030 if !joy0left && !joy0right && !direction && velocityx then velocityx=velocityx+0.0030 rem player movement code rem if joy0right || joy0left then direction = direction ^ 1 : goto skip if !velocityx then goto skip if direction then velocityx=velocityx-0.0030 else velocityx=velocityx+0.0030 skip

Not sure I'm following what you're doing. It looks to me like you do the normal thing, except sometimes you also bounce. There's still only certain possible collisions depending on anglevar they just change if you've bounced. If the block was not destroyed you could collide with it again(?) (assuming you could collide more than once at all)

Why did you go back to doing the collision detection in code? Is it possible you're colliding more than once? Perhaps you should set the position out of bounds for a bounce and see if that helps.

if it's less than 85 add 3 (and) if it's less than 170 add 4 (although, that doesn't sound like what you describe)

temp1 = SWCHA / 4 & $C temp1 = temp1 | last last = temp1 / 4 if ptbl[temp1] & nomove then goto no_move if ptbl[temp1] & left then carpos=carpos-1 else carpos=carpos+1 gamebits{0}=1 const nomove = 1 const right = 0 const left = 2 data ptbl nomove, right, left, nomove left, nomove, nomove, right right, nomove, nomove, left nomove, left, right, nomove end no_move (untested, it compiles. I transposed temp1 and last) edit: goofed the table fixed now I hope

I would have guessed from your previous code that the cooldown conditions should be inequalities? Anyway you could still save a few bytes temp1 = anglevar & 1 temp1 = difficulty * 2 | temp1 if mmove_ball_flags[temp1] & set_bits[cooldown] then player1x = player1x + xmtbl[anglevar] : player1y = player1y + ymtbl[anglevar] rem even bytes are even angles odd bytes odd angles rem difficulty counts by twos rem cooldown is bits data move_ball_flags %11110111, %00000001, %01111111, %11011111, %00000000, %01111111, end (the flags are meant to match your code, not what I thought you wanted)

Since you've set up to address bits and since there's only to two possibilities either adjust player1x, player1y or don't, you could use a table of bit flags to decide. Something like this (I was trying for minimum code, not sure I managed that)(sorry, you'll have to figure out which flags you want set yourself) if anglevar & 1 then goto odd_angle rem temp = 8 forces an add rem first line in the table is odd angles second line is even angles rem + 5 offsets to the second line in the table if difficulty > 2 then temp = 8 else temp = difficulty + 5 goto add data add_flags_tbl %00000000, %00000000, %00000000, %00000000, %00000000 %00000000, %00000000, %00000000, %11111111 end odd_angle if difficulty > 4 then goto skip_add else temp = difficulty add if add_flags_tbl[temp] & setbits[cooldown] then player1x = player1x + xmtbl[anglevar] : player1y = player1y + ymtbl[anglevar] skip_add

I see, so you're not expected to change things mid line, during the visible part?

you'd set them up just like you do now, during horizontal blanking, you just wouldn't waste any code for timing during horizontal blanking

I hesitate to disagree since I haven't done any kernel programing, but I think it would have been better to start the screen immediately you'd have to time the sceen drawing correctly but then you could do setup for the next line during hblank without regard to how much time it took provided it didn't take too long.

somewhat off topic question after WSYNC the processor must run for a precise number of cycles, the horizontal blank time, and then draw the screen? ie it's not the other way around, immediatey draw the screen then do the horizontal blank (which could have been a WSYNC)

I went into the .bin file and for some reason (which I haven't tryed to figure out yet) the jmp .DrawKernel wasn't there (even though it was in .lst file) (only thing I can think is I must have been looking at the wrong file or forgot to recompile or something) At this less sleepy time all seems to be well with the .bin file jsr's and jmp's are there and go where they're meant to (I abandoned the bB label and just used the asm) A quick bit of Googling didn't turn up anything about scope for local labels in DASM but that doesn't seem to be the problem. I haven't tryed your new and improved code yet

That's what I did and according to the .lst file the jmp, jsr got to the right spots

for what it's worth I couldn't get it to work either I inserted the kernel listing at the end of the bB code like so: custom_kernel asm jmp .DrawKernel end asm ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; ASSEMBLY KERNEL ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; . . . end then called the kernel with a gosub custom_kernel just before the flicker code then jumped past it rem ============== rem COLOR FLICKER rem ============== 100 gosub custom_kernel goto 415 I also tried jmp .StartPlayScreen I get rolling lines if I use goto custom_kernel the normal thing for bB is to jsr drawscreen (thats the result of a drawscreen statement) I would think it needs a gosub or else how would it know where to return to in the bB program? If I use gosub custom_kernel I end up back at the title screen immediately I didn't look to see what the jmp REJOIN_BB does yet. Is that vertical syncing? I don't think there's anything on the stack from the bB code except the single return to where the kernel is called.

I was thinking something similar here's a scatter plot previous value v current value for a combined PRNG http://postimage.org/image/xt2hiwf0p/ the LCG is seed * 17 + 103 iirc The bB RNG is a 16 bit LFSR I believe (but not the one used for the picture) in bB it would be something like myrnd = myrnd * 4 + myrnd +103 r = rand ^ myrnd ie it wouldn't cost much and it looks (to me) much more random.

asl adc #$80 rol asl adc #$80 rol

it writes it directly to memory instead of passing the info to the pfpixels routine and having it do it (the screen is at $A4)

105 rem increment flicker flicker = flicker + 1 & 7 rem determines if a color is being used if setbits[flicker] & temp4 then goto 110 goto 105 data screen_add $02, $02, $07, $0F, $17, $1F, $27, $2A, $2A, $29, $25, $1C, $14, $0C, $05, $01 end data block_bit $80, $08, $01, $08, $10, $08, $01, $08, $80, $10, $01, $04, $08, $04, $01, $10 end data setbits $01, $02, $04, $08, $10, $20, $40, $80 end 110 rem cycle through pfpixels, turning them on if they are equal to the color being drawn temp6 = base : temp4 = blkc[flicker] for temp5 = 0 to 15 if a[temp6] = temp4 then temp2 = screen_add[temp5] : $A4[temp2] = $A4[temp2] | block_bit[temp5] temp6 = temp6 + 1 & 15 next rem set playfield to current color COLUPF = temp4

it's like if pulse <> 0 then goto 10 It doesn't change anything about the logic of the program it just means you don't have to do a lot of checking heartcolor and level before you find out pulse <> 0 and they don't matter anyway. It also saves space because you're not duplicating it a bunch of times. And it does save cycles which you (apparently) don't have any to waste. Thats at least partly because you waste them like that.

so what you should do is skip all that except for the 1 in 45 times that you actually need it similarly you don't need to check for level 1 twice here's a trick a^a=0 a^0=a if x=a^b then a^x=b, b^x=a rem hc = blkc[0] ^ blkc[1] const hc = 94 rem special occasion for first level if level = 0 then heartcolor = blkc[0]: goto 10 if pulse then goto 10 rem special occasion for second level if level = 1 then heartcolor = heartcolor ^ hc : goto 10 rem increment the colors if heartcolor = blkc[1] then heartcolor = blkc[2]: goto 10 if heartcolor = blkc[0] then heartcolor = blkc[1]: goto 10 if heartcolor = blkc[2] then heartcolor = blkc[0] 10

how often will pulse = 0 ? level 1 only has two colors you only have to figure out which it is now (once) and get thew other one rem special occasion for first level if level = 0 then heartcolor = blkc[0]: goto 10 rem special occasion for second level if level = 1 && heartcolor = blkc[0] && pulse = 0 then heartcolor = blkc[1]: goto 10 if level = 1 && heartcolor = blkc[1] && pulse = 0 then heartcolor = blkc[0]: goto 10 rem increment the colors if heartcolor = blkc[1] && pulse = 0 then heartcolor = blkc[2]: goto 10 if heartcolor = blkc[0] && pulse = 0 then heartcolor = blkc[1]: goto 10 if heartcolor = blkc[2] && pulse = 0 then heartcolor = blkc[0] 10 other stuff like that

To tell the truth I didn't try to dig into what you were doing I just assumed you'd got it rotated or mirrored or something and looked for a mapping that would work. 0, 0 is in the upper left corner with positive right and down You should learn some binary -1 is 255 (for eight bits) or $FF or %11111111 In decimal, for two digits, it would be 99 (still two decimal digits) Take 5 + 97 (ie 5-3) 5 + 97 = 102 throw away the 100. Same in two's complement except it's base two You're sort of adding with your negative number presubtracted (100 take away three, what's left is the complement in 100) For one thing, not just anybody is going to read the code. Decimal is generally not easier in this context. Ultimately, mainly, because binary is simple to impliment in hardware. You should do whatever works fo you. IMO you should get familiar with binary and hex so that that is what works for you because it's sort of inherent (in this context). It depends. In this case you're using a binary mask. some number hgfedcba and mask 00001111 result 0000dcba I think binary is clearer with the noinlinedata optimization set, it ends up as one big table with bB recognizing two places to index from. The table has the x and y values interleaved since you only need every other value relative to the index. It simplifies (and speeds up) the code some. As for software checks apart from what Omegamatrix mentioned, I thought you'd already decided not to use the hardware collision for some reason and that's why you weren't using it (something you were discussing several posts back).