-
-
Notifications
You must be signed in to change notification settings - Fork 53
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
Comments
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. |
This has been mostly fixed through the development of GraphY. Which runs about a third as fast as GraphX in Oiram since it is written in C. Thanks to calc84maniacs research into the SPI controller and for GraphY is not incorporated into the toolchain yet, so you will have to copy graphy.c and graphy.h into your project for now https://github.com/ZERICO2005/PortCE/tree/master/src_PortCE/PortCE_include/graphy |
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
The text was updated successfully, but these errors were encountered: