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 · 2 comments
Open

Fix diagonal screen tearing #379

reticivis-net opened this issue Apr 24, 2022 · 2 comments

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.

@ZERICO2005
Copy link
Contributor

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 lcddrvce.h, it should be pretty easy to enable Column-Major mode on the ti84ce.

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

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

No branches or pull requests

4 participants