Closed wEPac closed 5 years ago
Hi, I just pushed a new branch (rotation) that addresses this problem. I have rewritten the code not to do a "look ahead" or "look back". I'd be happy if you could take a look and check if I didn't break it even more :)
Ah, one more thing. I have made changes this code that inverts display so that the framebuffer always contains the same data and it's inverted only when it's being written to the hardware.
More than pretty good news, and I feel it a great idea, this will allow us to work on the buffer without to think further :) I was close to rewrite some parts for the issue with different hardwares when I saw you are already working on with other contributors too :) I really like your driver, simple but efficient, it will preserve memory for the project. I will look further for this new branch
If I get no more complaints about the new scrolling code I will close this issue. Feel free to test branch "rotation" any time.
For now, rotation driver is working fine for me, that s pretty cool, these adjustments were the missing part from your driver. If I find something wrong, I will report. Have a nice day.
Okay, thanks for checking. I close the issue.
Hello, thank you for this nice driver. I was making some changes to use the scroll function with the "modRev" on. It is working fine now, I made a fork... But I found a fatal bug in this function. In the original file, we have
for (i = 8 * N; i >= 0; i-- )
when we should havefor (i = 8 * N - 1; i >= 0; i--)
because hereif ((i + 1) % N) frameBuffer[i + 1] |= (n << 7);
we can see, when i == 8 N, it will write at 8 N + 1, outside the frameBuffer array : [0; 8 * N [