Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix diagonal screen tearing #379

Open
reticivis-net opened this issue Apr 24, 2022 · 1 comment
Open

Fix diagonal screen tearing #379

reticivis-net opened this issue Apr 24, 2022 · 1 comment

Comments

@reticivis-net
Copy link
Contributor

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

@mateoconlechuga mateoconlechuga changed the title [enhancement?] fix diagonal screen tearing Fix diagonal screen tearing Jun 22, 2022
@drdnar
Copy link
Contributor

drdnar commented Nov 28, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants