stuck in a loop

[freehabitat]

Hello,...

 

bevor i got help with a color selection problem... it use a loop command to work...

 

now i tried to include it in my code and i have the feeling that loop stuck because my steering isn´t working anymore...

 

 

 set tv pal
set kernel_options pfcolors

const p0lo=#<playerL012_0

dim current_color = a
 current_color = 0

 c=$be

player0x=40 : player0y=40

 
main


scorecolor=$00
	COLUBK=$60
	COLUP0=c
	NUSIZ0=$07
	
drawscreen

rem	-player0 sprite-   

  player0:
  %11111111
  %11000011
  %11011011
  %11000011
  %11111111
end
  player0x = 80
  player0y = 44
loop
  COLUP0 = player0_color[current_color]
  drawscreen
  if joy0fire then current_color = current_color + 1
  if current_color = 5 then current_color = 0
  goto loop
  data player0_color
  $8C,$C0,$C4,$C8,$CC
end

 

 

how can i use this loop in the right way,... i really don´t understand well with subroutines/loops how to work...

i just know that the loop should run all the time beside the main code..

 

best,..

 

tom

frames.02_col.bas.bin

[SeaGtGruff]

The loop I showed you in the sample code was just an example. If you've already got a loop in your program, then you wouldn't want to just copy and paste my example into your program, because then you've got a loop within a loop, and that's (probably) not what you want. Take out "loop" and "goto loop," as well as the extra "drawscreen." You might also need to make other changes to make the sample code fit in with your existing program, such as changing the variable names, etc.

 

Michael

[freehabitat]

Take out "loop" and "goto loop," as well as the extra "drawscreen."

Michael

 

 

i thought the loop is essential for the pool of chosen colors... well,... wrong thougth!

 

 

anyway,... color changes work now,... just one 'little' problem left.

 

in my definition it shold be like that, if you press joy0fire the COLUP0 should become black. (thats the hide-mode)

 

but now i only have my choosen color pool.

 

i tried to set $00 as a const value, tried different things but only result was that the color changes to the first value

in my selection (data player0_color)

 

than i used $00 as the first color in my color pool but it´s also not a good deal.

 

 

how can i do that my playersprite becomes black unti next collision? i am little disapointet cause this are so little basic things i don´t know and i even

did not found anything compareable in other codes...

 

 

you can see a cutout of the code here, i just worked on player0:

 

 set tv pal
set kernel_options pfcolors

const p0lo=#<playerL018_0
const p1lo=#<playerL037_1

dim current_color_p0 = a
 current_color_p0 = 0

 v=40

 d=$ae

player0x=40 : player0y=40
player1x=110 : player1y=40

 
main


scorecolor=$00
	COLUBK=$00
COLUP0=player0_color[current_color_p0] 	
COLUP1=d
NUSIZ0=$07
NUSIZ1=$15

	
drawscreen


		

rem	-player0 sprite-   


player0: 
%11111111
%11111111
%11111111
%10000001
%10000001
%10000001

end


  
 
 x=0
 

 if joy0right then x=1
 if joy0left then x=255
 if joy0up then y=y-1
 if joy0down then y=y+1
 if joy0fire  then current_color_p0 = $00 

 rem	-player0 beam-

 if y=255 then y=87
 if y=88 then y=0
 if y<25 then player0pointerlo=p0lo+y : player0height=86 : player0y=87
 if y>24 then player0pointerlo=p0lo : player0height=24 : player0y=y

 if collision(player0,player1) then current_color_p0 = current_color_p0 + 1
 
 player0x=player0x+x
 
 if player0x=255 then player0x=159 : goto main 
 if player0x=160 then player0x=0 : goto main 

 if current_color_p0 = 6 then current_color_p0 = 0
 data player0_color
 $88,$8C,$C0,$C4,$C8,$CC
end

frames.02.bas

[SeaGtGruff]

I can help you change the code so the players alternate between black (after the fire buttons are pushed) or a color (after they collide with each other), but I'm not sure how the color cycling is supposed to fit into that. Are the players supposed to cycle through different colors when they aren't "invisible"? In your other poswt, I thought you said you wanted the colors to cycle each time a fire button was pushed?

 

Michael

[freehabitat]

well,.. it looks like this...

 

we have the pool with selected colors,.. they start to flicker if a collission happens.

 

if i press a fire button the playercolor should become black($00).... now the player is invisible.

.. anyway, if there is a collision the sprite began to change color very fast again,... if the collision is 'gone', the playercolor is constant that one,

what was selected at least in the colorpool.... until next collision or fire(invisible...)

 

it is not supposed to become visible by pressing fire again, you need to get in collision to become visible again.

 

 

it easy can be that i wrote something different befor,.. sometimes my concept is changeing during the work, i get new idears and that´s it..

 

 

hope that it is a better explaination of what i want.. thanx for your patient.

 

i´ll go to test my projections of the frame game in the foggy atmosphere now,.. i am so excited

 

i´ll let you know..

tom

[SeaGtGruff]

we have the pool with selected colors,.. they start to flicker if a collission happens.

 

if i press a fire button the playercolor should become black($00).... now the player is invisible.

.. anyway, if there is a collision the sprite began to change color very fast again,... if the collision is 'gone', the playercolor is constant that one,

what was selected at least in the colorpool.... until next collision or fire(invisible...)

 

it is not supposed to become visible by pressing fire again, you need to get in collision to become visible again.

Okay, I understand now. I'll post something later tonight after I've updated your code.

 

Michael

[freehabitat]

here you can see what i did : )

 

atari2600fog.mov

 

here you can see why i need to select a pool of colors,... it´s because of the contrast.!

 

so i am looking forward to finish that project soon thank you!

 

 

 

tom

[SeaGtGruff]

I modified the player0 color to work as you described, using the data array that defines a handful of colors that are to be cycled. I see you already have player1 working, or half working, but without an array (i.e., cycling between all 128 colors). If you want player1 to work like player0, just create another data array for player1's possible colors, make the first entry $00 for black, dim a variable for current_color_player1, and do the same thing with current_color_player1 as is done for current_color_player0.

 

By the way, I moved the player0 and player1 statements up toward the top of the code, so that adding more lines of code won't keep changing their bB line numbers-- at least, as long as you don't add any more lines of code *above* them.

 

Michael

frames.02.bas

frames.02.bas.bin

[freehabitat]

By the way, I moved the player0 and player1 statements up toward the top of the code, so that adding more lines of code won't keep changing their bB line numbers-- at least, as long as you don't add any more lines of code *above* them.

 

NICE, it was alway´s stupid to open the .asm file and look for the line number....

 

 

If you want player1 to work like player0, just create another data array for player1's possible colors, make the first entry $00 for black, dim a variable for current_color_player1, and do the same thing with current_color_player1 as is done for current_color_player0.

 

so far i am okay with setting everything for player1,... just one thing i do not understand is about the color black.

 

data player0_color

0,$88,$8C,$C0,$C4,$C8,$CC

 

why do you write only 0 at first? is 0 the same than $00 ? i don´t think so..

 

if i have $00 in my color array, it is possible that the playersprite is black after a collision, that´s not what i expect... this is what i imagine

but i testet with 3 colors in the array and it never become black ,.. that´s great but how does it come?

 

because of this?

dim current_color_p0 = a

current_color_p0 = 1

 

you set the value fom 0 to 1, is that the reason why it do not use black for the shown color array?

 

 

i will test this code next evening in my foggy camber : )

 

now i´ll think about how to get all the stuff on a nice cartridge, who is a good contact for that? can you recommend some one in this community?

 

 

 

Tom

[SeaGtGruff]

so far i am okay with setting everything for player1,... just one thing i do not understand is about the color black.

 

data player0_color

0,$88,$8C,$C0,$C4,$C8,$CC

 

why do you write only 0 at first? is 0 the same than $00 ? i don´t think so..

 

if i have $00 in my color array, it is possible that the playersprite is black after a collision, that´s not what i expect... this is what i imagine

but i testet with 3 colors in the array and it never become black ,.. that´s great but how does it come?

 

because of this?

dim current_color_p0 = a

current_color_p0 = 1

 

you set the value fom 0 to 1, is that the reason why it do not use black for the shown color array?

0 and $00 are the same-- just different number notations for the same value (zero):

 

0 = 0 in decimal notation

$00 = 0 in hexadecimal notation

%00000000 = 0 in binary notation

 

I actually did change it from 0 to $00 in the data statement, but I had already uploaded the source, so I didn't bother to upload it again since it's really the same thing.

 

Yes, I initialized current_color_p0 to 1 instead of 0, so the first color would skip the black value (0 or $00). Then, when a collision is occurring, I added 1 to current_color_p0. When the collision begins, if the frame was invisible (black), then current_color_p0 gets incremented from 0 to 1, so player0 changes from black to the first color. Then, as long as the collision is still occurring, current_color_p0 will continue to be incremented during each frame, switching to the next color in the cycle. Except, when current_color_p0 gets to 7, it is reset to 1 to begin repeating the color cycle, hence the color will never be black while a collision is occurring. If no collision is occurring, the color will stay set to whatever it was at the last moment of the collision. Or, if there's no collision and the fire button has been pressed, the color will go to black.

 

now i´ll think about how to get all the stuff on a nice cartridge, who is a good contact for that? can you recommend some one in this community?

You could contact Albert here at AtariAge.

 

Michael

[freehabitat]

fine,.... i understand now : ) much better than some weeks befor...

 

 

i´ll contact Albert later,... do i need to know any thing special how to prepair the .bin file? if i look at the .asm file, there is lot of mess inside what is

finally not for use, isn´t it?!

 

is there a tutorial about this, i haven´t found anything jet..

 

 

best,

 

tom

[SeaGtGruff]

i´ll contact Albert later,... do i need to know any thing special how to prepair the .bin file? if i look at the .asm file, there is lot of mess inside what is

finally not for use, isn´t it?!

Right now might not be the best time to ask him about this, as I think he is extremely busy this week working on the orders from the AtariAge store. I mean, you could always ask, but he might not be ready to take on anything new until after all of the orders have been filled. All he would need is the .bin file, assuming this is just for one cart for yourself. There are also other places that can create carts. I'm really not a very good source of information on this, though, because I've never had a cart made for myself.

 

is there a tutorial about this, i haven´t found anything jet..

I guess you could try searching the AtariAge forums, or Google, for something like "getting an atari 2600 cart made"-- or just scan through the list of topics in the homebrew and programming forums, since this topic comes up from time to time.

 

Michael

[freehabitat]

Hello,

 

i contact Al and he replied fast. He can help me burning the rom, ... jep !

 

these day i was testing the color array and thought about what else i should set befor

i finish my first project on atari.

 

well,.. here are 2 questions i have.

 

1) i tried to set both playersprites direct in the center of the screen,... the small in the large frame,.. center on center...

but i simply can´t. is it because of the code you used to steer the y-axis?!

 

this is not really for use,.. i tried different values but no result...

player0x=40 : player0y=40
player1x=110 : player1y=40

 

2) to use also the nice switches on the hardware i tried some things and found one helpfull feature.

i want to use the select switch for swapping the player_port. that mean player0 is the small frame and player1 the

large one. if i press switch again,.. everything is like befor.

shure,.. the usual way is to swap the controller but here it´s not that usual,.. i am using a interface for one joystic_port...

[freehabitat]

Hello,

 

i contact Al and he replied fast. He can help me burning the rom, ... jep !

 

these day i was testing the color array and thought about what else i should set befor

i finish my first project on atari.

 

well,.. here are 2 questions i have.

 

1) i tried to set both playersprites direct in the center of the screen,... the small in the large frame,.. center on center...

but i simply can´t. is it because of the code you used to steer the y-axis?!

 

this is not really for use,.. i tried different values but no result...

player0x=40 : player0y=40
player1x=110 : player1y=40

 

2) to use also the nice switches on the hardware i tried some things and found one helpfull feature.

i want to use the select switch for swapping the player_port. that mean player0 is the small frame and player1 the

large one. if i press switch again,.. everything is like befor. shure,.. the usual way is to swap the controller

but here it´s not that usual,.. i am using a interface for one joystic_port...

[freehabitat]

Hello,

 

i contact Al and he replied fast. He can help me burning the rom, ... jep !

 

these day i was testing the color array and thought about what else i should set befor

i finish my first project on atari.

 

well,.. here are 2 last questions i have.

 

1) i tried to set both playersprites direct in the center of the screen,... the small in the large frame,.. center on center...

but i simply can´t. is it because of the code you used to steer the y-axis?!

 

this is not really for use,.. i tried different values but no result...

player0x=40 : player0y=40
player1x=110 : player1y=40

 

on the other hand i found some strange visual effects by changeing some variables... this is for another time

 

 

2) to use also the nice switches on the hardware i tried some things and found one helpfull feature.

i want to use the select switch for swapping the player_port. that mean player0 is the small frame and player1 the

large one. if i press switch again,.. everything is like befor. shure,.. the usual way is to swap the controller

but here it´s not,.. i am using a interface for one joystic_port... so it would be great if i don´t need to change it´s place.

 

 

best,

Tom

[freehabitat]

Hello,

 

i contact Al and he replied fast. He can help me burning the rom, ... jep !

 

these day i was testing the color array and thought about what else i should set befor

i finish my first project on atari.

 

well,.. here are 2 last questions i have.

 

1) i tried to set both playersprites direct in the center of the screen,... the small in the large frame,.. center on center...

but i simply can´t. is it because of the code you used to steer the y-axis?!

 

this is not really for use,.. i tried different values but no result...

player0x=40 : player0y=40
player1x=110 : player1y=40

 

on the other hand i found some strange visual effects by changeing some variables... this is for another time

 

 

2) to use also the nice switches on the hardware i tried some things and found one helpfull feature.

i want to use the select switch for swapping the player_port. that mean player0 is the small frame and player1 the

large one. if i press switch again,.. everything is like befor. shure,.. the usual way is to swap the controller

but here it´s not,.. i am using a interface for one joystic_port... so it would be great if i don´t need to change it´s place.

 

 

best,

Tom

last.bas

[SeaGtGruff]

I'm not sure if this is what you wanted... By the way, it looked like you broke the code that turned the frame invisible if the fire button was pressed, so I fixed it back to the way it was before. If that wasn't what you wanted now, just put it back.

 

Michael

last.bas

last.bas.bin

[freehabitat]

...

Edited February 12, 2008 by freehabitat

[freehabitat]

By the way, it looked like you broke the code that turned the frame invisible if the fire button was pressed, so I fixed it back to the way it was before.

 

i postet only one of my test-files where i deleted the row,... i tried various constallations of using firebutton..

 

the code works fine now thanks... can you explain me this in little words?

 

  
  dim controller_p0 = c
  controller_p0 = 0
:
: 
  dim select_debounce = d
  select_debounce = 0
:
:

  if select_debounce <> 0 then select_debounce = select_debounce - 1 : goto main
  if switchselect then select_debounce = 12 : controller_p0 = controller_p0 ^ 1

 

 

ok,.. you dim 2 variables,.. but what is happening with them in this 2 lines??! i am really not sure with this function.

 

now i am trying to figure out how it works,... my example for today is to steer both sprites by switching the 'switchleftb'

with one joystick... i think it´s the same way to do like your example with the 'switchselect'...

 

now i tried some different codes,... i add two .bas versions of a simple code, only one player sprite to test the 'switchleftb' feature.

it works somehow but not perfect.... i am not shure how to say,

if ... gosub... DONT ...

 

well,...

 

  if controller_p0 = 0 then gosub joy0_p0 else gosub joy1_p0

  
  rem -player0 beam-

  if y=255 then y=87
  if y=88 then y=0
  if y<25 then player0pointerlo=p0lo+y : player0height=86 : player0y=87
  if y>24 then player0pointerlo=p0lo : player0height=24 : player0y=y

  player0x=player0x+x

  if player0x=255 then player0x=159 : goto main
  if player0x=160 then player0x=0 : goto main



  if switchreset then reboot

  if select_debounce <> 0 then select_debounce = select_debounce - 1 : goto main
  if switchselect then select_debounce = 12 : controller_p0 = controller_p0 ^ 1
  
  if !switchleftb then gosub joy_mix

  
  goto main


joy0_p0
  if joy0right then x=1
  if joy0left then x=255
  if joy0up then y=y-1
  if joy0down then y=y+1
  if joy0fire then current_color_p0 = current_color_p0 + 1 : if current_color_p0 = 5 then current_color_p0 = 1
  return

joy1_p0
  if joy1right then x=1
  if joy1left then x=255
  if joy1up then y=y-1
  if joy1down then y=y+1
  if joy1fire then current_color_p0 = current_color_p0 + 1 : if current_color_p0 = 5 then current_color_p0 = 1
  return
  
  
joy_mix
  if joy0right then x=1
  if joy0left then x=255
  if joy0up then y=y-1
  if joy0down then y=y+1
  if joy0fire then current_color_p0 = current_color_p0 + 1 : if current_color_p0 = 5 then current_color_p0 = 1
  if joy1right then x=1
  if joy1left then x=255
  if joy1up then y=y-1
  if joy1down then y=y+1
  if joy1fire then current_color_p0 = current_color_p0 + 1 : if current_color_p0 = 5 then current_color_p0 = 1
  return

 

 

whan i switch the 'switchleftb' it should gosub joy_mix (both controllers steers the same sprite) but the joy0_p0 or joy1_p0 is stil activ,..

how can i disable it in the case 'switchleftb' is activ?

 

this example here is for one sprite because it´s more complex for me to learn. later it should be able that i can steer with each of the joysticks both sprites

concurrent...

 

so i hope that i don´t bother you to much with all my 'new' idears... somehow it´s also a little complicated to explain exactl what i think to do..

 

anyway,... now i´ll go to electronic shop to buy some resistance and transistors,... hardware engineering this time

 

 

Thomas

1play_test.bas

1play_test_switchleft.bas

Edited February 12, 2008 by freehabitat

[freehabitat]

hello,..

i tried to get it runnig as i want, but the closest result is this .bas file.

 

somehow the up and down steering is in double speed whan i switch the switchleft , i don´t find out how can run only the joy_mix setting.

i think one of the other joy_*** definitions is still running...

so it is.. hope you have some time to look at this code..

 

best

TOM

1play_test_switchleft_02.bas

Edited February 15, 2008 by freehabitat

[SeaGtGruff]

can you explain me this in little words?

 

  
  dim controller_p0 = c
  controller_p0 = 0
:
: 
  dim select_debounce = d
  select_debounce = 0
:
:

  if select_debounce <> 0 then select_debounce = select_debounce - 1 : goto main
  if switchselect then select_debounce = 12 : controller_p0 = controller_p0 ^ 1

 

 

ok,.. you dim 2 variables,.. but what is happening with them in this 2 lines??! i am really not sure with this function.

A "debounce" variable is a way to have a short delay after pressing something (a console switch, joystick button, key on a keybord, etc.) before you recognize it as being pressed again. The computer is extremely fast at doing things, and even if you slow it down a little bit by letting it check on something only once every frame (i.e., once every 1/60 of a second on an NTSC Atari, or once every 1/50 of a second on a PAL or SECAM Atari), it can still check on that something several times between the time you start pressing down on the switch/button/key/etc., and the time you finally stop pressing down on it. For example, suppose you tell the Atari to increment the color value by 2 each time you press the fire button, and it takes you 1/10 of a second to press the fire button and then finish letting go of it-- then it would work as follows:

 

Color = 0

Begin pressing the button -- 0/60 of a second

Frame 1 -- 1/60 of a second -- Is fire pressed? Yes -- Color = color + 2 = 0 + 2 = 2

Frame 2 -- 2/60 of a second = 1/30 -- Is fire pressed? Yes -- Color = color + 2 = 2 + 2 = 4

Frame 3 -- 3/60 of a second = 1/20 -- Is fire pressed? Yes -- Color = color + 2 = 4 + 2 = 6

Frame 4 -- 4/60 of a second = 1/15 -- Is fire pressed? Yes -- Color = color + 2 = 6 + 2 = 8

Frame 5 -- 5/60 of a second = 1/12 -- Is fire pressed? Yes -- Color = color + 2 = 8 + 2 = 10

Frame 6 -- 6/60 of a second = 1/10 -- Finish letting go of fire button

Is fire pressed? -- Not anymore

 

So by the time you pressed the fire button and finished letting go of it, the color got incremented several times, and went from 0 to 10, instead of from 0 to just 2 as you might have expected.

 

With a debounce variable, you set the debounce counter to some delay value as soon as you start pressing the fire button (or console switch, or keyboard key, etc.). Then you let the counter decrement by -1 during each frame, until it reaches 0. As long as the debounce counter is greater than 0, it means you don't want the Atari to keep reacting to the fire button, because you're waiting a little bit to make sure you've had time to finish letting go of the fire button. But if the debounce counter is at 0, and the fire button is pressed, then you want to set the debounce counter (so it can start counting down), and react to the fire button.

 

Actually, I really should have coded the debounce logic a little bit differently, as follows:

 

   if !switchselect then select_debounce = 0 : goto main
  if select_debounce <> 0 then select_debounce = select_debounce - 1 : goto main
  select_debounce = 12 : controller_p0 = controller_p0 ^ 1

What this modified code does is check the select switch first. If it isn't pressed, then the debounce counter gets cleared, and you jump back to the beginning of the loop. Otherwise, the select switch must be pressed, but before you just react to it, you check the debounce counter. If it isn't 0, then the delay isn't over yet, so you go ahead and decrement the counter, then jump back to the beginning of the loop. Otherwise, the debounce counter must be 0-- and we've already determined that you must be pressing the select switch-- so it's okay to set the debounce counter to 12 (or whatever value you want to use for the delay time period), and then do whatever it is you want to do when the switch has been pressed.

 

As for the last part-- "controller_p0 = controller_p0 ^ 1"-- it will make the controller_p0 variable flip back and forth from 0 to 1 to 0 to 1 to 0, etc. (In batari Basic, "^" means "exclusive or," like the "EOR" command in assembly.)

 

Michael

[freehabitat]

that is a helpfull feature with the delay function,.. i needet this for my color test code,.. colors alway´s changed to fast to

whan i switched them by pressing a button : ) nice feature...

 

anyway,... i am still working with the switchleftb... i can not exclude the other joy0_setting whan i have run the joy_mix...

 

but it´s late now and i am tired,... i will continue tomorrow and post my result...

 

hopefully i can check it off soon.

 

 

good night

Tom

[SeaGtGruff]

my example for today is to steer both sprites by switching the 'switchleftb'

with one joystick...

I don't understand what you're trying to do in your new listing, so I took the last one I'd posted, and have updated it to use the left difficulty switch as follows:

 

If it's set to "a," then each joystick controls one sprite, with the select switch also having an effect. Or if it's set to "b," then both joysticks control the same sprite, again with the select switch having an effect. In other words:

 

left difficulty = a

joy0 controls player0, joy1 controls player1

press select-- joy0 controls player1, joy1 controls player0

press select again-- joy0 controls player0 again, joy1 controls player1 again

 

left difficulty = b

joy0 controls player0, joy1 also controls player0

press select-- joy0 controls player1, joy1 also controls player1

press select again-- joy0 controls player0 again, joy1 also controls player0 again

 

Michael

 

Edit: Ick, I didn't realize until I'd already posted that I actually did the opposite of what you said you wanted... control one sprite with two joysticks, rather than control two sprites with one joystick. Oh, well...

last.bas

last.bas.bin

Edited February 16, 2008 by SeaGtGruff

[freehabitat]

Ick, I didn't realize until I'd already posted that I actually did the opposite of what you said you wanted... control one sprite with two joysticks, rather than control two sprites with one joystick. Oh, well...

 

 

i am so sorry,.. explaining thoughts is really not one of my strong abilities

the correction you did is really that what i thought! nice...

 

i see,.. you made a pre-selection of the controoling settings,.. isn´t it?!

 

one thing, i try to explain...

 

if switchleft = B and switchselect(true)

now i can steer both sprites with both controllers (simultane) that´s what i want!

 

if switchleft = A and switchselect(false)

now i can do nothing but it should be like above.

 

i will try to solve it and post ig if i was successfull... if not would be great to get your help!

 

tom

last.corr.bas

last.corr.bas.bin

[SeaGtGruff]

if switchleft = B and switchselect(true)

now i can steer both sprites with both controllers (simultane) that´s what i want!

I'm not sure if I understand, so tell me if I'm wrong...

 

You want joy0 to control both player0 and player1 at the same time, and you also want joy1 to control both player0 and player1 at the same time. Is that correct?

 

if switchleft = A and switchselect(false)

now i can do nothing but it should be like above.

If I understood you correctly above, then select shouldn't do anything while both controllers are moving both sprites. I've made that adjustment.

 

I also noticed that the y coordinate had some problems when it's being moved twice as fast (if both controllers are pushing up or down at the same time)-- the frame was disappearing-- so I fixed that. But there's also a possible problem with the x coordinates (depending on how you look at it-- you might also think of it as a "feature"). If both controllers are pushed in the same x direction, the frames move at regular speed, instead of at doubled speed. If both controllers are pushed in the opposite x directions, the frames move in opposite directions, instead of being at a standstill. This is because you're using the same variable (x) for both sprites. I'm leaving it as is for now, because I'm not sure whether you like this behavior or not. And there seems to be a slight problem with the x and y coordinates when both controllers are pushed in the same diagonal direction, causing the two frames to slip a little bit out of alignment each time they wraparound the screen. I still haven't figured that out yet.

 

Michael

last.corr.bas

last.corr.bas.bin