Re: C64 graphics card

From: Christopher Phillips (
Date: 2004-11-04 05:12:35

On 4 Nov 2004, at 01:23, Steve Judd wrote:

> Hola CJ,
>> Do you still do fullscreen clears rather than writing to the screen
>> with an eor-plotter?
>> Or are you referring to the cost of clearing the eorbuffer?
> Actually, I have a very low opinion of eor-plotters (solid polygons).

solid?  Pattern fills like the ones your lib supports are pretty easy 
to add to an eor-plotter.  Texture mapping or gouraud shading's another 
issue altogether of course.

> They are slow and obnoxious, with special cases and such to handle, and
> there are much better -- faster, cleaner, more flexible -- ways to do 
> it.

They are hard to get working, and at the moment you have much better 
performance than me on simple convex objects, but I suspect with a bit 
more optimisation a good eor-plotter will win if there's much overdraw. 
  I only just got the routines in Effluvium debugged/working in time to 
release it - there's quite a bit of scope for improving the code.

Congrats on the speed of lib3d btw - I still haven't gotten around to 
playing with it, but your quoted 8-10 fps on the Elite craft is v. 

> Yes, I do fullscreen, or at least full-the-area-containing-data clears.
> Or did, I guess, since this was all years ago.  You really have to, if
> you're drawing more than one object.  For a single object, my 
> recollection
> is that once you factor in overhead it's always faster, unless you're
> drawing just one or two polygons, and only maybe then.

hmm - I overwrite the entire screen every refresh, but each byte is 
only touched once regardless of the number of polygons.

>>> As to organization, vertical organization is preferred for any
>>> plotting.True for BOBs etc, but I would have thought less applicable 
>>> to 3d?
> Any routine involving an x,y coordinate benefits, especially line and
> polygon routines.

I use a pair of charmaps myself (32*16), but that's mostly to save me 
having one eor-fill routine per character row - it's a memory saving 
rather than a speed thing, and one that would not be required with a 
hardware eor-buffer such as the one I proposed in an earlier mail in 
this thread.


       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.