bogax

I really shouldn't comment 'cause I have very little idea what goes on (especially with visual bB) lst is a switch in the tail of the line that invokes DASM I assume sym would be similar (I believe) the labels are part of the asm the bB generates, no way for DASM to distinguish one from the other. Why would you want to suppress them? (whether or not they're really necessary I don't know. I think bB throws stuff in there just in case)

Here I've made two changes to the setup_move code to improve the accuracy First we can assume that dy wont be more than 128 so if dx is less than 128, dx and dy are multiplied by 2 that should give you something like 1/2 pixel accuracy in the calculations most of the time, instead of 1 pixel Second it sets ea iff ea looks like it's too far out of whack for the current dx and/or dy It's still possible to make player0 miss but it's a lot harder improved_movement.bas improved_movement.bin

I think you should either skip the move code altogether at the limits or redo the setup if you apply the limit because doing only part of the move will cause you to deviate from the line you want to follow The movement of the sprite and the operation of the error accumulator are really independent the sprite needs to follow what the error accumulator is doing. If you limit what the sprite does and not the error accumulator they will diverge You really shouldn't need the limits on the player0 sprite it can only follow player1 and player1 is limited Having said that it's still possible to make player0 miss (and go off screen) (with the previous code) but player1 has to hold still, move slightly at just the right time, then hold still again. Even if player0 misses (and goes off screen), any movement of player1 should bring it back

I suppose you think that's easier to understand than my code The only real criticism I have is 1) the the player0 move code can move player0 on both axis but you only test for one (x on one branch and y on the other) 2) you should test for the limits and then skip the move rather than make the move and try to undo it also, in this bit of code _x0 = player0x + 1 : _y0 = player0y + 1 _x1 = player1x + 1 : _y1 = player1y the + 1's are there to compensate for the size of the sprites to make the aiming point somewhere near the middle, they're left over junk that I should have removed (or adjusted) you don't really need _x0, _y0, _x1, _y1 they're more in the nature of parameters so that the setup move code isn't dedicated to one set of conditions (player0 moving towards player1 in this case)

setup_move has to come first because it computes dx and dy and sets f{0} to indicate which is larger and set_ea sets ea to the larger (divided by two) of the two and uses f{0} to determine which

There's two problems with the moving target code One is the movement code just isn't very accurate if you make both the players 1 pixel it will generally miss If you make at least one of the players 2 pixels it won't miss if you're not moving but it's not hard to cause a miss by holding still when player0 comes at you from far away so that dx and/or dy have (relatively) large values, then dodging towards but missing player0 when it gets very close (so that the residual ea is large compared to the new dx and/or dy) (I'm guessing, I didn't really look to see if that's what's happening) I expected to see it with the wrap around movement by jumping back and forth between diagonally opposed corners but it turns out it's not too hard to cause a miss even when player1 is 4 x 4 pixels This is not unexpected, I deliberately made the code simple but I didn't expect it to be so easy to cause a miss when player1 is as large as 4 x 4 The only change I'd make is to set ea to half of dx or dy (when it comes time to set ea) I think that would make it slightly more accurate and not cost much So for example I'd make the setting of ea a subroutine that could be called only when it's really necessary (in this case when a new player0 is spawned) And just be aware that the code as is has limitations moving_target_2.bas moving_target_2.bin

if you just leave player1 sitting you'll see player0 sometimes misses

ea is error accumulator if eg dx is greater than dy then when you've accumulated dx worth of dy's you've accumulated a pixel's worth of error and it's time to take a step in y (you're a pixel away from where you want to be in the y direction) I hadn't quite decided how to deal with a moving target. you'd need to re-do the setup but I think you would want to retain the accumulated error so you sort of bend the line of your path without restarting. I haven't decided the best way to do that. the first thing I'll try is just re computing the setup without changing ea and see what it looks like basically when you change octant dx and dy swap places but the actual values you're working with don't change much and presumably if you don't change octant the difference between changes wouldn't be much (at least that's what I'm thinking) this just (re) sets up the move without resetting ea if player1 moves moving_target.bas moving_target.bin

I shouldn't post this stuff when I'm tired In the cold light of day.. It's more straight forward to make the timer count down .01 rounds to .0078125 I chose that because it gives you the closest to 5 minutes while only setting one variable (I think) dim timer = counter1.counter0 counter1 = 142 timer = timer - 0.01 if !counter1 then next_level

here you can compare the two movement_comparison.bas movement_comparison.bin

They produce basically similar code .L00 ; if a >= 70 then skip LDA a CMP #70 bcs .skip . ; .L01 ; if a > 69 then skip LDA #69 CMP a bcc .skip . another way to do the timer timer will rollover at 256 and .01 is actually .78125 ie .01 gets rounded to 2/256 dim timer = counter1.counter0 counter1 = 115 timer = timer + 0.01 if !counter1 then next_level

or you could just do it in bB temp1 = scroll_distance scroll_distance = scroll_distance + scroll_speed if scroll_distance < temp1 then scroll

Here's some Bresenham type movement code This moves player0 towards player1 while joy0fire is pressed When a collision occurs the players are repositioned randomly and paused for 1 second The setup_move code computes the absolute value of delta x and delta y from x0,y0 and x1,y1 and sets a bit in f for each to indicate if they were positive or negative it then sets a bit according to which is larger. This determines the octant we're moving in and is used to lookup the direction of movement (+1, -1) in the xinc and yinc tables The playfield pixels are the octant were moving in (the f variable) and some reference pixels to show which bits are which (var40 = %01010101) (I did this for my own purposes but when I Googled for similar stuff in bB I found nothing so I thought I'd share it in case some else wants something like) move.bas move.bin

According to RTs chart you don't have any missiles

Which is better would be for the individual programmer to decide but there's generally several ways to do something with different timing and space requirements I think it would be a shame to just exposit on different methods without providing some analysis (and tabulation of) timing and space so that a programmer could see the trade offs (and after all that analysis is what you were just doing)

but of course you should gosub to the on goto and then return (if you just have to use on goto) instead of that jump there then jump back nonsense, and that will cost something re a blog, a tabulation and comparison of different techniques would be usefull but it could get complicated (eg if it were me I'd probably put the sprites in a data statement)

but I think Papa is right about the colors, put them in a subroutine and don't set them if you don't need to.

dim rand16 = z dim count = y rem the location of variable a is $00D6 player0pointerhi = $00 player0pointerlo = $D6 rem the sprite will be 10 bytes, 0..9 rem here that's variables a..j rem the tenth location, location 9 rem is the top player0height = 9 player0x = 80 player0y = 40 rem just to show us where we are j = $FF loop count = count - 1 COLUP0 = $3A drawscreen if count then loop count = 30 rem just scrolls some random rem stuff through the sprite to rem show something happening for temp1 = 0 to 8 temp2 = temp1 + 1 a[temp1] = a[temp2] next rem j is a[9] the top of the sprite j = rand goto loop

with bB I think you'd have to put the sprite data in RAM where you could manipulate it and point the sprite pointer(s) at the ram (normaly the sprites are just blocks in ROM you can choose diferent ones but you can't change them)

then make it disappear I think that's usually done by parking it somewhere off the playfield but I assume you could blank it or change the color to match whatever it's over

if collision(missile0, player1) then score = score + 1 : player1x = rand/2 : player1y = 0 : missile0y = 255 if collision(player0 , player1) then score = score - 1 : player1x = rand/2 : player1y = 0 : missile0y = 255 : pfscore1 = pfscore1*4 rem pfscore1 may have changed so check to see if you've rem run out of lives and if so jump to game over rem !pfscore1 is like pfscore1 = 0 if !pfscore1 then gameover goto __Main_Loop jump goto sprites goto draw_loop gameover playfield: ..XXXXXX..XXXXX..XXXXXXX..XXXXXX ..X.......X...X..X..X..X..X..... ..X.XXX...XXXXX..X..X..X..XXXXXX ..X...X...X...X..X..X..X..X..... ..XXXXX...X...X..X.....X..XXXXXX ................................ ..XXXXXX.X........X.XXXX..XXXX.. ..X....X..X......X..X.....X..X.. ..X....X...X....X...XXXX..XXXX.. ..X....X....X..X....X.....XX.... ..XXXXXX.....XX.....XXXX..X.X... end gameover_loop drawscreen goto gameover_loop something like that then although I assume you're going to want some way to break out of the gameover_loop

It would help if you posted your code and were a liitle more precise about what you want to happen. when you get to zero lives you go to your gameover code that does whatever you want to happen when the game ends

heh I didn't really look at your code before if collision(player0,player1) && !p=6:then r=r+3 if collision(player0,missile1) && !p=6:then r=r+3 if r=0 then pfscore2 = %11111111 if r>30 then pfscore2 = %01111111 if r>60 then pfscore2 = %00111111 if r>90 then pfscore2 = %00011111 if r>120 then pfscore2 = %00001111 if r>150 then pfscore2 = %00000111 if r>180 then pfscore2 = %00000011 if r>210 then pfscore2 = %00000001 if r>240 then pfscore2 = %00000000 if r>242 then goto __gizdead bank4 I don't know what you think -- !p=6:then -- should do but what ever it is, I'm pretty sure it's not doing what you think. presumably you meant -- !(p = 6) then -- but in bB it would be -- p<>6 then -- (that's not real code. I substituted -- for the rest of the if statement to highlight the bit I was talking about) anyway I don't see why you need to use r = r + 3 or what you need r for except to know to adjust pfscore2 every tenth hit that being the case you could do something like this if p = 6 then skip if collision(player0,player1) then gosub inc_r if collision(player0,missile1) then gosub inc_r if !pfscore2 then goto __gizdead bank4 skip . . inc_r r = r + 1 rem the if statement adjusts the lower four bits rem of r so that the lower four bits count in BCD rem (but only counting up) and adjusts pfscore2 rem if you've reached (a multiple of) 10 temp1 = r & %00001111 if temp1 > 9 then r = r + 6 : pfscore2 = pfscore2 / 2 return the subroutine would have to go someplace out of the way of course (the if statement could just reset r to 0 when it reaches 10 but I didn't know if you had some other use for r and for keeping a higher count than 9 of course it counts kind of funny and that would have to be taken into account if so)

if !pfscore1 then gameover

man I'm no expert but I think your problem is that the sprites routine keeps reseting pfscore1 set pfscore1 to %11111111 before (or at least outside) the sprites routine (forget the pfscore1 = 100) then instead of pfscore1 = pfscore1 - 25 make it pfscore1 = pfscore1 * 4