I have fixed the scrolling, by introducing conditional logic only in displayRow(), and removed my previous changes in setPixel() and getPixel().
Due to you mentioning that these modules come in all different varieties and orientations, I have got rid of bool modRev and added bool flipSegCol and bool flipSegRow in the constructor, you can alternate between the two bool parameters to suit the device.
Changed the enum for scroll parameter to byte - this negates the need for less advanced users to look in to the driver code to find the names then type object.scroll(LEDMatrixDriver::Enum_Name);
The example I submitted (MarqueeTextClean) has a bug, if you instantiate char text[] with a really long string, the marquee delay grows as the loop() gets further towards the end of the displayed string. I am working on a new example which uses the buffer scroll function, then introducing a new column on the right for the current letter which will be handled in the example, it will be very effient.
quakec
commented
5 years ago
A few of things...
I have fixed the scrolling, by introducing conditional logic only in displayRow(), and removed my previous changes in setPixel() and getPixel().
Due to you mentioning that these modules come in all different varieties and orientations, I have got rid of bool modRev and added bool flipSegCol and bool flipSegRow in the constructor, you can alternate between the two bool parameters to suit the device.
Changed the enum for scroll parameter to byte - this negates the need for less advanced users to look in to the driver code to find the names then type object.scroll(LEDMatrixDriver::Enum_Name);
The example I submitted (MarqueeTextClean) has a bug, if you instantiate char text[] with a really long string, the marquee delay grows as the loop() gets further towards the end of the displayed string. I am working on a new example which uses the buffer scroll function, then introducing a new column on the right for the current letter which will be handled in the example, it will be very effient.