Jump to content

Photo

some movement code

Bresenham movement

30 replies to this topic

#1 bogax OFFLINE  

bogax

    Dragonstomper

  • 718 posts

Posted Mon Mar 2, 2015 9:06 PM

 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)
 

Attached Files



#2 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 28,238 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Mon Mar 2, 2015 10:42 PM

Is that basically the same as this?
_

   if player1y < player0y then player1y = player1y + 1
   if player1y > player0y then player1y = player1y - 1
   if player1x < player0x then player1x = player1x + 1
   if player1x > player0x then player1x = player1x - 1


#3 bogax OFFLINE  

bogax

    Dragonstomper

  • Topic Starter
  • 718 posts

Posted Thu Mar 5, 2015 10:14 PM

 

Is that basically the same as this?
_

   if player1y < player0y then player1y = player1y + 1
   if player1y > player0y then player1y = player1y - 1
   if player1x < player0x then player1x = player1x + 1
   if player1x > player0x then player1x = player1x - 1

 

here you can compare the two

Attached Files



#4 Mountain King OFFLINE  

Mountain King

    Dragonstomper

  • 618 posts
  • Location:Philadelphia, PA

Posted Thu Mar 5, 2015 11:02 PM

This is really cool. I think I still need to wrap my head around it and find an application for it.  But I like it a lot.



#5 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 28,238 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Sat Mar 7, 2015 11:34 AM

Double post.



#6 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 28,238 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Sat Mar 7, 2015 11:35 AM

here you can compare the two


Thanks. That's a big difference. I've been trying to simulate it without using data and I can get close, but there is always something off and I end up using too much code anyway, so I might as well just adapt the code you posted.



#7 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 28,238 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Sat Mar 7, 2015 3:49 PM

What does the variable alias "ea" stand for in the code?

Also, is there a way to make this work if the target moves using the joystick? Or does it always have to be a stationary target?

#8 bogax OFFLINE  

bogax

    Dragonstomper

  • Topic Starter
  • 718 posts

Posted Sat Mar 7, 2015 8:55 PM

 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   
 

Attached Files



#9 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 28,238 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Sat Mar 7, 2015 9:06 PM

Thanks. That looks nice and smooth. I'll start adapting this latest code. When I get done, I'll put an example program on the bB page and link back to this thread for people who want more info.



#10 bogax OFFLINE  

bogax

    Dragonstomper

  • Topic Starter
  • 718 posts

Posted Sat Mar 7, 2015 9:40 PM

if you just leave player1 sitting you'll see player0

sometimes misses



#11 bogax OFFLINE  

bogax

    Dragonstomper

  • Topic Starter
  • 718 posts

Posted Sun Mar 8, 2015 10:43 AM

 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
 

 

Attached Files



#12 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 28,238 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Sun Mar 8, 2015 2:23 PM

Does "gosub set_ea" have to come after "gosub setup_move" in the line below?
_

if collision(player0, player1) then gosub P0_rand : gosub setup_move : gosub set_ea : goto s2

_
Would it still work OK if they are switched like in the example below?
_

if collision(player0, player1) then gosub P0_rand : gosub set_ea : gosub setup_move : goto s2

_



#13 bogax OFFLINE  

bogax

    Dragonstomper

  • Topic Starter
  • 718 posts

Posted Sun Mar 8, 2015 3:10 PM

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


Edited by bogax, Sun Mar 8, 2015 3:16 PM.


#14 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 28,238 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Sun Mar 8, 2015 3:53 PM

setup_move has to come first . . .


Thanks. Here is the first draft:

Attached File  ex_bresenham_movement_2015y_03m_08d_1746t.bas   11.21KB   82 downloads

Attached File  ex_bresenham_movement_2015y_03m_08d_1746t.bin   4KB   93 downloads


If you think it looks OK, I'll put it on the bB page.

#15 bogax OFFLINE  

bogax

    Dragonstomper

  • Topic Starter
  • 718 posts

Posted Sun Mar 8, 2015 4:48 PM

 I suppose you think that's easier to understand than my code :P

 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) 

 

#16 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 28,238 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Sun Mar 8, 2015 7:13 PM

I suppose you think that's easier to understand than my code :P


I've been going back to update the example programs on the bB page (I think I'm about halfway done) and I'm trying to make all of the code semi-consistent. Same for any new programs I'll be adding. Some people hate the comments with a passion, but at least it helps me remember what does what and why. People who hate the comments can use a program like Notepad++ and do a quick find and replace to get rid of them.


 

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)


Wow! I'm glad you caught that.


 

2) you should test for the limits and then skip the move
rather than make the move and try to undo it


I knew how to do that for the player, but my brain stopped working and I couldn't figure out how to handle it when x can go left or right and y and go up or down. I just updated the code. This seems to work:
 _
   temp1 = _error_accumulator

   if _octant{0} then goto __Skip_Chase1
   if player0y >= _Edge_Top && player0y <= _Edge_Bottom then player0y = player0y + _Data_yinc[_octant]
   _error_accumulator = _error_accumulator - _delta_x
   if temp1 >= _error_accumulator then goto __Skip_Chase2
   _error_accumulator = _error_accumulator + _delta_y
   if player0x >= _Edge_Left && player0x <= _Edge_Right then player0x = player0x + _Data_xinc[_octant]

   goto __Skip_Chase2

__Skip_Chase1

   if player0x >= _Edge_Left && player0x <= _Edge_Right then player0x = player0x + _Data_xinc[_octant]
   _error_accumulator = _error_accumulator - _delta_y
   if temp1 >= _error_accumulator then goto __Skip_Chase2
   _error_accumulator = _error_accumulator + _delta_x
   if player0y >= _Edge_Top && player0y <= _Edge_Bottom then player0y = player0y + _Data_yinc[_octant] 

__Skip_Chase2

 


 

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)


Thanks. I just got rid of it.


Here is the updated code and .bin:

Attached File  ex_bresenham_movement_2015y_03m_08d_2110t.bas   11.63KB   96 downloads

Attached File  ex_bresenham_movement_2015y_03m_08d_2110t.bin   4KB   102 downloads

If you get a chance and feel like it, maybe you can expand on what each line of your code in the file above does so I can add it to the program. If you don't feel like it, no problem.

#17 bogax OFFLINE  

bogax

    Dragonstomper

  • Topic Starter
  • 718 posts

Posted Sun Mar 8, 2015 9:08 PM

 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

 



#18 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 28,238 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Sun Mar 8, 2015 9:31 PM

OK, thanks. I put that code back the way it was:

 

Attached File  ex_bresenham_movement_2015y_03m_08d_2330t.bas   11.35KB   107 downloads

 

Attached File  ex_bresenham_movement_2015y_03m_08d_2330t.bin   4KB   103 downloads



#19 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 28,238 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Mon Mar 9, 2015 2:08 PM

It's on the bB page now:

randomterrain.com/atari-2600-memories-batari-basic-commands.html#ex_smooth_chase



#20 bogax OFFLINE  

bogax

    Dragonstomper

  • Topic Starter
  • 718 posts

Posted Tue Mar 10, 2015 4:43 AM

 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
 

Attached Files



#21 Random Terrain ONLINE  

Random Terrain

    Visual batari Basic User

  • 28,238 posts
  • Controlled Randomness
    Replay Value
    Nonlinear
  • Location:North Carolina (USA)

Posted Tue Mar 10, 2015 7:14 PM

Thanks. I updated the code on the bB page.



#22 Missile-Commander OFFLINE  

Missile-Commander

    Space Invader

  • 11 posts

Posted Fri May 22, 2015 1:18 PM

Hey there, I'm curious. Is there a way to make the Bresenham movement only reversed? Instead of being chased by the dot, the dot trying to get away from you? 

 

If so, I could certainly use some help figuring out how to do that. 



#23 bogax OFFLINE  

bogax

    Dragonstomper

  • Topic Starter
  • 718 posts

Posted Fri May 22, 2015 5:50 PM

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)


#24 Lillapojkenpćön OFFLINE  

Lillapojkenpćön

    Space Invader

  • 40 posts

Posted Mon Nov 13, 2017 5:54 AM

Does this and other line algorithms require the data tables? I would really like to shoot in a straight line like i can do with this, but with smoother 8.8 type X & Y variables, is it possible?



#25 bogax OFFLINE  

bogax

    Dragonstomper

  • Topic Starter
  • 718 posts

Posted Mon Nov 13, 2017 3:59 PM

Does this and other line algorithms require the data tables? I would really like to shoot in a straight line like i can do with this, but with smoother 8.8 type X & Y variables, is it possible?

 

how will you aim?

 

no, you don't need tables

 

I doubt 8.8 variable will get you anything

8 bits should be enough for the maximum

screen resolution

 

it will depend on how you aim (I think)


Edited by bogax, Mon Nov 13, 2017 4:12 PM.





0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users