Re: [cc65] Colormania (was: TGI summary)

Hi,

>> Yep, because there is no support for Sprites or Sound.
>> The best would be something like an "DirectEightBit" API where someone
>> can write a game for C64 and compile it later for, for example, Apple 2
>> without much effort.
>>
>> Just my 2 eurocent...
>
> that doesnt make a lot of sense really. sprites and sound are highly system
> dependend, and to do anything half serious you will even need application
> specific code.

The example above is (most likely unintentionally) an excellent
example fo the difficulties of such an approach: The Apple2 doesn't
have sprites nor a sound chip at all.

Nevertheless one can imagine reasonable things for an "DirectEightBit" API...

- Allow to create offscreen drawpages selectable as target for the
existing tgi drawing primitives.
- Allow fast bit blitting between those offscreen drawpages and the viewpage(s).

With those two features programs could create graphic elements
offscreen during initialization using the tgi drawing primitives and
then show / move / ... those graphic elements - all in a portable way.

Additionally one could have a separate graphics creation program using
the tgi drawing primitives and then saving the generated offscreen
drawpages to disk. One would build and run that program once on every
target to support. Then another program could create offscreen
drawpages and load the (obviously target-specific) files into them.

Already these things would allow for a new type of programs to be
created with cc65 and tgi - while still being portable.

The next step could be...

Allow to access the onscreen and offscreen drawpages directly in a
"device aware" but still not target dependent way. This is what MS
DirectDraw at its core is about. There are some presumptions made
maybe not true for all cc65 tgi drivers, but the general idea is, that
- the drawpage memory is organized depending on the color depth (2
color -> 8 pixels/bit, 4 color -> 4pixels/bit, ...)
- the next pixels to the right are in the byte with the next address
- there's a certain address offset to the bytes representing the
pixels in the next row
- ...

The program asks for this type metadata for a certain coordinate on a
certain drawpage and gets the info together with an address to use for
accessing the memory. The program has fore sure to distinguish between
the different color depths when writing into a drawpage but can still
be target-neutral.

Things like this could for example allow for fast yet portable
character drawing.

To be clear about this: I'm not advocating for implenting this stuff.
I just want to point to that in my opinion there _are_ portable
approaches reasonable for 6502 targets.

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