[futurebasic] Re: [FB] Lazy old SETCPIXEL

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : June 1999 : Group Archive : Group : All Groups

From: tatewake@... (TJ Grant)
Date: Tue, 1 Jun 1999 00:41:57 -0400
Someone told me one time that Moveto/Lineto was actually faster than
SetCPixel...

Other optomizations however...
I could see possibly saying something to the effect of:

if lastbyteset <> thisbyteset
 calc color
 set rgbforecolor
end if
moveto/lineto

Where the thought is that if the last byteset is equal to this byteset,
then use the current color and set a pixel, else recalc the color, set the
color, then set the pixel. You drop two steps this way. Your initial last
byteset could be 0 or a color index probably not found within the scope

You could also replace the multiplies/divides with bitshifts- since
bitshifts are much faster than mult/div arithmatic anyway

You could experement with loop unrolling, perhaps bulk up the file routine
to use real toolbox calls instead of "OPEN"...

You _could_ manually poke color'd bits into a gworld or on an on screen
device- but there's not much of a speed gain for one file - and consider
some of the special checking you'd have to do(depth, clipping, etc).

Perhaps making an image cache would be the way to go. If they reference the
same file with the same checksum, show the same image- only this time
pre-stored in a gworld or external PICT file. Generating the checksum each
time takes time though...

(I've always wanted to make a program that uses a file cache of some kind.)

:-)


-- TJ Grant (tatewake@...)
Inspired Communications. http://inspired.netstreet.net/
Phone: 407-728-7563