Like I guess that 127 is supposed to represent the value 1 and -127 as -1, but I don't know how I would make a conversion like that inside code.

Well... divide by 127 ?
Be sure though not to divide right after you made the (co)sine calculation or you'll always get 0 or 1 or -1. For example, if you have to do sin(a)*r, do sin(a)*r/127 and not sin(a)/127*r.
Also, if you don't care about losing a bit of precision, divide by 128 instead of 127. It is a less ugly number.

V/*127*5
/* = fixed-point division.

Else you can use subpixels! And for drawing: Pxl-on(x/128, y/128)

Precision: Subpixels is a method who lets for instance for each pixel 128 values to have some precision.

For instance sx = [0,127] corresponds to x=1, sx= [128,255] <=> x=2...
With this, you'll only have to divide sx and sy by 128 to have pixel coords. And what's great is that division is optimized by Axe!

If you want completely accurate precision that is very fast (at the cost of requiring more RAM), it might actually be more beneficial to store the following information about each bullet:
x coord
y coord
width
height
remainder
Each frame, you would do something like the following:
for(a=0,#ofbullets-1)
  call AdjustCoords
  pxl-change(x,y)
  x?buf(5*a)
  y?buf(5*a+1)
  w?buf(5*a+2)
  h?buf(5*a+3)
  r?buf(5*a+4)


AdjustCoords:
buf(5*a)?x
buf(5*a+1)?y
buf(5*a+2)?w
buf(5*a+3)?h
buf(5*a+4)?r

pxl-change(x,y)
if remainder >0
  x+1?x
  r-h?r
  return
If remainder=<0
  y+1?y
  r-w?r
  return
Essentially, it makes sure that the bullet stays as close to being on track as it can. If it moves too far in the x direction, it corrects by moving in the y direction. All the while, it adjusts the remainder (if remainder dips below 0, then we know it has moved too far off track and we need to adjust by moving in the y direction.

The pseudocode isn't perfect-- it only accounts for being able to move right or up. You will want to store the x and y directions of the bullets as well. The rest of the data is derived from:


initial (x,y) depends on where the bullet originates
initial (w,h) will remain constant and comes from subtracting the enemy objects coordinates from the bullet origin coordinates. If these are positive, then direction will be 1 for the given direction. If either is negative, direction needs to be set as -1 and then you need to make it positive with abs().
initial remainder should be set as w
Finally, (w,h) needs to be readjusted by multiplying them by 2.

(in non-integer arithmetic, we would just set initial remainder as w/2, but we would lose accuracy in integers if w was odd, so we just use w and then double width and height)


An increment, add/subtract and compare is much faster than computing arctangent, multiplying/dividing and using sin() or cos(). It also does not require inflated pixels, but it can work just fine with them, too. I have vague memories of doing something like this over the summer that got hundreds of bullets on screen at 6MHz. I'll try to find it and edit this post.


EDIT: Oh, it was actually an old topic that you posted in, but for a refresher: http://ourl.ca/19321/356834