Erratic enemy movement?

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

User avatar
Sogona
Posts: 186
Joined: Thu Jul 23, 2015 7:54 pm
Location: USA
Contact:

Re: Erratic enemy movement?

Post by Sogona »

thefox wrote:
Sogona wrote:For flying enemies, I was also thinking about trying polar coordinates to achieve some interesting flying patterns. Just having a variable for angle and radius. The only real issue with this is that you’d need subpixels for it to look good at all, and that’d make the look up table for conversion huge.
I don't understand why you'd need a huge lookup table for this.
You’re right, actually. :wink: I’d thought about it a while back and figured out I’d only need 64 values for 0-pi/2 radians and can combine sine and cosine since they’re essentially the same; like Tepples pointed out. I’d just forgotten about these tricks. And using 16-bit values for subpixel precision would only be 128 bytes. So I guess that isn’t too bad.
tepples wrote:You'd need maybe a 64-entry cosine table, but then you'd need to multiply that by the speed to get the rectangular velocity. An 8-bit by 8-bit multiply takes a scanline and a half unless you do it through a quarter square lookup table.
I’d want speed and final cartesian positions to be 16-bit. I haven’t really looked into 6502 implementations for multiplication/division. Are there any 16*16->16 where the result is just rolled over if it exceeded 65,535? I’d guess this would take a bigger performance hit unless there are other tricks I don’t know about.

I also couldn’t decide if I wanted to just leave the screen coordinates as they were (leave (0,0) as the origin and have Y go downward as it increases) or add 128 to X and Y and then negate Y to try and “fake” cartesian space.
Post Reply