avsa242 / libgfxbitmap-spin

Generic bitmap-oriented graphics library for spin

libgfxbitmap-spin

---

This is a P8X32A/Propeller, P2X8C4M64P/Propeller 2 library for generic bitmap-oriented drawing routines.

Salient Features

• Line, Circle (not ellipse), Box, Plot primitives
• Text rendering (uses terminal.common.spin[2]h to provide str(), hex(), bin(), printf(), etc)
• Text: 0 or 90 degree-rotated font bitmaps
• Text: Character cell-level or pixel-level positioning (build-time)
• Text: Internal or custom user-provided putchar function pointer
• Copy bitmap to display buffer, with optional offset
• Copy, cut, scale region
• Single-pixel scroll up region
• Integration with most any dot-matrix type display

Requirements

P1/SPIN1:

• 69 bytes global var RAM for settings, configuration
• terminal.common.spinh (provided by spin-standard-library)

P2/SPIN2:

• 69 bytes global var RAM for settings, configuration
• terminal.common.spin2h (provided by p2-spin-standard-library)

Compiler Compatibility

Processor	Language	Compiler	Backend	Status
P1	SPIN1	FlexSpin (6.5.0)	Bytecode	OK
P1	SPIN1	FlexSpin (6.5.0)	Native/PASM	OK
P2	SPIN2	FlexSpin (6.5.0)	NuCode	FTBFS
P2	SPIN2	FlexSpin (6.5.0)	Native/PASM2	OK

(other versions or toolchains not listed are not supported, and may or may not work)

Limitations

• Text rendering is s l o w; needs optimization
• Region scrolling not implemented fully on 1bpp displays

libgfxbitmap-spin's Issues

Speed up Copy(), Cut()

Could block memory moves be used instead of calls to Plot() to speed these up?

Bitmap() should take x, y coords as display offset

Currently, it uses a linear offset in the display buffer memory

address() should be split into two discrete methods

This really doesn't need to be crammed into one method and should be split into two for simplicity.
Rename address() to set_address() (with alias to the name address so existing code doesn't break) and move the read code to a new method get_address().

EDIT:
The current address() actually lives re-implemented in each display driver. Since it should always operate the same way, move it into the graphics library, too.

Make it possible to draw text at pixel-level granularity

Currently coordinates can only be set at character-cell coordinates.

• spin1
• spin2

set_dims() doesn't account for displays with color depths less than 8bpp

_buff_sz and _bytesperln are calculated based on the assumption that BYTESPERPX is >= 1
Since this can't really be fractional, it isn't calculated quite correctly for displays with bpp < 8 (e.g., monochrome displays like SSD1306).
There probably should be a new divider symbol incorporated into these calculations for these cases.

Finer steps in Scale()

Currently, Scale() only allows scaling a region of the display up, not down, and only by integer amounts.

Scrolling is broken on 1bpp displays

Scrolling a region of the display doesn't currently work for 1bpp drivers, e.g., SSD1306/9, IL3820, Charlieplexed LED matrix
These displays present a somewhat unique problem in that every byte of the display memory actually affects 8 pixels, so it isn't as simple as a bytemove

Add support for rotating bitmaps

Ability to rotate bitmaps or areas of the display.

Rewrite Bitmap() to use x, y coords

Operation would be much more straightforward if parameters were coordinates, rather than (currently) a memory offset within the display buffer.

Add polygon primitive

Add a method for drawing n-pointed/sided polygons.