Re: [cc65] tgi_sprite and friends

Hi,

> Unfortunately I have nothing new to add to this discussion thread.

By no means I wanted to stop a discussion on this topic - rather the
opposite ;-)


1. In some areas things have changed in the meanwhile too...

- 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.

- The question if that tool is able to create that binary data for
several targets from a single source (as I advocated for) is already
answered: Uz clearly stated to me that he does _not_ see
resizing/dithering/<you name it> as part of sp65. This means that one
likely has to preprocess a source PNG using gimp or whatever before
feeding the result into sp65. While I personally still dislike this
from the cross-target perspective the good news is that this is
answered.

- 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. Same as above: I personally dislike this but
the good news is that it is answered.


2. Most of us don't see TGI as the tool for high performance highly
interactive programs.

So at least for me it's totally fine that those scenarios require
other sprite/bitmap tools - just in the same way that those scenarios
require other drawing primitives in general.


3. So the primary question is about sprites vs. bitmaps - isn't it?

From the sp65 perspective that's no issue: It generates binary data
and it's up to the user to decide what to do with it and/or how to
interpret it. So somewhat more precisely it's:

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?

b) Does it make sense to have that function make use of
hardware-sprites where they are available?

Hopefully this makes sense to far...

Now for my opinion:

For a)
I think that it makes certainly sense. For me the big question was it
the (somehow limited) benefit of such a function justifies the need
for a whole new host platform tool. But now with sp65 that tool is
already there so I see no reason to not use it that way.

For b)
Given that sprites tend to have severe size limitations and that their
"behaviour" is very different from bitmaps I'd rather say that the
function as I envision it doesn't make use of hardware sprites - or
that it falls back to bitmaps if the data to be displayed is to large.
I would imagine that a TGI user should be allowed to use the function
to display "something" covering the full screen - the function
shouldn't be optimized that that scenario but it should be a scenario
not precluded.

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.

Just my two - as always length - cents,
Oliver
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.