bogax

And obviously he can look at that and see what you did but maybe he'd like to do his own code instead of use yours. Especially since he may not understand what you've done or why you've done it.

post your code Basically your code is a mess After you fix the miss spellings and put in the missing colons you don't actually draw the screen unless missile0x is <= 240 and that only happens when you press joy0fire and doesn't last playfield: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX X.........X..........X.........X X.........X..........X.........X X....X....X..........X...X.....X X....X...................X.....X X....X...................X.....X X....X...................X.....X X....X....X..........X...X.....X X.........X..........X.........X X.........X..........X.........X XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX end COLUBK = $0E COLUPF =$00 player0x=25:player0y=50 player1x=130:player1y=50 missile0height=4:missile0x=255 NUSIZ0 = 16 sprites player0: %00111000 %00100000 %01101100 %01111110 %01100000 %01111000 %00101000 %00111000 end player1: %00011100 %00000100 %00110110 %01111110 %00000110 %00011110 %00010100 %00011100 end if missile0x>240 then goto skip missile0x=missile0x-2 : goto draw_loop skip if joy0fire then missile0x = player0x-2:missile0y=player0y+4 if joy0up then player0y = player0y-1 : goto jump if joy0down then player0y = player0y+1 : goto jump if joy0left then player0x = player0x-1 : goto jump if joy0right then player0x = player0x+1 : goto jump jump goto sprites draw_loop drawscreen goto sprites

LOL I suggested you post your code because, while there maybe common newbie mistakes that might be suggested, it's much more difficult to diagnose things without seeing the code. but ... (mis)spelling missile as missle is somerthing I'm constantly doing I wonder how common that is. (it's not that I don't know how to spell missile it's just that my fingers somehow miss that second i )

post your code

oh, well then here's one that shaves another 3 bytes x3_cloop2.bas

Something like this? r_fill_pf.bas

You can nest for-next loops You only get one next per for and a next is associates with the next previous for that's not already paired with a next so for j = 1 to 10 for i = 1 to 10 goto skip next skip next is like for j = 1 to 10 for i = 1 to 10 goto skip next i skip next j (even if you put in the i and the j ) (like this) for j = 1 to 10 for i = 1 to 10 goto skip next j skip next i

unless its changed, rand doesn't use temp1

Just for the hell of it here the collision determination is done by looping through the three copies. Probably not worth the bother but it saves 10 bytes x3_cloop.bas

Wouldn't compile for me. Doesn't like the if statement on line 96 if player1x + temp1 > 154 then player1x = 153 - temp1 : player1_motion = 255

Here's another one x3.bas edit cleaned it up a little

I rearranged your code I moved the sprite animation into a subroutine called sprite_animation at the end of code to get it out of the main loop because I think that makes it easier to see what's going on in the main loop. But it costs a subroutine call. I added a timer called timer that counts to ten which is then used to update sprite_animation timers f and g. Sprite_animation is only called when timer rolls over so you only do the sprites when they change (which is all you need) I moved the playfield statement out of the main loop you only need playfield statement once (per different playfield that is) You set it once and it will stay that way untill you change it. I moved the player1x generation into a subroutine called new_x for no good reason except to make it clear that you're doing your player1x generation as an aside and then coming back to do drawscreen instead of looping back and missing drawscreen. I added some missile0 x movement. I also changed the missle height just because I think it looks better. Just because I changed something doesn't mean I think that's the way you must do it or even that I think that's the way it should be done. Some of this stuff I might do differently. I probably made some other minor changes that I forget. Your code spends most of it's time doing drawscreen and it has to do drawscreen at precise times. The rest of your code runs in the time that's left over. You have to get what ever you need done and then call drawscreen again before it's too late. For now your code is simple enough that you can waste some time without running out. But you don't really want to waste any time doing things you don't need to do and you don't want to skip drawscreen rabbit.bas

yes you didn't quite state that explicitly so I tried to.

player1-5 are all actually player1 if you get a player1 collision you have to test which of them it is.

the only problem with the temp variables is that bB uses them. If you don't ask bB to do anything that uses them you're safe drawscreen uses them pfread uses temp1 and temp2 it's not always obvious that you're asking bB to do something that will use them. a multiplication or division by something other than a constant that is a power of 2 uses temp1 and temp2 multiplication and division are only things I can think of just off hand that aren't obvious or might slip by (me at least)

I see atari2600land beat me to it but here's mine (haven't looked atatari2600land's yet) rem Generated 2013-05-27 22:17:41 by Visual bB Version 1.0.0.554 rem ********************************** rem *<filename> * rem *<description> * rem *<author> * rem *<contact info> * rem *<license> * rem ********************************** dim v1x = u x=50 y=56 v1x = -1 player1x = 137 player1y = 32 main playfield: ................................ ................................ ................................ ................................ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ................................ ................................ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ................................ ................................ ................................ end COLUP0=$28 COLUP1=$20 COLUBK=$00 COLUPF=$D4 f=f+1 if f=10 then player0: %00011000 %00011000 %00111100 %00111100 %00000000 %00011000 %00011000 %00000000 end if f=20 then player0: %01000010 %00100100 %01011000 %01111110 %00000010 %00011000 %00011000 %00000000 end if f=20 then f=0 g=g+1 if g=10 then player1: %11111111 %10000001 %10111101 %10000001 %10100101 %10000001 %01000010 %00111100 end if g=20 then player1: %11111111 %10000001 %11111001 %10000001 %11001001 %10000001 %01000010 %00111100 end if g=30 then player1: %11111111 %10000001 %10000001 %10000001 %10000001 %10000001 %01000010 %00111100 end if g=40 then player1: %11111111 %10000001 %10000001 %10000001 %10000001 %10000001 %01000010 %00111100 end if g=50 then player1: %11111111 %10000001 %10011111 %10000001 %10010011 %10000001 %01000010 %00111100 end if g=50 then g=0 player1x = player1x + v1x if player1x > 16 then skip player1x=137 a = rand & 1 if a then player1y = 32 else player1y = 56 skip drawscreen if joy0right then x=x+1 if joy0left then x=x-1 if joy0up && y=56 then y=32 if joy0down && y=32 then y=56 skipmovement goto main

so you want player1 to change it's x position continuously you need to update the position continuously (every drawscreen I guess) so you'd keep a delta x position, a velocity basically, and add it to the player1x position every drawscreen. dim vx = x vx = -1 . . . player1x = player1x + vx drawscreen you could just increment player1x but then you need a seperate statement to decrement player1x if you want to go right

now I'm confused perhaps I'm mixing up to seperate lines of discussion here. previously you said but 2 seconds is not a random interval and y is up-down not left-right

oops sorry I forgot we're not all english speakers (or 'mericun or what ever that would be) It just means do whatever you're going to do with player1 (I'm not really sure what you want to do) edit (with reference to previous posts) I'm guessing it would be something like temp1 = counter & 63 if !temp1 then temp2 = rand & 1 : player1y = tbl[temp2]

you could increment a counter every time you do a drawscreen so it gets incremented ~30 times a second then mask for the lower 6 bits and mess with player1 if they're 0 which they will be every 64 counts (a little more than 2 seconds) something like drawscreen counter = counter + 1 . . . temp1 = counter & 63 if !temp1 then mess with player1

& is a bitwise and meaning corresponding bits in the two operands are anded together 1 & x = x 0 & x = 0 2 is %00000010 rand %hgfedcba rand & 2 = %000000b0 think of the letters as variables for individual bits in particular positions in the byte rand & 2 = %000000b0 b can be 1 or 0 so the result of rand & 2 will equal 2 or 0 1 in the b bit positon is equal to 2 that is 2 in binary is %00000010 rand & 2 will never be 1 as in %0000001 which is what if a = 1 then ... tests for your code should be if a = 0 then player1y=56:player1x=137 if a = 2 then player1y=32:player1x=137 I assume that means player1x will always get set to 137 so there's no need to set it conditionally so you could do it this way player1x=137 if a = 0 then player1y=56 if a = 2 then player1y=32 if you write if a then ... its the same as if a<>0 then ... and since you only have two possibilities you could write your code like this player1x=137 if a then player1y = 32 else player1y = 56 this way you only do one if then statement with the others you always do two even though only one can be true. edit using the else ends up as if you'd written if a then player1y = 32 : goto skip player1y = 56 skip it saves you an if statement but costs you the equivalent of a goto personaly I would use a table look up for this situation although it doesn't save you much if anything with only two possibilities a = rand & 1 player1x = 137 player1y = tbl[a] data tbl 56, 32 end

It really depends on context and what better means. The first bit of code is slightly faster (1 cycle) on average if 1 and 0 are equally likely and its slightly shorter. 27/39, 33 average cylces v 34 cycles 30 bytes v 36 bytes If you do your if statement like this _NUSIZ0 = _NUSIZ0 | $10 : missile0height = 1 if !_Missile_Width then _NUSIZ0 = _NUSIZ0 & $0F : missile0height = 0 NUSIZ0 = _NUSIZ0 You save 2 cycles and 2 bytes in the if statement. (and if you know _Missile_Width will always be 1 or 0 you can do if _Missile_Width then .. if treats non zero as true which would make the second bit of code 1 cycle faster)

I think pfread uses temp1 and temp2 perhaps this temp4 = ((player0x-15)/4) temp5 = temp4 + 1 temp6 = ((player0y-1)/8) - 1 if !pfread(temp4,temp6) then if !pfread(temp5,temp6) then player0y = player0y - 1

two bytes (lda value) works for variables too assignments with the same value need to be consecutive a = 1 : b = 2 : c = 1 : d = 2 saves you nothing a = 1 : c = 1 : d = 2 : b = 2 saves four bytes

Which is a lot faster but takes a lot more space. But it's not necessarily only speeding up calculations. It might be look up what to do for this player moving in that direction with those conditions.