Re: Fonts
John DeHope writes:
> EMemCopy does this *really* fast.
> Simple, right? I hope this offers a clear alternative to using the pixel
> routine. I think RDS included it for the sake of being complete, but it
> has *no* place in any graphics library that even wants to dream of
> speed.
Ouch!
You're right of course. pixel() is much slower than mem_copy(), poke(),
special machine code, or techniques that only work in one graphics mode.
However I'd like to mention:
* pixel() is much faster in mode 19 than in other modes.
* pixel() of a fairly long sequence of points is *much* more
efficient than pixel() of a single point (atom)
* pixel() will safely clip points that are off the screen
If you have an algorithm that calls pixel() once per pixel,
you should strongly consider converting it into one that composes
a sequence of pixels before making a single call to pixel().
The same goes for display_image() - try to output bigger, especially
wider, images in each call.
* * *
Notice to registered users: It's now November. You are all
eligible to toss another dollar (of our money) in the collection tray at:
http://members.aol.com/FilesEu/ecoform.htm
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
|
Not Categorized, Please Help
|
|