gfs@abvax.UUCP (Greg F. Shay) (06/08/88)
I don't know if these challenge proposals are a popular idea. I am simply trying to drum up some exchange of ideas, with a motive for finding the best. The integer sine program resulted in references to the CORDIC algorithm which I admit is a better solution for what I was trying to do. Here it is, who can write the fastest code fragment for drawing 2-d vectors in a bit mapped screen. My test system has a 68000, and so do Macintoshes so the 68000 seems to be a good place to start. Any other micro is fine too. The algorithm and clever use of registers is what I am after. Vector draw routines involve some setup computations and then an inner loop that rapidly sets the bits in screen memory. A tradeoff must be made since the setup for the fastest inner loop may be longer than the setup for a slightly slower inner loop which will cause a difference in overall performance depending on the average length of the vector drawn. For arguments sake, unless someone knows of a better number, assume the average length of a vector drawn is about 50 pixels. I'll post my 68000 assembler code later. For now, I'll say the innermost loop takes an average of 51 machine clocks per pixel (8 instructions). At 8 Mhz, this would be 6.375 microseconds per pixel or 157,000 pixels/sec. Have fun! Greg Shay ..mandrill | ..pyramid |..!abvax!gfs ..decvax |
bayes@hpfcdc.HP.COM (Scott Bayes) (06/10/88)
> Here it is, who can write the fastest code fragment for drawing 2-d >vectors in a bit mapped screen. My test system has a 68000, and so do >Macintoshes so the 68000 seems to be a good place to start. Any other micro >is fine too. The algorithm and clever use of registers is what I am after. ... > I'll post my 68000 assembler code later. For now, I'll say the >innermost loop takes an average of 51 machine clocks per pixel (8 instructions). >At 8 Mhz, this would be 6.375 microseconds per pixel or 157,000 pixels/sec. > Have fun! > Greg Shay So what's the frame buffer architecture?? Our (HP's) 200 and 300 series computers support multiple frame buffer architectures, including "packed pixel odd byte" (bit-per-pixel monochrome, think move.p alignment), "packed pixel" (normal bit-per-pixel), byte-per-pixel, separate planes, etc. These variations can make quite a difference at the machine clock level. Is your algorithm faster than a cleverly implemented Bresenham? Is it just an implementation variation on Bresenham, or is it something new and different? Scott "tight loop" Bayes bayes@hpfclw