bogax

and to reuse the (sine) table cos = sin( 90 - angle )

Perhaps it's also worth pointing out that if its a gravity simulation, and therefore parabolic, the tangent may be some simple function of x (part of the calculation is in the gravity simulation already)

oops, yup (fixed)

I think the most usual way to do that is a look up table y / x = tangent then look up the angle with tangent How fine do you need to split the angles?

yes, but that still compiles

Basicaly everything except labels and end statements needs to be indented, you've got four lines that aren't.

I know nothing of DPC+ Are you trying to minimize code size? I just assumed you weren't worried about it for a demo. Theres several places you could squeeze out a few bytes. one bit of code puzzles me. if collision(player0,playfield) then skip_ud if collision(player0,playfield) && player0y=71 then player0y=player0y+1 if collision(player0,playfield) && player0y=111 then player0y=player0y+1 if collision(player0,playfield) && player0y=151 then player0y=player0y+1 if !collision(player0,player1) then skip_ud dontskip p0_y = 0 if joy0up then p0_y = 255 if joy0down then p0_y = 1 player0y = player0y + p0_y skip_ud The first if statement means the next three will never be true. Your playfields are so simple I think you could draw them with lines and save some bytes. It would be a lot slower I'd guess.

If 0, 0 is the upper left hand corner and the x and y velocities are both positive then if you hit on the top you want to reverse the y velocity and not the x velocity and if you hit the side you want to reverse the x velocity and not the y and maybe you want to reverse both if you hit a corner, I don't see how you do that with out knowing where you're coming from. I suppose you might fake it by angle, and assume you'll reverse the greater velocity. edit: you'd still have to have some idea of where you could be comeing from

a little shorter, a little faster, uses one less temp variable. const pptrs_lo = <playerptrs const pptrs_hi = >playerptrs data playerColorslo <milCol, <milCol, <milCol, <drkCol end data playerColorshi >milCol, >milCol, >milCol, >drkCol end temp1 = 0 for temp2 = 20 to 26 step 2 temp3 = enemy0[temp1] DF0LOW = pptrs_lo + temp2 DF0HI = (pptrs_hi + temp2) & $0F DF0WRITE = playerColorslo[temp3] temp3 = playerColorshi[temp3] DF0WRITE = (((temp3 / 2) ^ temp3) & $F0) ^ temp3 temp1 = temp1 + 1 next

It just seems like 9 times out of 10 when someone suggests a bogus op code there's no reason for it. I avoid them, although I can't really see any harm for code that's only going to be run eg on a 2600. Aside from the obvious reasons not to use them, they're cheating

wouldn't ldx Graphics5,y work about as well?

I know nothing of DPC+ Your code is kind of goofy sometimes and I didn't try to figure out if it will do what you want it to do. Here's that code in bB const pptrs_lo = <playerpointers const pptrs_hi = >playerpointers data playerColorslo <milCol, <milCol, <milCol, <drkCol end data playerColorshi >milCol, >milCol, >milCol, >drkCol end temp1 = 0 for temp2 = 20 to 26 step 2 temp3 = enemy0[temp1] DF0LOW = pptrs_lo + temp2 DF0HI = (pptrs_hi + temp2) & $0F DF0WRITE = playerColorslo[temp3] temp3 = playerColorshi[temp3] temp4 = temp3 & $0F DF0WRITE = ((temp3 / 2) & $70) | temp4 temp1 = temp1 + 1 next It looks like DF0LOW, DF0HI, DF0WRITE are just regular variables in the DPC+ kernel (that is, they're zero page locations that can be written to) but I can never get DPC+ to work. If they're dimmed to variables in the standard kernel that code will compile.

I know nothing of DPC+ one thing, temp2 is a constant in the standard kenel its = $9D where you have lda #<(playerpointers+temp2) I think you want something like lda temp2 clc adc #<playerpointers so something like eg for temp1 = 20 to 26 step 2 enemycolor asm lda #<playerpointers clc adc temp1 sta DF0LOW lda #>playerpointers clc adc temp1 and #$0F sta DF0HI lda #<milCol sta DF0WRITE lda #((>milCol) & $0F) | (((>milCol) / 2) & $70) sta DF0WRITE end next

not sure what you want, works for me. dim lives_centered = 1 dim lives_compact = 1 lifecolor = $aa lives = 224 lives: %11111111 %10000001 %11111111 %10000001 %10000001 %10000001 %11111111 %11111111 end LOOP drawscreen goto LOOP inline 6lives.asm

Here's essentially the same tarted up a bit hi_scor rem puts temp1 in the upper three score digits scr0 = 0 : scr1 = scr1 & 15 if temp1 >= 100 then scr0 = scr0 + 16 : temp1 = temp1 - 100 if temp1 >= 100 then scr0 = scr0 + 16 : temp1 = temp1 - 100 if temp1 >= 50 then scr0 = scr0 + 5 : temp1 = temp1 - 50 if temp1 >= 30 then scr0 = scr0 + 3 : temp1 = temp1 - 30 if temp1 >= 20 then scr0 = scr0 + 2 : temp1 = temp1 - 20 if temp1 >= 10 then scr0 = scr0 + 1 : temp1 = temp1 - 10 scr1 = (temp1 * 4 * 4) | scr1 return lo_scor rem puts temp1 in the lower three digits of score scr1 = scr1 & 240 : scr2 = 0 if temp1 >= 100 then scr1 = scr1 + 1 : temp1 = temp1 - 100 if temp1 >= 100 then scr1 = scr1 + 1 : temp1 = temp1 - 100 if temp1 >= 50 then scr2 = scr2 + 80 : temp1 = temp1 - 50 if temp1 >= 30 then scr2 = scr2 + 48 : temp1 = temp1 - 30 if temp1 >= 20 then scr2 = scr2 + 32 : temp1 = temp1 - 20 if temp1 >= 10 then scr2 = scr2 + 16 : temp1 = temp1 - 10 scr2 = scr2 | temp1 return here's something similar but shorter and probably slower. also uses two more temp variables hi_scor rem puts temp1 in the upper three score digits scor0 = 0 : scor1 = scor1 & 15 hi_100s if temp1 >= 100 then scor0 = scor0 + 16 : temp1 = temp1 - 100 : goto hi_100s temp2 = 80 : temp3 = 8 hi_scor_loop if temp1 >= temp2 then scor0 = scor0 + temp3 : temp1 = temp1 - temp2 temp2 = temp2 / 2 : temp3 = temp3 / 2 if temp3 then hi_scor_loop scor1 = (temp1 * 4 * 4) | scor1 return lo_scor rem puts temp1 in the lower three digits of score scor1 = scor1 & 240 : scor2 = 0 lo_100s if temp1 >= 100 then scor1 = scor1 + 1 : temp1 = temp1 - 100 : goto lo_100s temp2 = 80 : temp3 = 128 lo_scor_loop if temp1 >= temp2 then scor2 = scor2 + temp3 : temp1 = temp1 - temp2 temp2 = temp2 / 2 : temp3 = temp3 / 2 if temp2 >= 10 then lo_scor_loop scor2 = scor2 | temp1 return edit: Here's another shorter bB version that is even shorter and doesn't use more temp variables and I think is not substantially slower than the previous shorter bB version. hi_scor rem puts temp1 in the upper three score digits scor0 = 0 hi_scor_100s_loop if temp1 >= 100 then scor0 = scor0 + 16 : temp1 = temp1 - 100 : goto hi_scor_100s_loop goto enter_hi_scor_10s_loop hi_scor_10s_loop scor0 = scor0 + 1 : temp1 = temp1 - 10 enter_hi_scor_10s_loop if temp1 >= 10 then hi_scor_10s_loop scor1 = (((temp1 * 4 * 4) ^ scor1) & $F0) ^ scor1 return lo_scor rem puts temp1 in the lower three digits of score scor1 = scor1 & 240 : scor2 = 0 lo_scor_100s_loop if temp1 >= 100 then scor1 = scor1 + 1 : temp1 = temp1 - 100 : goto lo_scor_100s_loop goto enter_lo_scor_10s_loop lo_scor_10s_loop scor2 = scor2 + 1 : temp1 = temp1 - 10 enter_lo_scor_10s_loop if temp1 >= 10 then lo_scor_10s_loop scor2 = (scor2 * 4 * 4) | temp1 return here's some asm hi_scor rem puts temp1 in the upper three score digits asm ldx #$FF lda temp1 sec hi_100s_loop inx sbc #$64 bcs hi_100s_loop adc #$64 sta temp1 txa asl asl asl asl tax lda temp1 sec hi_10s_loop inx sbc #$0A bcs hi_10s_loop adc #$0A dex asl asl asl asl eor scor1 and #$F0 eor scor1 sta scor1 stx scor0 rts end lo_scor rem puts temp1 in the lower three digits of score asm ldx #$FF lda temp1 sec lo_100s_loop inx sbc #$64 bcs lo_100s_loop adc #$64 sta temp1 txa eor scor1 and #$0F eor scor1 sta scor1 lda temp1 ldx #$FF sec lo_10s_loop inx sbc #$0A bcs lo_10s_loop adc #$0A sta temp1 txa asl asl asl asl ora temp1 sta scor2 rts end edit: yet another (asm) version a little shorter a little faster rem puts temp1 into the upper 3 score digits rem uses the table defined in lo_score hi_scor asm lda temp1 ldx #$00 hi_100s_loop cmp #$64 bcc skip_hi_100s sbc #$64 inx bne hi_100s_loop skip_hi_100s ldy scor_x10_tbl,x sec hi_10s_loop iny sbc #$0A bcs hi_10s_loop adc #$0A dey sty scor0 tax lda scor_x10_tbl,x eor scor1 and #$F0 eor scor1 sta scor1 rts end rem puts temp1 into the lower 3 score digits lo_scor asm lda scor1 and #$F0 sta scor1 lda temp1 lo_100s_loop cmp #$64 bcc skip_lo_100s sbc #$64 inc scor1 bne lo_100s_loop skip_lo_100s ldx #$FF SEC lo_10s_loop inx sbc #$0A bcs lo_10s_loop adc #$0A ora scor_x10_tbl,x sta scor2 rts scor_x10_tbl .byte $00, $10, $20, $30, $40, $50, $60, $70, $80, $90 end edit I hate uncommented code does this need commenting?

Did you try this ?

here's some quick and dirty you could try dim scr0 = $93 dim scr1 = $94 dim scr2 = $95 scorecolor = $AA temp1 = 125 rem puts temp1 in the upper three score digits scr0= 0 : scr1 = scr1 & 15 if temp1 > 99 then scr0= scr0+ 16 : temp1 = temp1 - 100 if temp1 > 99 then scr0= scr0+ 16 : temp1 = temp1 - 100 if temp1 > 49 then scr0= scr0+ 5 : temp1 = temp1 - 50 if temp1 > 29 then scr0= scr0+ 3 : temp1 = temp1 - 30 if temp1 > 19 then scr0= scr0+ 2 : temp1 = temp1 - 20 if temp1 > 9 then scr0= scr0+ 1 : temp1 = temp1 - 10 scr1 = (temp1 * 4 * 4)| scr1 temp1 = 234 rem puts temp1 in the lower three digits of score scr1 = scr1 & 240 : scr2 = 0 if temp1 > 99 then scr1 = scr1 + 1 : temp1 = temp1 - 100 if temp1 > 99 then scr1 = scr1 + 1 : temp1 = temp1 - 100 if temp1 > 49 then scr2 = scr2 + 80 : temp1 = temp1 - 50 if temp1 > 29 then scr2 = scr2 + 48 : temp1 = temp1 - 30 if temp1 > 19 then scr2 = scr2 + 32 : temp1 = temp1 - 20 if temp1 > 9 then scr2 = scr2 + 16 : temp1 = temp1 - 10 scr2 = scr2 | temp1 LOOP drawscreen goto LOOP I just poke a byte to the playfield

I don't use Visual bB I don't think there's any problem with any of that. it appears that bB just pairs the fors and nexts as it encounters them, it doesn't know anything about code blocks or program flow. (RTs page says it applies a next to the previous for but if that were true you couldn't nest for next loops.)

Here's some code to do ranged random numbers with out the biases of some of the other methods and using only one call to rand. But it does need a dedicated variable (called my_seed here) basically it's just mod but carrying the bias forward so it gets distributed. The code is as yet UNTESTED There are two cases. If the range is between 0 - 128 and 0 - 254 (inclusive) the difference between 256 and the modulus is added back in and my_seed is taken mod the modulus (by subtraction) It uses a temp variable and needs two constants the modulus, rnd_modulus and the difference 256-modulus, mod _dif so for a range 0-137 const rnd_modulus =138 and const mod_dif = 118 temp1 = my_seed my_seed = rand + temp1 if my_seed < temp1 then my_seed = my_seed + mod_dif if my_seed >= rnd_modulus then my_seed = my_seed - rnd_modulus In asm you only need the modulus constant and my_seed. you don't need the temp variable or to have mod_dif defined as a constant asm jsr randomize clc adc my_seed bcc *+4 adc #255-rnd_modulus cmp #rnd_modulus bcc *+4 sbc #rnd_modulus sta my_seed end For a range less than 128 the result of rand is taken mod a power of two to minimize the modulus operation. It needs a temp variable and my_seed and two constants, rnd_modulus, and a power of two mask, rnd_mask, equal to the lowest power of two that's greater than the modulus, minus 1 so for a range 0-17 the next power of two is 32 and the mask is const rnd_mask = 32 - 1 and the modulus const rnd_modulus = 18 dim my_seed = variable const rnd_mask = const rnd_modulus = my_seed = (rand & rnd_mask) + my_seed if my_seed >= rnd_modulus then my_seed = my_seed - rnd_modulus if my_seed >= rnd_modulus then my_seed = my_seed - rnd_modulus in asm asm jsr randomize and #rnd_mask clc adc my_seed cmp #rnd_modulus bcc *+4 sbc #rnd_modulus cmp #rnd_modulus bcc *+4 sbc #rnd_modulus sta my_seed end

I'm still not sure what you're trying to do so that may not be helpful. The variable names are constants, I just put them in a table so they could be indexed. To get your indirection you have to look them up and put them in a variable to use as a pointer since bB doesn't allow for indirection to go any deeper than that. I used temp variables renamed to xptr, yptr And yes I was just applying it to the previous little bit of code as an example. The only reason I could see for doing it that way is for indexing as in the for next loop but you could in principle do it with named constant (hence the constant definitions of table indexes) You'd still have to do the look ups rem this writes x to player0x xptr = x_ptrs[player0] mem[xptr] = x rem this reads x from player0x xptr = x_ptrs[player0] x = mem[xptr] You could put stuff like that into macros and/or subroutines I suppose but I'm not sure you need anything that general? As RevEng points out they're all ready mostly in order if you're counting through indexes. If you want something more random access or arbitrary it's going to cost you, but it could probably be done. The question is what will it save you? What are you trying to do specifically?

You could put your mapping into table and do something like this. const mem = 0 const player0 = 0 const player1 = 1 const player2 = 2 const player3 = 3 const player2 = 4 const player3 = 5 const missle0 = 6 const missle1 = 7 const ball = 8 dim xptr = temp1 dim yptr = temp2 data x_ptrs player0x, player1x, player2x, player3x, player2x, player3x, missle0x, missle1x, ballx end data y_ptrs player0y, player1y, player2y, player3y, player2y, player3y, missle0y, missle1y, bally end for i = 0 to 1 xptr = x_ptrs[i] yptr = y_ptrs[i] mem[xptr] = spritex[i] mem[yptr] = spritey[i] next

What kernel/kernel options are you using ? edit I'm having trouble following your code. I think what you want for that last bit would be data spritex 40, 60 end data spritey 40, 60 end main_loop rem player0 is red, player1 is green COLUP0 = $40 COLUP1 = $C0 for i = 0 to 1 player0x[i] = spritex[i] player0y[i] = spritey[i] next drawscreen goto main_loop let me rephrase that I'm not sure that's what you want I think that's what you're doing.

I hate to be a nay sayer but that's way overkill. You won't split a second to any better than a frame. You can keep the seconds / frames accurate. but even an inaccurate 24 bit fraction will be better than the best crystal clock where they think they're doing really good if they keep it to one part in 100000. It would be a lot simpler just to accumulate seconds/frame. 32 bits would be off by something like a second / 10 days And a 32 bit (or what ever) fraction could actually be more accurate than 32 bits. In the case of 59736/3579575 seconds/frame it's more like 35 bits

I see I goofed it up when I transposed them 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 but that just makes it the same as the zombie chase code

crap Ever look back at a bit of code and say what the hell was I thinking !? Presumably you had the wits to ignore this if joy0right || joy0left then direction = direction ^ 1 : goto skip for this if joy0right then direction = 1 if joy0left then direction = 0 If not please do so.