# some movement code

Bresenham movement

32 replies to this topic

### #1 bogax OFFLINE

bogax

Dragonstomper

• 793 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

• Random Terrain , Gemintronic and RevEng like this

### #2 Random Terrain OFFLINE

Random Terrain

Visual batari Basic User

• 28,987 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
• 793 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

• Philsan likes this

### #4 Mountain King OFFLINE

Mountain King

Dragonstomper

• 691 posts

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 OFFLINE

Random Terrain

Visual batari Basic User

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

Posted Sat Mar 7, 2015 11:34 AM

Double post.

### #6 Random Terrain OFFLINE

Random Terrain

Visual batari Basic User

• 28,987 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 OFFLINE

Random Terrain

Visual batari Basic User

• 28,987 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
• 793 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

• Random Terrain likes this

### #9 Random Terrain OFFLINE

Random Terrain

Visual batari Basic User

• 28,987 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
• 793 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
• 793 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

• Random Terrain likes this

### #12 Random Terrain OFFLINE

Random Terrain

Visual batari Basic User

• 28,987 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
• 793 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 OFFLINE

Random Terrain

Visual batari Basic User

• 28,987 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:

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

### #15 bogax OFFLINE

bogax

Dragonstomper

• Topic Starter
• 793 posts

Posted Sun Mar 8, 2015 4:48 PM

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

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 OFFLINE

Random Terrain

Visual batari Basic User

• 28,987 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

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:

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
• 793 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 OFFLINE

Random Terrain

Visual batari Basic User

• 28,987 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:

### #19 Random Terrain OFFLINE

Random Terrain

Visual batari Basic User

• 28,987 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

• Philsan and RevEng like this

### #20 bogax OFFLINE

bogax

Dragonstomper

• Topic Starter
• 793 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

### #21 Random Terrain OFFLINE

Random Terrain

Visual batari Basic User

• 28,987 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

• 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
• 793 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)

• Mountain King likes this

### #24 Lillapojkenpćön OFFLINE

Lillapojkenpćön

Chopper Commander

• 195 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
• 793 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