Hi

I'm coding a small game for a system that features a 6502 compatible cpu, and though my question isn't limited to the specifics of the cpu itself I was kind of hoping you guys could help me out anyway.

I have a cannon in the centre of the display and an aim that rotates 360deg around it, my problem is that I can't quite figure out a smart way to make the bullet fly from the cannon in the direction of the aim. I was playing around with linedrawing routines, but they eat a bunch of cycles and seems to be rather a hassle. It would also be great if one didn't have to use signed numbers at all. Any ideas how one could either use precalculated tables for this task or some other smooth method?

Sorry for my ignorance.
_nu

nu,

What screen resolution are you taling about here? Also, what increment of angles are you looking for, 1 deg, 5 deg, .1 deg?

Daryl

Hi 8bit.

Screenres is at 320*200, and I suppose I'm going at 1 deg.

_nu

It can be done with simple math using a lookup table.

Your table would hold the x offset and y offset for each angle.

You add the offset to the current position and plot the new position.

You use 16 bit math, using the upper byte as the whole number (position)and the lower byte as the fractional offset. Use bit 7 of the offset to determine if you are to add or subtract the 7 bit offset from the current position. Add the center location (x=160, y=100) to your position value to get the actual screen coordinates.

You then plot the postion, step thru the math, redraw and test for the edge of screen <0 or >160 (>100 in the y direction)

Your table could also contain a step counter that would eliminate the edge detection by precalculating the number of steps needed to reach the edge.

Use a spreadsheet to calculate the sine and cosine of each angle to generate the offsets for your table.

This should get you started.

Daryl

Hi again.

I've gone through your idea in theory, but wouldn't this solution result in a non-smooth jagged path for the bullets? Like this first example:




I am looking for something that would guess how many steps to take in y before it's time to take a step in x and so on.. like the example below:



Perhaps I'm missing something with your method, I'm a wee bit tired at the moment ;)

Thanks for helping out.
_nu

If you have a more massive amount of room, instead of a calcuylation lookup table, you would have a coordinate lokkup table. That way, the table just has the plot points for each and every bullet position and will send out to the edge of the screen. The code is much easier for that and consumes less memory cycles, BUT your table is larger.

A quick calculate

# oif anim sequneces: 360
# of anim steps (160 (the most, the least will be 100 but lets call 160)
16 bits, 4 bytes per step with the XY coordinates

360
160
4
------
230,400 bytes


A math routine and lookup table would be more practical, size wise. If you had a pc with the wasteful amount of memory, the above table would work out fine.

_________________
"My biggest dream in life? Building black plywood Habitrails"

nightmaretony,

yup, that would work.. though memory is an issue aswell, a more balanced solution between actual size and speed is pretty much needed.

_nu

My method will produce a smooth path because its adding fractional increments to the bullet location. For example, a 10 degree path will move more quickly in the x direction (cartesian coordinate system).



these values are your increments.

Here's how they'll run in 16 bit math:



Look closely at the upper byte of the locations and you'll see that it actually takes at least 2 calculations to advance the bullet, resulting in a very smooth path!!

Does this help?

Daryl

Daryl,

Ah! Very clever! Thanks for the further explanation .)
Nice solution indeed, the tables won't be too large and the math won't steal too many cycles. Again, very clever .)

Thanks a bunch for your help.
Friendly board this is, aye.

_nu

No trouble. I used the same method for my line drawing routines a long time ago.

Good luck with your project!

Daryl

Curious.

I'd think the first example he gave would look smoother in as much as you
can only move at certain discrete angles and moving one pixel at an
iteration allows an angle of 45 degrees and moving two pixels at a time
only allows an angle of about 26 degrees.
ie the maximum position error is something like 1 pixel in a given direction
and (I think) it would look better spread over 2 pixels in the other direction
rather than one pixel.

so wouldn't it be better to move at least on pixel and (maybe) preferably
two at each iteration for (at least) one of the two axis?

eg

from your table:

0B 056A 00F2
0C 05E8 0108
0D 0666 011E

if I'm reading that correctly, that's a jog of 90 degrees

Maybe I misunderstand? Or maybe you guys mean some other kind of smooth?

Also if cycles are at a premium, wouldn't it be better to move at 1-2 pixels
at a step rather than <1 ?

I'd also note that if 7 bits of sine is enough you could probably get by with
a smaller table and do linear interpolation all be it at a cost in cycles
equivalent to a few iterations of bullet movement.

In terms of smooth, I thing what Nu & I are talking about is a line with no holes, at the expense of some jaggedness.

You can do better with 8 bit Sin & Cos but using bit 7 for the direction bit was a shortcut to save cycles. I'm not sure how much cycles matter here.

Yes, this method could be optimized to save cycles and/or improve drawing accuracy.

Daryl