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

Background Image? #91

Open
thestumbler opened this issue Dec 21, 2024 · 2 comments
Open

Background Image? #91

thestumbler opened this issue Dec 21, 2024 · 2 comments

Comments

@thestumbler
Copy link

I prepared a pixel for pixel background image, 240x240.
Is there a mechanism for rendering that in Tempe?
In the Hughes library, there is a function to open an image file and convert it to RGB565 buffer for display. I'm thinking this exists, or almost exists, in Tempe but can't quite figure it out.

@thestumbler
Copy link
Author

Has a sudden thought -- since I'm using the Hughes library underneath Tempe, gc9a01_mpy, I realized that I could draw a background image using that before making tempe calls. Well, that did and didn't work. It did draw the image at first, but as soon as Tempe started refreshing the image disappears. Next I tried adding it up the Tempe update function. This "works", in that an image is drawn, but you see the updated rectangular regions being redrawn with black background (not surprising since Tempe doesn't know there's an image there). That also slows down the updated rate significantly, like 5 or 10 times slower.

I also wonder, are there two competing buffers in this case? Hughes driver has a working buffer, and Tempe has a separate working buffer. Should these be the same?

@corranwebster
Copy link
Contributor

corranwebster commented Jan 3, 2025

Apologies for the delay - back after holiday break.

To get a background image, you want to use a Bitmap: get your image into RGB565 format framebuf.FrameBuffer somehow and do something like:

surface.bitmaps("BACKGROUND", (x, y, w, h), buffer)

This is going to be really memory intensive though - you need the entire image in RGB565 format in memory the whole time, in addition to your rendering buffer. It should be reasonably fast after the initial draw, though at least on the current main branch, as it should only draw the updated regions of the image when things change.

Edit: order of arguments was wrong.

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

No branches or pull requests

2 participants