Joined: 6/14/2004
Posts: 646
I'm just saying for the purposes of NES level programming, it's pretty darn close to a circular path.
I like my "thank you"s in monetary form.
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
NrgSpoon wrote:
I'm just saying for the purposes of NES level programming, it's pretty darn close to a circular path.
When I tried that algorithm with the program below, I get all kinds of weird paths (by varying the initial value of xvel), such as:
Language: cpp

#include <cstdio> int main() { const int kImageWidth = 300, kImageHeight = 300; unsigned char image[kImageHeight][kImageWidth][3] = {}; const int cx = kImageWidth/2, cy = kImageHeight/2; const int ix = cx, iy = cy + 130; int x = ix, xvel = 15, y = iy, yvel = 0; do { if(x < cx) ++xvel; else if(x > cx) --xvel; if(y < cy) ++yvel; else if(y > cy) --yvel; x += xvel; y += yvel; if(x >= 0 && kImageWidth > x && y >= 0 && kImageHeight > y) image[y][x][0] = image[y][x][1] = image[y][x][2] = 1; } while(x != ix || y != iy); std::printf("P6 %u %u 1\n", kImageWidth, kImageHeight); std::fwrite(image, 1, kImageWidth*kImageHeight*3, stdout); }
Limne
Any
Joined: 2/24/2010
Posts: 153
Warp, thanks for code snippet, it's actually pretty useful to trying to understand all this. Unfortunately, I'm at my parent's place for the holiday's without access to my development tools so I won't be able to try anything out. But I figure once I get a handle on this "difference between consecutive circles" idea I should be able to develop an algorithm for calculating where the nth pixel goes given some sort of "speed" variable.
Joined: 10/24/2005
Posts: 1080
Location: San Jose
For trig functions: CORDIC is used very frequently in DSP applications where you may not have a FPU (or even Fixed Point) multiply/divide unit available.
<agill> banana banana banana terracotta pie! <Shinryuu> ho-la terracotta barba-ra anal-o~