Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This ones just hvtile changes to try make life easier. As said no worries if not use. But its adds consitency and shouldnt break anything, but will take abit more code space and RAM up. Display drivers that use horizontal architecture can updated as needed.
The tile buffer width is needed by the horizontal display drivers, otherwise there is no way of knowing width of sent buffer for incrementing a display row, because tile buffer width size sent to display driver changes. But generally it is 1byte wide for u8x8 and display row wide for u8g2.
I also added variable tile width to draw_hvtile conversion buffer, but as said its generally only 1 tile sent from u8x8 to display, but its there for consitency and maybe needed in future, adds very little to code size. The coversion method used not sure is best, but seems reasonably compact and not to processor or memory hungry.