#By the way I saw your color pallet
1 messages ยท Page 1 of 1 (latest)
how about this?
from displayio import release_displays
from framebufferio import FramebufferDisplay
import gc
from picodvi import Framebuffer
release_displays()
gc.collect()
fb = Framebuffer(640, 480, clk_dp=CKP, clk_dn=CKN,
red_dp=D0P, red_dn=D0N, green_dp=D1P, green_dn=D1N,
blue_dp=D2P, blue_dn=D2N, color_depth=8)
display = FramebufferDisplay(fb, auto_refresh=False)
that's a copy and paste from my code at https://adafruit-playground.com/u/SamBlenny/pages/fruit-jam-color-checker with minor edits for the width, height, and color depth arguments
The trouble with higher resolutions is that they get really slooooooooow
doing stuff at 320x240 is moderately reasonable. above that is painful
if you're happy with e-ink like performance, then higher res is probably fine
I think I may have seen the very slow with the Matrix screen saver code.
So for game or anything interactive, this is not fun. But for enhanced graphic PyPortal that display some AdafruitIO information (in my case local MQTT), it could be fine, I only update every 15 or 30 seconds.
It is mostly text, but the font was ugly with big pixels.
tannewt was doing something with custom font rendering for the game he was working on in his deep dive show a while back. not sure where that code lives
have you looked at the fruit jam os thing that foamyguy has been working on?
Not yet, I need to finish adding the DAC to have a more or less FruitJam complete.
Next I will likely add AirLift to get up to speed to the next FruitJam revision, maybe not C6 but what I have in stock.
I have seen a few of foamyguy's stream, but not in full or not in the right order, or not the right one. ๐ฆ
You might also keep an eye out for hardware updates on Desk of Ladyada and Ask an Engineer. From the show last Wednesday, it sounds like we may get more Fruit Jam news soon.
you might have a look at this for the font stuff: https://github.com/adafruit/Adafruit_CircuitPython_Bitmap_Font. From a quick scan of recent commit messages, it looks promising.
I tested some unicode demo with all kind of emoji, but that was not mixing well with the other things I was doing.
also, this one: https://github.com/adafruit/Fruit-Jam-OS
oh, yeah. unicode emoji can be really tricky. Depending on which characters you use, the resulting UTF-8 can be a grapheme cluster (a chain of codepoints) instead of just one codepoint. Not all text rendering systems can handle that. And they come up with new emoji frequently. You might have better luck if you stick to the older single-codepoint emoji that are present in Unifont
GNU Unifont free software utilities
For fancier graphics in CircuitPython, I've had the best results from using a TileGrid and a bitmap spritesheet. For example: https://adafruit-playground.com/u/SamBlenny/pages/feather-tft-gamepad-tester-with-sprites
If you used sprites and a TileGrid, you could screenshot emoji from your computer at whatever size you want, then convert that into a spritesheet as a bmp image file.
I found this about the font used for terminalio:
https://docs.circuitpython.org/en/latest/docs/environment.html#circuitpy-terminal-font
and on the same page, the HSTX display initialisation. I think this is an interesting place to look at for some enhanced text mode with special fonts.
Now I have enough things to investigate, for the coming weeks. ๐
Little update:
fb = picodvi.Framebuffer(640, 480, ..., color_depth=8,)
just does
MemoryError: memory allocation failed, allocating 307200 bytes
But with color_depth=4 it works and I have a full screen. So now I have to work on color selection and adapt for "high resolution" like picking a bigger font (that also use more memory I guess).
oh... that's interesting. Which board are you using to test with? Does it have PSRAM? Also, are you importing any large libraries, or otherwise doing stuff that allocates much, prior to setting up the display?
Ideally, you want to set the display up first thing when your code starts because it claims a big chunk of your heap. So, anything you've done prior to that which reduces the available heap space, or which fragments the heap, will up the odds of an allocation exception.
Also, that allocation persists across auto-reloads. So, if your code is set up to re-initialize the display each time code.py runs, and if you make lots of code changes before reseting the board or unplugging it, eventually you'll run out of heap.
Did some more experimenting today, and I got that same MemoryError exception on my Metro RP2350 (no PSRAM version). Seems like 640x480 8-bit needs a PSRAM chip?
I played around with some stuff in an attempt to minimize the RAM used by my code. Managed to just barely sneak past that first exception, but then I immediately got another one when I tried to create a Bitmap object.