Sprite won't move

[accousticguitar]

I just started using batari Basic a short time ago and I can't seem to get a sprite to move on its own. I want it to move diagonally and then ricochet off a playfield wall kind of like a pong ball would do. Here is the code I am using that isn't working. Also, will I have to repeat the moveupandright movedownandleft etc each time for all the objects I want to move on their own?

 

    dim  player1Dir=a
    dim  player2Dir=b
    dim  player3Dir=c  
    dim  player4Dir=d
    dim  player5Dir=e     
    dim  missile0Dir=f     
    dim  missile1Dir=g
    dim  ballDir=h    
    

MovePlayer1
if player1Dir = 10 then gosub moveupandright
if player1Dir = 20 then gosub movedownandright
if player1Dir = 30 then gosub movedownandleft
if player1Dir = 40 then gosub moveupandleft

if collision(player1,playfield) then player1Dir=player1Dir+10
if player1Dir < 10 then player1Dir=10
if player1Dir > 40 then player1Dir=10

MovePlayer2


MovePlayer3


MovePlayer4


MovePlayer5


MoveMissile0


MoveMissile1


MoveBall


 

  goto main

moveupandright 
player1x = player1x + 1
player1y = player1y + 1
return


moveupandleft
player1x = player1x - 1
player1y = player1y + 1
return


movedownandright
player1x = player1x + 1
player1y = player1y - 1
return


movedownandleft
player1x = player1x - 1
player1y = player1y - 1
return

[SeaGtGruff]

I just started using batari Basic a short time ago and I can't seem to get a sprite to move on its own. I want it to move diagonally and then ricochet off a playfield wall kind of like a pong ball would do. Here is the code I am using that isn't working.

I didn't have any trouble getting your code to work after adding a few lines, so it was okay except for a few things that were missing. But I don't know if you're missing them in your actual code, or if you just deleted them from your post because you were trying to show just the lines that relate to the sprite moving.

 

Here's what I added:

 

(1) Drew a box around the screen with the playfield.

(2) Drew a ball with player1.

(3) Set the screen colors (background, playfield, and player1). Note that player1's color must be set inside the loop.

(4) Initialized player1's x and y positions, as well as its direction.

(5) Added the label for where the main loop begins.

(6) Added the drawscreen command inside the main loop.

 

Also, will I have to repeat the moveupandright movedownandleft etc each time for all the objects I want to move on their own?

The way your code is written, and the way batari Basic's system variables are defined-- yes, you will. But if you rewrite your code a bit, and customize the batari Basic header file so the different x and y variables are declared together in the correct order, then I think you should be able to use one set of subroutines to move all of the objects, by using arrays and passing the number of the object you want to move. For now, I'd suggest you just use separate move subroutines and separate ifs for each object. If you need to optimize your code later to reduce ROM, then you can worry about how to squeeze the code down-- but don't worry about it yet until (or unless) it becomes a problem.

 

Michael

Sprite_won__t_move.bas

Sprite_won__t_move.bas.bin

[SeaGtGruff]

By the way, the ball bounces fine when it hits some walls in a certain direction, but it bounces with a "jerky" motion when it hits some of the walls in a particular direction. I haven't tried to debug the exact reason(s) why yet, or how to fix it.

 

Michael

[accousticguitar]

Thanks for the help! I guess I should have posted the whole file instead of just the part I was having trouble with. The only thing I could find on your list that I didn't do was setting direction for player1. I tried adding that in but it didn't seem to make a difference. After that I changed a bunch of stuff to try to order things more like you did but then my player0 sprite wouldn't move. So, I guess I'll post the original file in hopes that something simple can be found there. Thanks again!

 

Trial010.txt

[SeaGtGruff]

It looks like you've got multiple problems.

 

The reason player1 won't move is because you're setting the initial positions of the sprites inside the main loop, so even if they move, they just keep getting reset back to their starting locations.

 

For the multisprite kernel, you need to put an underscore in front of COLUP1 (_COLUP1).

 

You should do the drawscreen after you move the sprites, but before you check for collisions.

 

I fixed those errors, and maybe a few others. I forget everything I changed around, but I'm posting the revised code so you can look at it.

 

Even after fixing those problems, player1 vanishes when it gets to the top of the screen, so it never bounces back-- then it eventually reappears at the sides, and at the bottom, but it's outside the playfield box.

 

At first I thought it was because of the flickering that bB uses to get the additional players in the multisprite kernel-- that maybe player1 doesn't reappear until after it's collided with the playfield, and then it gets stuck or goes flaky.

 

But then I realized that it's something more basic than that.

 

In the multisprite kernel, players 1 through 5 can only be drawn to a certain vertical position on the screen-- I forget the exact y position-- and then they disappear. So player1 is disappearing before it can collide with the screen, not because of the flickering, but because of the value of its y position.

 

Probably what you should do is forget about using the playfield collisions to change the direction of player1, and switch to using its x and y coordinates to detect when it's reached the boundaries (i.e., the playfield). In other words, if player1y is greater than some number, then add 10 to player1Dir as if it collided with the playfield. I've added a line just before the collision checking to bounce player1 back if player1y is greater than 83, which seems to have fixed that problem. But I'd suggest doing the same thing with the other sides, and I'll have to fiddle around with player1y and player1x to find the right values to use.

 

Also, player1 is bouncing funny sometimes, as I described in my first reply-- it jerks around. It looks like the simple "add 10" technique isn't quite sophisticated enough. I can't look at it any more right now, because I have to go to bed; but maybe you can figure out something by looking at the revised code.

 

Michael

Trial010a.bas

Trial010a.bas.bin

[accousticguitar]

Wow, I didn't expect an answer at this late hour. Thank you for all the help! I guess it's obvious that this is my first attempt at batari Basic. I was thinking the same thing about the add 10 technique. I didn't anticipate balls bouncing in a figure 8 pattern. When I saw that I figured using x and y coordinates would probably work out better. That is far out that player1 is disappearing due to it's y position. I never would have guessed. I'll work on it some more tomorrow. Thanks again!

[SeaGtGruff]

That is far out that player1 is disappearing due to it's y position. I never would have guessed.

That's something I discovered while helping someone else with a multisprite-kernel game. There are differences between the x and y positioning of player0 versus the x and y positioning of players 1 through 5. And the players vanish if their y positions are too high (and maybe too low as well). I'll play around after work to see if I can refresh my memory about it, and post the results.

 

Michael

[accousticguitar]

I have player1 bouncing nicely now, but player0 won't move with the joystick. The collision detection for player0 apparently doesn't work either since player1 will pass right over player0 with no effect. I will search the forums for "multisprite kernel" and see if I can find anything.

Edited June 17, 2009 by accousticguitar

[accousticguitar]

Okay, I got player0 to move. Now I need to work on the collision detection.

Edited June 17, 2009 by accousticguitar

[SeaGtGruff]

Okay, I got player0 to move. Now I need to work on the collision detection.

One thing I noticed in the code you posted last night is that (if I remember correctly) you were just looping back to main if player0 and player1 collided. So I'm not sure what would actually happen in they collide, or rather, what you want to have happen when they collide.

 

Michael

[accousticguitar]

I just want the game to stop (for now anyway). I figured out what was wrong. I just had things in the wrong order. Now I need to make the other sprites move. That will take some time.

 

DoBas022.bas

 

DoBas022.bin

[accousticguitar]

Well, I don't think there is much more I can do with this. All of the objects are moving, although one of the missiles mysteriously changes width from time to time. Does anybody have any ideas on that?

 

DoBas033.bas

 

DoBas033.bin

[RevEng]

It's missile1, and when it's passing one of the virtual sprites (the last one drawn on the scanline, I think) it's sometimes taking on that virtual sprite's NUSIZ#, which is zero.

 

If you change your NUSIZ settings after "main" to...

 

NUSIZ0=$20

NUSIZ1=$20

_NUSIZ1=$20

NUSIZ2=$20

NUSIZ3=$20

NUSIZ4=$20

NUSIZ5=$20

 

...your shape-shifting missile1 goes away.

Edited June 19, 2009 by RevEng

[accousticguitar]

That works great, thanks!

[Impaler_26]

Very nice! So are you going to make a 2600 version of Dodge It out of this?

Edited June 19, 2009 by Impaler_26

[accousticguitar]

I'm working on it.