Thoughts on a "minimalist" graphics library.

[netzerohero]

In order to stimulate thoughts and conversation in this newly stood-up forum, re-posting some musing initially captured under Issue-#8:

Implementing a "minimalist graphics libarary" is not limited only to EhBASIC+.
Consideration should be given the the two or three environments evolving for the picocomputer: EhBASIC, cc65 and now perhaps llvm-mos.

It has been demonstrated that features may be added:

• directly to EhBASIC (via assembly);
• using cc65 (via C and it's rich set of mature libraries), and
• the merged cc65+EhBASIC worlds.

llvm-mos, with its more-efficient code and parameter calling (over cc65), adds a new wrinkle. (Apparently, llvm-mos library support is not as mature and feature-rich as cc65.)

Consideration IMHO should be given to: ease-of-implementation vs. code-size / calling-parameter inefficiencies, along with limits of developer skills of the technical HW intricacies isolated via more-user-friendly SW-library implementations.
(Read this as: I'm not intimately familiar with the pico's video implementation. :) )

My interpretation of TGI is that it is a graphic-extension to CC65's libraries, introducing helpful hardware-agnostic isolation. The trade-off of course is: being OK with the resulting inefficiencies in an already memory-constrained 8-bit environment.

Can and should a common library methodology be used across all three environments?

[netzerohero]

One approach could be taking vmuumllc's fuller-featured graphics-library and integrating that to cc65 as a TGI extension specific to the rp6502 picocomputer. Then implemented TGI features under cc65 may be used for any picocomputer graphics extensions exposed to EhBASIC+, using cc65/TGI.

IMHO, that is a significant enough project (TGI-extensions to cc65) to stand on it own, separate from EhBASIC+.
(If that approach is taken, examples on implementing can be found in the TGI implementations for: apple2, c64 & c128, vic20 and nes.)

The current EhBASIC+ graphic feature is point-plotting and screen-clearing, with a possible extension to "line-to" plotting. Unless more extensive graphic features such as geometric-shapes (circles/ellipses, squares/rectangles, triangles) with fill, or sprites are considered for addition to EhBASIC+, it is not clear that using TGI/cc65 is beneficial over directly implementing the EhBASIC+ graphics extensions directly using assembler or plain-cc65.