Re: [cc65] TGI blit

Hi Karri,

> This is the first problematic area. In real life I probably cannot use the
> colors and resolutions directly on my target. Part of porting a project
> includes fine-tuning the colors and the size of the graphics. For me it is
> enough to do the reduction of colors, dithering etc in Gimp. I would then
> save my graphics as an indexed png file.
>
> I do not want any extra "intelligence" of the conversion tool. Just re-pack
> the data - don't mess with it. This means that the colors, indexes and
> palettes are already suitable for the target when I compile my code.

That doesn't seem a big problem to me. The tool should have option to
allow for resizing, color reduction, dithering and alike, but it
should of cource be able to not do those things if not technically
necessary and/or desired by the user.

>> - The bitmap contains some minimal header with height and width and ...
>>
>
> This is very device dependent. Don't define it. Just define a binary object
> that contains the graphics without defining the structure, the fields etc.

I certainly didn't want to propose a common definition of those
things. I just wanted to point out the difference to "pure raw"
dataformats: Because the size isn't fixed there needs to be at least
enough metadata for the driver to know how to interpret the data. How
much that is and how it is structured depends on the driver.

However it might make sense to have a "pre-header" stating for which
driver the bitmap is intended. Beside consistency checks this could be
used by some generic bitmap viewer that looks at that pre-header and
then loads the corresponding driver - a very nice showcase btw for the
cc65 dynamic driver loading...

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