Re: [cc65] tgi_sprite and friends

On 07.11.2012 12:42, Oliver Schmidt wrote:
> - The question to have a tool that runs on the cc65 host platform and
> that creates target (and graphics mode) specific binary data is
> already answered: Uz introduced sp65.

This is very good news for Lynx developers because now we have the 
_complete_ set of tools in one single package.

> Uz clearly stated to me that he does _not_ see
> resizing/dithering/<you name it> as part of sp65.

This is exactly what I want too. Rescaling and recoloring stuff produces 
bad results. When porting stuff you should always pay attention to the 
quality of the graphics on the screen.

> - The question if that tool is creates a common header for that binary
> data allowing i.e. to dynamically load a suitable TGI driver in order
> to render it (as I advocated for) is already answered: Uz added some
> metadata support when generating C code but clearly stated that he
> does _not_ see that - at least in a generic cross-target fashion - for
> generating binary data.

I am very much for the way Uz did it. There is no way the sp65 can know 
in advance what the bitmap will be used for. Is it transparent, border 
sprite, collidable sprite, scalable, tiltable/skewable. All these 
require different container structures. They can easily be implemented 
with the #defines provided in the bitmap.c file.

> a) Does it make sense to define a cross-target TGI function that takes
> some target-specific sp65 output and places it on the screen?
>
> But now with sp65 that tool is
> already there so I see no reason to not use it that way.

I have the same opinion. Could it be tgi_bitmap with some arguments?

> b) Does it make sense to have that function make use of
> hardware-sprites where they are available?
>
> So if a target has hardware-sprites there's nothing to say against a
> target-specific ioctl-based extension. And of course sp65 may generate
> binary data consumed by that extension. But it seems to me that the
> cross-target function that I'd like to see should most likely rather
> stay clear of hardware-sprites.

Makes sense to me too.

What arguments should tgi_bitmap have?

Could it be an argv style command like tgi_bitmap(bitmap, ...)?
It could be expanded by posx, posy, width, height, type, bits_per_pixel, 
palette depending on what the target can handle.

--
Karri

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