Re: [cc65] tgi_sprite and friends

Hi!

On Thu, Nov 08, 2012 at 11:30:06AM +0100, Oliver Schmidt wrote:
> The TGI API is derived from the BGI API you can find at
> http://www.cs.colorado.edu/~main/bgi/doc/

"Derived" is the wrong word. "Inspired" would be better. I've written several
BGI drivers and had some intimate knowledge about the internals. Using this
knowledge in both ways (knowing what to implement and knowing what to avoid)
seemed as a good idea to me. But TGI is not BGI, so pointing to BGI as an
reason why something should be done in the same way is wrong in my eyes.

> For some reason or another Uz replaced putpixel() with tgi_setpixel()
> which seems sort of a pitty to me as in the BGI API set...() means
> modifying the internal state of the enigne while put...() means
> modifying the screen.

In retrospect you're right, but as always it's easy to be smart afterwards:-)

> I personally would go for tgi_setbitmap() as tgi_setimage() seems to
> imply some "advanced abstration" we don't want to offer. Rather ther
> opposite: I.e. hardware-sprites (which might be classified as images
> too) are not covered by the function.

BGI putimage/getimage had no advanced abstraction whatsoever, so this doesn't
seem like an argument for me. BGI didn't document the format of the data, and
the format was actually driver dependent. So it was not possible to use
putimage with externally generated data, at least not in a clean way. All one
could do was to use getimage to fetch part of the screen, then use putimage to
place it somewhere.

On the other side, it's just a name. I'm happy with xxximage as well as with
xxxbitmap.

BTW: There was an imagesize() function that calculated the space requirements
for the data. We might also need such a function if we implement a get...
function for graphics data.

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.