bogax

figure out where you want to move to then check it for a playfield pixel there. if there is, don't move (or bounce or something) if there isn't then move. platfield pixels are 8 pixels wide (in the standard kernel) and are offset from the player's position (playfield pixel 0 covers player positions 10..17 (or something, forget the offset)) the playfield pixels are in var0..var43 bit 7 of var0 is playfield pixel 0 (top left) var0..var3 are the first (top) line of the playfield, var4..var7 the second line, etc some of the bytes are reversed (instead of bit 7..0 going left to right some are 0..7 going left to right)

I think it's a fine thing for you to use assembly. so by all means do. But what I was talking about is knowing enough about the nuts and bolts to use bB (which may include doing stuff in assembly that you can't do in bB or finding out things you might want/need to know to do what you're doing in bB by looking at the assembly listing) here's an animated sprite that runs forward then backward through 35 (or so) frames (I forget the exact number) for a cycle of 70 frames. it's in bB. all the frames are in a single player0 definition. animated_sprite.bas (pastebin)

here I've invoked the multisprite kernel commented out the extraneous stuff and set the frames of the pancake animation to three different sprites set kernel multisprite set tv ntsc x=75 : y =75 pfheight=1 const screenheight = 80 scorecolor = $1C playfield: .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. .............................. end main COLUP0 = $00 _COLUP1 = $1C COLUP2 = $30 COLUP3 = $3A COLUBK = $86 REFP1 = 0 drawscreen c = c + 1 if !(c & $0F) then f=f+1 player0x=10 player0y=10 player1x=30 player1y=30 player2x=40 player2y=40 player3x=50 player3y=50 rem if f=1 then player1: %00000000 %00011000 %01111110 %01100110 %01111110 %00011000 %00000000 %00000000 end rem if f=1 then player1color: rem $40 rem $20 rem $22 rem $24 rem $22 rem $20 rem $40 rem $40 rem end rem if f=2 then player2: %00000000 %00000000 %00000000 %00011000 %00000000 %00000000 %00000000 %00000000 end rem if f=2 then player1color: rem $40 rem $40 rem $40 rem $1E rem $40 rem $40 rem $40 rem $40 rem end rem if f=3 then player3: %00011000 %01100110 %10000001 %10000001 %10000001 %01100110 %00011000 %00000000 end rem if f=3 then player1color: rem $0A rem $0C rem $0C rem $0E rem $0C rem $0C rem $0A rem $40 rem end if f=3 then f=0 rem drawscreen rem player1x=x : player1y=y if joy0right then REFP1 = 0 if joy0right then x=x+1 if joy0left then REFP1 = 8 if joy0left then x=x-1 if joy0up then y=y-1 if joy0down then y=y+1 goto main

why can't you just cut and paste? if I understand what you want to do you will be better off if you do it in a way that requires some knowledge of some details of how batari Basic and the kernel work (but that's not to say it can't be done without that). Does being a newbie mean you're going to avoid that? for example statements like if f=1 then player1: . . if f=2 then player1: . . might be done [something like] this player1pointer = P1_animation[f] but you have to be willing to find out how the sprites work and what the player pointers are and maybe dig into the listing to find out what the actual values need to be

assuming that's not including the fire switch then (in Stella at least) SWCHA = $FF should do edit: maybe RevEng fixed some stuff 'cause it looks like this will work rem a small demo rem if no joy then black rem else blue rem (joy0) def joy0 = ((SWCHA ^ $F0) & $F0) COLUPF = $30 var36 = $55 loop if !joy0 then COLUBK = $00 else COLUBK = $80 var32 = SWCHA drawscreen goto loop

what is it meant to be (or do)?

I think you could still save a few (more) bytes

sorry I wasn't clear I meant mem generically (same with index). ie mem as short for "some location in memory" mem is not a keyword. As to what you were talking about, that's a neat idea. I'll have to think about what utility that has

What does that mean? One of the really nice things about bB is the mem[index] syntax it uses (instead of, eg peek() poke() ). But it really needs to expose the registers to go with that (and not only for that). Are you going to have register variables?

post your code you can also refer to the second byte of score as score[1] so you could try something like this temp1 = score[1] + 1 if player1y < player0y then player1y = player1y + temp1 if player1y > player0y then player1y = player1y - temp1 if player1x < player0x then player1x = player1x + temp1 if player1x > player0x then player1x = player1x - temp1

score is a three byte, six decimal (BCD) digit variable. the bytes are in reverse order, the least significant byte has the highest address try this edit: oops (fixed) rem give the second byte of the score a name dim scr_hundreds = score + 1 if player1y < player0y then player1y = player1y + scr_hundreds + 1 if player1y > player0y then player1y = player1y - scr_hundreds - 1 if player1x < player0x then player1x = player1x + scr_hundreds + 1 if player1x > player0x then player1x = player1x - scr_hundreds - 1

are you trying to simulate gravity? or do you just want to go up and down between platforms?

jeezus wept 5MB of javascript to download a 1k file? why don't you just post it to the forum either by enclosing it in [_code_] [_/code_] (remove the underscores) tags or attaching it

for one thing the sprite has to overlap the platform in order for there to be a collision for another you don't need to fall at all if you're on the platform so there'd be no point in falling (and presumably then undoing it if you don't want to fall) assuming the platform is a simple horizontal surface, you could test the limits when you move in the x direction something like if !joyright then left x = x + 1 if x = right_limit then fall goto after_x_move left if !joyleft then after_x_move x = x - 1 if x = left_limit then fall after_x_move

I think ZackAttack makes it sound simpler than it's likely to look if you're jumping in to the subject cold (ie with no knowledge at all of state machines). For one thing, state will necessarily include stuff like what platform you're on and whether you've fallen off screen. But to interpret ZackAttack (and risk trying to put words in his mouth) You'd have a state variable who's value reflects the current state and you'll choose which piece of code to run depending on the state variable (maybe) using on-gosub. You don't really need to deal with Y movement at all if you are on platform and you might want to deal with moving up (jumping) and moving down (falling) differently So if you're in the on platform state you don't worry about what happens when you're falling or jumping at all. You will look for stuff that changes state. if fire is pressed change to jump state. if X movement moves you off platform change to falling state (and there will be concomittent stuff that goes with that like Y velocity) (personally I think falling and jumping are likely to be so similar that I'd just have it be moving in the Y direction or not but that would depend on what you want your code to do and how you prefer to deal with it)

set up the move as if it were the cat moving towards the mouse but then apply it to the mouse movement

not sure I recall correctly but no you don't need to pop any thing next gets paired with the most recent unpaired for so you can only have one next per for and you have to have a for for every next and you can't overlap for-next loops you can only nest them

I'm guessing that sprite sorting is the problem Here the colors get changed set kernel multisprite set romsize 2k dim rand16 = r the_beginning rem player sprites player0: %0110110 %0010100 %0010100 %0010100 %1010101 %1011101 %1011101 %1011101 %1011101 %0111110 %0001000 %0111110 %1011101 %1100011 %1111111 %1101011 %0111110 end player4: %011110 %111111 %111111 %111111 %011110 end player1pointerlo = player4pointerlo : player2pointerlo = player4pointerlo : player3pointerlo = player4pointerlo player1pointerhi = player4pointerhi : player2pointerhi = player4pointerhi : player3pointerhi = player4pointerhi player1height = player4height : player2height = player4height : player3height = player4height player1y = 80 player2y = 60 player3y = 40 player4y = 20 rem k{0} explained later rem l=AUDF0 k{0}=1 : l=33 : player0y=110 goto start_game_2 start_game k=0 : l=0 : score=0 : m=0 j=1 rem m=score timer rem j=speed of tomatoes start_game_2 rem i=which tomato to get positions of for i = 0 to 3 gosub intialize_tomato next player0y=1 : player0x=20 main_game drawscreen if switchreset then i=0 : goto the_beginning if k{0} then goto player_dead if player0y<20 then player0y=player0y+1 : goto main_game if joy0up && player0y<80 then player0y=player0y+2 if joy0down && player0y>20 then player0y=player0y-2 rem m=scoretimer. if m>59 = one second. m=m+1 if m>59 then m=0 : score=score+1 rem controlling tomato 1's movement for i = 0 to 3 if a[i] then a[i] = a[i] - 1 else player1x[i] = player1x[i] - j : _COLUP1[i] = $48 if player1x[i] < 10 then gosub intialize_tomato next rem k{0}=1 - you're dead , k{0}=0 - you're not dead. if collision(player1,player0) && !k{0} then l=20 : k{0}=1 player_dead rem if dead and l<32 then make a splat sound, else be silent if k{0} && l<32 then AUDV0=4 : AUDC0=1 : AUDF0=l : l=l+1 if k{0} && l>31 then AUDV0=0 : l=32 if k{0} && joy0fire then i=0 : goto start_game goto main_game intialize_tomato a[i] = rand / 4 : player1x[i] = 150 : _COLUP1[i] = $BA return vblank rem colors for the sprites and background. COLUBK=$BA : COLUP0=$2c return Here the sprites get blanked set kernel multisprite set romsize 2k dim rand16 = r const blank = <playerL07_4 const show = <playerL07_4 + 5 the_beginning rem player sprites player0: %0110110 %0010100 %0010100 %0010100 %1010101 %1011101 %1011101 %1011101 %1011101 %0111110 %0001000 %0111110 %1011101 %1100011 %1111111 %1101011 %0111110 end player4: %000000 %000000 %000000 %000000 %000000 %011110 %111111 %111111 %111111 %011110 end player1pointerhi = player4pointerhi : player2pointerhi = player4pointerhi : player3pointerhi = player4pointerhi player1pointerlo = blank : player2pointerlo = blank : player3pointerlo = blank player1height = 6 : player2height = 6 : player3height = 6 : player4height = 6 _COLUP1 = $48 : COLUP2 = $48 : COLUP3 = $48 : COLUP4 = $48 player1y = 80 player2y = 60 player3y = 40 player4y = 20 rem k{0} explained later rem l=AUDF0 k{0}=1 : l=33 : player0y=110 goto start_game_2 start_game k=0 : l=0 : score=0 : m=0 j=2 rem m=score timer rem j=speed of tomatoes start_game_2 rem i=which tomato to get positions of for i = 0 to 3 gosub intialize_tomato next player0y=1 : player0x=20 main_game drawscreen if switchreset then i=0 : goto the_beginning if k{0} then goto player_dead if player0y<20 then player0y=player0y+1 : goto main_game if joy0up && player0y<80 then player0y=player0y+2 if joy0down && player0y>20 then player0y=player0y-2 rem m=scoretimer. if m>59 = one second. m=m+1 if m>59 then m=0 : score=score+1 rem controlling tomato 1's movement for i = 0 to 3 if a[i] then a[i] = a[i] - 1 else player1x[i] = player1x[i] - j : player1pointerlo[i] = show if player1x[i] < 10 then gosub intialize_tomato next rem k{0}=1 - you're dead , k{0}=0 - you're not dead. if collision(player1,player0) && !k{0} then l=20 : k{0}=1 player_dead rem if dead and l<32 then make a splat sound, else be silent if k{0} && l<32 then AUDV0=4 : AUDC0=1 : AUDF0=l : l=l+1 if k{0} && l>31 then AUDV0=0 : l=32 if k{0} && joy0fire then i=0 : goto start_game goto main_game intialize_tomato a[i] = rand / 4 : player1x[i] = 150 : player1pointerlo[i] = blank return vblank rem colors for the sprites and background. COLUBK=$BA : COLUP0=$2c return (I was messing with the code so sorry if it's messed up heh, heh)

I think Kiwi has got it. Try setting the player y positions and don't change them instead change the player colors

sorry what I should have said is you have a bug there but I don't know if that's related to your problem

I think you will have to give an example I don't understand what you are worried about repeating what sort of things do you want to do with nybbles? (some code would be nice) I think RT had bunch of this stuff but here you go rem to add something to the hi nybble of a rem shift it four places to the left by multiplying rem it by 16 rem increment the high nybble of a rem ie add 1 to the hi nybble a = a + 16 rem decrement the high nybble of a a = a - 16 rem add the lo nybble of b to the hi nybble of a a = b * 16 + a rem if you can't do the shifting first it's better rem to use a temp variable if you can or else bB rem starts messing with the stack to save intermediates rem subtract the lo nybble of b from the hi nybble of a temp1 = b * 16 a = a - temp1 rem use an XOR swap to set the lo nybble of a rem to the lo nybble of something else rem with out effecting the hi nybble of a rem the something else being temp1 here a = ((temp1 ^ a) & %11110000) ^ temp1 rem and use the parenthesis or else bB will mess with rem stack for intermediates rem do what ever in a temp variable then rem swap it back in to a rem increment the lo nybble of a temp1 = a + 1 a = (temp1 ^ a) & %11110000 ^ temp1 rem decrement the lo nybble of a temp1 = a - 1 a = (temp1 ^ a) & %11110000 ^ temp1 rem add lo nybble of b to lo nybble of a temp1 = a + b a = (temp1 ^ a) & %11110000 ^ temp1 rem to set the low nybble of a to the lo nybble of b a = (b ^ a) & %11110000 ^ b rem to set the hi nybble of a to the hi nybble rem of something else (temp1 in this case) a = (temp1 ^ a) & %00001111 ^ temp1 rem to set the hi nybble of a to the lo nybble rem of something else shift the something else 4 bits rem mask out the hi nybble of a and OR in the (shifted) rem lo nybble temp1 = b * 16 a = (a & %00001111) | temp1 you can put this stuff in macros and you don't have to use nybbles if could eg be the hi 5 bits and the lo 3 bits but the constants would change eg multiply by 8 for the 5 hi bits mask with %11111000 for the 5 hi bits or %00000111 for the lo 3 bits

(you may already know this) if you're going to add be sure the bit is zeroed first don't forget that some of the playfield bytes are reversed use rand16 sounds like you'll be calling rand a lot if you call rand some set number of times that's a factor of the cycle length it'll likely seem much less random

How about an example? Probably the simplest thing would be to use temp variables temp1 = nybble if temp1 then ..

I don't know what your problem is but .. if i>3 then player0y=0 : player0x=20 : goto main_game i=i+1 on i gosub first_one first_one second_one third_one fourth_one if i = 3 you're going to (try) to gosub to fifth_one player0x..player5x and player0y..player5y (and the letter variables) are in sequence in memory so you should be able to replace all that with (untested) rem i=which tomato to get positions of if i>2 then player0y=0 : player0x=20 : goto main_game i=i+1 e[i] = 0 : a[i] = rand player1x[i] = 150 : player1y[i] = 150 drawscreen goto start_game_2

Not sure exactly what you want But assuming you want to steer your player with the joystick and not be just left-right, up-down Two possibilities come to mind. Have a target you can steer (not necessarily visible) that you can steer in the usual way and have your object move towards that (something like missle command) Or have your movement follow a vector you can rotate and convert to dx and dy with a look up table (something like asteroids)