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

[theother_bob]

----- Original Message ----
From: Gene Heskett <gene.heskett at verizon.net>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Sunday, August 16, 2009 11:34:02 AM
Subject: Re: [Coco] wanting to patch HPUT routine... (ping RG!)

On Sunday 16 August 2009, theother_bob wrote:
>----- Original Message ----
>From: Gene Heskett <gene.heskett at verizon.net>
>To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
>Sent: Sunday, August 16, 2009 10:13:13 AM
>Subject: Re: [Coco] wanting to patch HPUT routine... (ping RG!)
>
>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...
>
><snip>
>
>>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.
>
><snip>
>
>>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.
>
><snip>
>
>
> This seems like it would be great for B&W, and I may use it in a hires,
> 4-color version, but on HSCREEN2 it mixes the colors, which is
> "undesirable" in this case.
>
>My cursor uses 3 palette colors, so I have to mask out (zero out) the colors
> behind it before ORing it into place.
>
>If the HPUT command included the XOR option, it would probably have been
> broken anyway, like the NOT option is.
>
>Bob

Well, in fairness, I was referring to those operations in os9.  They seem to 
work fairly well.  Is there any room to patch the HPUT?
>

I'm sure I could find a few dozen bytes to insert some intermediate code.
I've already patched HPRINT in a similar manner. Those 13 bytes make a
huge difference in program overhead by not having to clear the background first.
It should have been an optional flag on the HPRINT command.

Bob