drdnar
commented
1 year ago So for the record, the issue is that the LCD is actually a portrait-mode display that is rotated on its side. It updates its pixels top-to-bottom (as you would expect) but since it's rotated onto its side into a landscape orientation, it's actually updating left-to-right. Via some clever abuse of hardware control registers, we can make it look to us programmers like a landscape display with pixels ordered in rows instead of columns. Unfortunately, the LCD module itself still updates the physical pixels in columns, while we're sending pixel data to the LCD in rows. It's similar in concept to Vsync-related screen tearing. By rotating the buffer, we can send data to the LCD in the same order it's physically used to prevent the tearing.
Rotating the buffer requires completely rewriting GraphX (and FontLibC). The same general algorithms still apply, but the code makes a lot of assumptions for optimization purposes and therefore basically every single line needs to be reviewed. Some optimizations also get easier, others get harder. Sprite data will also all be rotated, so it could break some existing programs. (You could also do the rotation at runtime, but that carries a performance penalty.)
If somebody wants to learn a whole lot about graphics algorithms and eZ80 optimization, this is a surely a good project to take on. It's just also a big one.
ZERICO2005
people on the CE Programming discord said that this could be done by rotating the buffer, though they also said "it's [probably] far more trouble than it's worth". I'm aware the OS also has this screen tearing this is just a wishlist low-priority thing that I just wanted to put on yall's radar in case someone ever wanted to if not I get it