Hi! On Wed, Oct 28, 2009 at 02:56:40PM +0100, Oliver Schmidt wrote: > Instead of having each driver supply the CIRCLE routine there could be > just a single shared routine (incl. clipping) right inside tgi_circle: I'm just coming back from running, and while I looked at all the autumn foliage, I had the same idea:-) > The interface from the tgi_circle into the driver could look something like this > - CIRCLEINIT called once at the start of circle drawing > - CIRCLEPLOT called for every pixel to be plotted > - CIRCLEDONE called once at the end of circle drawing > > The CIRCLEPLOT parameters would be identical to SETPIXEL so a driver > could implement the three entrypoints by > - just returning on CIRCLEINIT and CIRCLEDONE > - aliasing CIRCLEPLOT to SETPIXEL I would even go a step further: * No circle support by the driver at all. * The wrapper implements circles by using a cosine table and drawing line segments. This has one disadvantage and a lot of advantages: * The circle routine is slower than before. * The drivers get smaller and simpler. Part of the saved space could be used to max out the line drawing routine, which becomes more important than before. * Ellipses, pie slices or whatever could also be done without much trouble. * The sine/cosine routines could be user callable, removing implementations from 3dmaze, tgidemo and all the doom clones for the 6502 machines :-) * Programs that don't use circles don't pay for it in terms of code size. * The runtime can be used to do multiplications and such. This is not possible from a driver. * Circle is the only routine that needs clipping in the driver if we do also change OUTTEXT. This means that clipping can be removed completely from the drivers making them smaller and faster. Now, how does that sound? Regards Uz -- Ullrich von Bassewitz uz@musoftware.de ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Wed Oct 28 16:06:19 2009
This archive was generated by hypermail 2.1.8 : 2009-10-28 16:06:22 CET