Bullet controller in Shmup-game

[buzzybee]

After some constructive feedback to the last video of my forthcoming shmup RESHOOT PROXIMA 3, I decided to totally ditch the existing bullet control code and try something new; aim for code which allows much more control of bullet objects at launchtime.

As I am a mathematical dyslexic, I wonder if anyone wants to share some kind of algo. I will then use this algo to develop code which is able to

- launch an object towards a set position
- adjust precision
- adjust angle
- adjust speed

Object controller uses a 2d world with conventional x and y coords, x and y stored within longwords (upper 16 bits define worldcoord, lower 16 bits define subpixel coord). Efficiency rules, so no divs and muls at all; or only at launch.

Any suggestions much appreciated!

[phx]

The obvious answer would be "Bresenham", which works without any multiplications and divisions. But how were you doing it before?

In Black Strawberry Cake I'm using such aimed missiles in the world 2 boss fight (monster.asm/newAimedMissile). I'm using a lookup table with 64 entries in x- and y-direction with values between 0.0 and 1.0. The stored format is 1.7 bits, which is sufficient. So you only have to normalize your dx and dy, by shifting both values right at the same time, until both are less than 64. Then read the gradient from the table, which you can add in each step to the missile movement.

See also here: http://eab.abime.net/showpost.php?p=...5&postcount=14
...which includes the C source to generate the table.

[buzzybee]

Bresenham does not work for me, for the same reasons that you mention in your thread. So far I am using a forced vector approach, by calculating dx and dy first and do some simple bitshifts to get x- and y-acceleration at launch. These two values are just added to x- and y-coords the following frames, so hardly any extra calculation is needed. Works fine, but is not versatile at all; for example acceleration of bullets cannot be controlled. Maybe I have to re-visit my code.

I will also try the table approach, as it seems to work pretty well in your game. Thanks a lot!

[Auscoder]

Originally Posted by buzzybee

Bresenham does not work for me, for the same reasons that you mention in your thread. So far I am using a forced vector approach, by calculating dx and dy first and do some simple bitshifts to get x- and y-acceleration at launch. These two values are just added to x- and y-coords the following frames, so hardly any extra calculation is needed. Works fine, but is not versatile at all; for example acceleration of bullets cannot be controlled. Maybe I have to re-visit my code.

I will also try the table approach, as it seems to work pretty well in your game. Thanks a lot!

Hi Richard, I saw that feedback, pretty decent feedback too.

For the acceleration, you are able to fudge it along with the dx/dy approach. Since you are storing your coords in 32bit with upper 16 bits as world, and lower as remainder its even easier.

Caveat is that you would need to store your dx/dy along with each bullet object (so that each bullet can have its own current speed state) also in your same fixed point format.

When firing a bullet, copy the initial deltas to your bullet object, then each frame or whenever add your acceleration in the same fixed point format equally values to each of the dx/dy. Adding equally keeps the bullet firing straight in the existing direction. You can add with unequal values to increase/decrease the acceleration on either axis.

Psuedo would look something like:

    onShoot:
      bullet_deltax = tablex[index]
      bullet_deltay = tabley[index]

    for each frame:
      add.l bullet_deltax,bullet_posx
      add.l bullet_deltay,bullet_posy

      add.l acceleration,bullet_deltax
      add.l acceleration,bullet_deltay

Acceleration as 65536 would increase objects dx by 1 each frame with your fixed point format.
Acceleration as 32768 would increase objects dx by 1/2 pixel each frame...
and so forth. You are using pretty high precision so you have good control.

Of course in this you need to add.l not add.w because your format is 32bit.

I also use 32bit fixed point, its simple to swap, and deref each word separately. Wish there was a swap.w on 68k.

[buzzybee]

@Auscoder: Thank you for your input. It does work, in fact that´s what my code did already. Unfortunately, with this method, speed of bullets depends on spawn-target-distance, which is not desired.

@PHX: You inspired me to finally adress compiling c- and assembler-code using VASM. The makefile for compiling your C-code on Mac looks something like this:

gcc $AMIDEV/source/createBulletVectorTable.c -o $AMIDEV/source/bulletVectorTable.exe	#compile
chmod +x $AMIDEV/bulletVectorTable.exe	#is executable
$AMIDEV/bulletVectorTable.exe 64 $AMIDEV/bulletVectorTable #create table with [64] entries on x- and y-axis

Works perfectly. Only have to adapt it to the coordsystem used in rp3, and implement assembler code which reads the table. Thanks a lot!

[Tigerskunk]

Originally Posted by buzzybee

@Auscoder: Thank you for your input. It does work, in fact that´s what my code did already. Unfortunately, with this method, speed of bullets depends on spawn-target-distance, which is not desired.

Also you can do this a lot less complicated with simple bit shifts..

[Auscoder]

Originally Posted by buzzybee

@Auscoder: Thank you for your input. It does work, in fact that´s what my code did already. Unfortunately, with this method, speed of bullets depends on spawn-target-distance, which is not desired.

Yes great, normalized delta's are key here. I guess the table you are now generating is providing those to you. I will have to do this, as I am calculating normalized vector each time a tracking bullet spawns

[Auscoder]

Originally Posted by Steril707

Also you can do this a lot less complicated with simple bit shifts..

I find with shifting for speed/acceleration, its a bit too granular, good if you want 2x 4x steps etc, but for something finer fixed point works a treat for me.

[zero]

If you want to trade memory for speed then the fastest option is to use lookup tables. They have the additional advantage of being able to control accuracy.

You can just have a very simple bounded x/y relative lookup using low resolution coordinates, say 16x16 blocks because then you can avoid shifts.

[grond]

Originally Posted by Auscoder

I find with shifting for speed/acceleration, its a bit too granular, good if you want 2x 4x steps etc, but for something finer fixed point works a treat for me.

You can always do stuff like dx += dx>>2 for a mul*1.25 if you have enough post-point digits.

EDIT: I just realised that this is exactly what you were referring to. Sorry!

[buzzybee]

Quick update: I implemented the lookup table approach that phx suggested - thanks a lot for this, phx! The modified approach only eats up additional 8k, ends up with fast and versatile code, and works nicely. Sharing some thoughts and a short video on my Patreon-page. Feel free to read and have a look!

Will share code here as soon as I´ve cleaned it up a bit.

[Cyprian]

looks promising