[Coco] wanting to patch HPUT routine... (ping RG!)

[Gene Heskett]

On Sunday 16 August 2009, theother_bob wrote:
>I'm experimenting with speeding up the cursor drawing routine in Color FOG.
> I've found that while I can get faster results with HPUT, it actually looks
> a bit more "flickery" due to the process...
>
>Original method was to HPUT a box erasing the old cursor, then HDRAW the
> cursor in the new location. HDRAW benchmarks @ 200 timer clicks/100 cursor
> drawing cycles (obviously dependent on complexity of cursor. I use three
> colors but kept it small and drawn efficiently.)
>
>Modified routine uses HPUT to put cursor on the screen, but requires more
> overhead... one HBUFF with a 00/FF mask of the cursor, HPUT with AND
> option, followed by HPUT real cursor with OR option. Benchmarks at <150
> timer clicks/100 double-HPUTs, but looks a little more flickery as a solid
> black cursor is placed and then the "colored in" cursor in a follow-up HPUT
> command.
>
>My goal is to speed up the process to a single HPUT operation. Basically I
> want to support "transparency" in HPUT by ignoring pixels of palette 0.
>
>One approach would be to intercept one of the options and make a new HPUT
> routine that compares pixels to 0, ignoring if 0, basically using PSET
> option if non 0. I'm thinking this would probably be a semi-complex
> subroutine compared to my next thought...
>
>I suppose an easier way would be to intercept one of the options. Maybe HPUT
> the mask but hijack the exit from AND at $EF04 and then (without returning
> to Basic) increment the HBUFF number, set the OR option flag and re-run the
> same HPUT command (reset X,Y locations?). This would just require two
> HBUFFers, mask and cursor, to be defined adjacently.
>
>Thoughts? Coding help?

Historically, cursors have been a single xor operation.  Put the curser in its 
buffer box, xor that buffer to the screen location to draw it, xor the same 
data to erase it, then move it to the new location and xor it there.  That 
reduces the usage of a bunch of buffers to just one, and the screen updates 
are going to be about as fast as the coco can do them, which isn't going to be 
entirely flicker free.  Only use more cursor buffers if you want to have 
multiple cursor styles to indicate the sort of an operation that a click will 
perform.  They of course can be pre-drawn so your proggy only has to do it 
once.

BTW, way back in history, someone tried to patent that xor operation for 
cursor drawing, but it was soon blown away by prior art from xerox parc, plus 
the fact that its the most intuitive way to do it.  That was probably the 
first of thousands of software patents the USPTO has dropped the ball with.  
That place needs to be abolished.  Where it was once a driver of innovation by 
securing the innovator an exclusive right for a limited time, it has now 
become a tool of Disney and a severe limitation on innovation because this 
exclusivity doesn't expire in a timely manner.  Software itself moves so fast 
that even the original 7 years is about 10x too long.

>TIA,
>Bob
>
>
>
>
>
>--
>Coco mailing list
>Coco at maltedmedia.com
>http://five.pairlist.net/mailman/listinfo/coco


-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
The NRA is offering FREE Associate memberships to anyone who wants them.
<https://www.nrahq.org/nrabonus/accept-membership.asp>

The only "intuitive" interface is the nipple. After that, it's all learned.
(Bruce Ediger, bediger at teal.csn.org, in comp.os.linux.misc, on X interfaces.)