Re: [cc65] 3dmaze portability

Hi Uz,

> As far as I remember, the plan was to put clipping into the wrapper, because
> it's target independent and this way, clipping must only coded once.

I see, so the drivers are _not_ supposed to do it.

> But since
> I didn't come up with a pixel exact algorithm immediately, I postponed it and
> so it never made it into the library.

I see.

In general I think this is a difficult decision. AFAIK computing the
position of the pixel at the edge of the screen is from the algo
perspective as expensive as actually drawing the line (at least with
Bresenham). So if a driver explicitly implements the line drawing code
then it would be way more effective to let the driver do the clipping.
If however the driver rather calls some external function to draw the
line (which doesn't clip) then the clipping code is additional
overhead anyway - and sould therefore go into the wrapper in order to
have it only once. Most likely a quick test if clipping is necessary
at all, and then do it if necessary in the wrapper is the most
promising approach...

> But this is only true for lines - other
> primitives (like circles) must do their own clipping.

I see. So could you please comment on the comment below replicated
into most drivers?

; SETPIXEL: Draw one pixel at X1/Y1 = ptr1/ptr2 with the current drawing
; color. The coordinates passed to this function are never outside the
; visible screen area, so there is no need for clipping inside this function.

> The reason why the C64 driver has clipping is that it was derived from Stephen
> Judds GRLIB code, which clips when drawing pixels.

Thanks for the background info :-)

Best, Oliver
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.