This page is a mirror of Tepples' nesdev forum mirror (URL TBD).

# Diagonal movement with arbitrary angle

Hi,

So in my game, there's an object that can move diagonally. But the angle is not always 45 degree. It can vary depending on the position of the object's target. I don't have a clue as to how I can do this on NES. I can do it easily on other engines like Unity 3D or Cocos. AFAIK, it's because we can't just use a vector like other game engine, right? Since floats are not exactly supported. So how do I do this?

"Normally," (that is, with higher-powered computers) you'd normalize the difference vector and multiply by your desired speed […or have someone's modules do it for you]. However, normalizing a vector requires finding the magnitude, which requires squaring [multiplication] and square roots, and division. All of those are abysmally slow on 6502.

Castlevania II has a good solution, involving a table lookup after shifting the X- and Y- differences down equally, and using them as an index. I can't find the topic here where we discussed it.

Here's another topic discussing trying to shoot at a player.

edit: and here's another topic about 6502 trigonometry.
Floats are not supported, but q8 fixed-point is.

Aiming a projectile isn't that slow, maybe about 700 cycles at most: one atan2 and two multiplies. Firing one projectile a frame won't contribute that much to slowdown. And even if you're looking for homing missile behavior on 8 different objects, you can have only one per frame adjust its heading.
To move in something other than a 45 degree angle, you have to move going less than one pixel per frame on an axis. I assume you have some sort of variable for x and y velocity? What you'd do, is add it to the variable for the object's position every frame. The object's position (and velocity) variable should not be measured in pixels, but fractions of pixels. When it's time to display the sprites, you'd only take the bits from the object's position variable that represent whole pixels. How you plan on setting this all up is up to you.

If you want to figure out how to calculate the x and y velocity, you don't. Instead, you have a precalculated table that list different values for each degree. The only need one table, as the values for y are the values for x, just backwards.
If you aim by time rather than direction, you can use efficient power-of-two timings.

For example, if you want a projectile to hit a certain point in 64 frames (~1 second):

velocity = (target - position) / 64

This produces a velocity that will move "position" to "target" over 64 frames. A division by 64 of course can be done with 6 right shifts (and as mentioned above, "fixed point" is an important concept for precision to store those 6 sub-pixel bits).
What tepples said; fixed-point. There tends to be a lot of tutorials that are c64 oriented, but since it's basically the same processor - so you can use them. Also look up the fast mul for 65x. It's about a 2k table in rom (you'll know it when you see it described as (x^2)/4 in the f(x)). It's pretty quick, and should easily allow 16bit:16bit multiplication (as in 32bit * 32bit -> 32bit) should you need it. I mean, however you want to set the fixed point precision point (byte segmented for faster usage). As far as angle, a 0 to 90 degree (or whatever point system you pre-calculate) look up table should work (just invert whatever axis for the other coordinate planes).
one way

determine your deltas dx, dy and what their signs are
decide which has the larger magnitude
develope an index using the signs and which has the larger magnitude
ie three bits two for signs and one for x or y having the larger magnitude
that will define the octant you're moving in and can be used to look up increments
you always move in the direction with the larger magnitude
you'll keep an error accumulator, ea which gets intialized to the greater magnitude
say dy is the greater and dx is the lesser
you'd intialize the ea to dy

take a step in the y direction and subtract dx from the ea
if the ea goes through zero ie if ea is greater after you subtract
you've accumulated y worth of x's and it's time to take a step in x and add dy back into the ea

here's some batari basic code and an excerpt from the asm code it produces

in bB

f{0} = 0

sets bit 0 in variable f to 0

edit: var36 =f is some cruft, ignore it

Code:

move
temp1 = ea

if f{0} then skip
player0y = player0y + yinc[f]
ea = ea - dx
if temp1 < ea then ea = ea + dy : player0x = player0x + xinc[f]
return
skip
player0x = player0x + xinc[f]
ea = ea - dy
if temp1 < ea then ea = ea + dx : player0y = player0y + yinc[f]
return

setup_move
if x0 < x1 then f{2} = 1 : dx = x1 - x0 else f{2} = 0 : dx = x0 - x1
if y0 < y1 then f{1} = 1 : dy = y1 - y0 else f{1} = 0 : dy = y0 - y1

if dx > dy then f{0} = 1 : ea = dx else f{0} = 0 : ea = dy
var36 = f
return

data yinc
\$FF, \$FF, \$01, \$01, \$FF, \$FF,\$01, \$01
end

data xinc
\$FF, \$FF, \$FF, \$FF, \$01, \$01, \$01, \$01
end

.move
; move

.L08 ;  temp1  =  ea

LDA ea
STA temp1
.
;

.L09 ;  if f{0} then skip

LDA f
LSR
bcs .skip
.L010 ;  player0y  =  player0y  +  yinc[f]

LDA player0y
LDX f
CLC
STA player0y
.L011 ;  ea  =  ea  -  dx

LDA ea
SEC
SBC dx
STA ea
.L012 ;  if temp1  <  ea then ea  =  ea  +  dy  :  player0x  =  player0x  +  xinc[f]

LDA temp1
CMP ea
BCS .skipL012
.condpart0
LDA ea
CLC
STA ea
LDA player0x
LDX f
CLC
STA player0x
.skipL012
.L013 ;  return

RTS
.skip
; skip

.L014 ;  player0x  =  player0x  +  xinc[f]

LDA player0x
LDX f
CLC
STA player0x
.L015 ;  ea  =  ea  -  dy

LDA ea
SEC
SBC dy
STA ea
.L016 ;  if temp1  <  ea then ea  =  ea  +  dx  :  player0y  =  player0y  +  yinc[f]

LDA temp1
CMP ea
BCS .skipL016
.condpart1
LDA ea
CLC
STA ea
LDA player0y
LDX f
CLC
STA player0y
.skipL016
.L017 ;  return

RTS
.
;

.
;

.
;

.setup_move
; setup_move

.L018 ;  if x0  <  x1 then f{2}  =  1  :  dx  =  x1  -  x0 else f{2}  =  0  :  dx  =  x0  -  x1

LDA x0
CMP x1
BCS .skipL018
.condpart2
LDA f
ORA #4
STA f
LDA x1
SEC
SBC x0
STA dx
jmp .skipelse0
.skipL018
LDA f
AND #251
STA f
LDA x0
SEC
SBC x1
STA dx
.skipelse0
.L019 ;  if y0  <  y1 then f{1}  =  1  :  dy  =  y1  -  y0 else f{1}  =  0  :  dy  =  y0  -  y1

LDA y0
CMP y1
BCS .skipL019
.condpart3
LDA f
ORA #2
STA f
LDA y1
SEC
SBC y0
STA dy
jmp .skipelse1
.skipL019
LDA f
AND #253
STA f
LDA y0
SEC
SBC y1
STA dy
.skipelse1
.
;

.L020 ;  if dx  >  dy then f{0}  =  1  :  ea  =  dx else f{0}  =  0  :  ea  =  dy

LDA dy
CMP dx
BCS .skipL020
.condpart4
LDA f
ORA #1
STA f
LDA dx
STA ea
jmp .skipelse2
.skipL020
LDA f
AND #254
STA f
LDA dy
STA ea
.skipelse2
.L021 ;  var36  =  f

LDA f
STA var36
.L022 ;  return

RTS
.
;

.L023 ;  data yinc

yinc
.byte   \$FF, \$FF, \$01, \$01, \$FF, \$FF,\$01, \$01

.skipL023
.
;

.L024 ;  data xinc

xinc
.byte   \$FF, \$FF, \$FF, \$FF, \$01, \$01, \$01, \$01

.skipL024
.
;
Thanks for the replies guys. This is too many information to chug at once, lol. A good thing though, since I have lots of ways to do it now. I have a question though. If I were to use the lookup table, won't it cost to much memory? I mean I need 90 bytes to store all 90 degrees values, right?
Many games use brads, binary fractions of a turn such as 1/32 or 1/256, instead of degrees or radians. In a 32-step system such as that used in Thwaite, 0 to 31 represent 0 to 31/32*360 = 348.75 degrees in 1/32*360 = 11.25 degree steps.