Here's the face in the original size in 3 versions: With Alpha background, White and then Black.
View attachment CrazyClockFace.zip
tgx: a 2D/3D graphics library for Teensy.
- Thread starter vindar
- Start date
Here's the face in the original size in 3 versions: With Alpha background, White and then Black.
View attachment CrazyClockFace.zip
I've been playing around with this library for a bit with thoughts on using with T41 & a 800x480 display; impressive library, excellent work.
Whilst playing with the Mars demo, I noted a fatal error within loadFalconTexture() where it assigns the Falcon mesh data (falcon_vs_1). The 'while ... mesh = mesh->next' relies upon the NULL for completion, standard stuff for running through a list, but nowhere is the final 'next' expectedly set to NULL, thus leading to unpredictable results (hard fault).
My fix was to escape on the 60'th iteration.
Impressive demo, I'll try to get a video together.
Whilst playing with the Mars demo, I noted a fatal error within loadFalconTexture() where it assigns the Falcon mesh data (falcon_vs_1). The 'while ... mesh = mesh->next' relies upon the NULL for completion, standard stuff for running through a list, but nowhere is the final 'next' expectedly set to NULL, thus leading to unpredictable results (hard fault).
My fix was to escape on the 60'th iteration.
Impressive demo, I'll try to get a video together.
Thought this might have been related to a suspected bug I've been tracking (extmem_calloc does not zero the returned memory like a regular call to calloc should) but it's not, the copyMeshEXTMEM function in tgx doesn't assign a value to the next pointer of the final mesh.
(The bug only appears when using a Teensy 4.1 with extmem, since otherwise the mesh is accessed directly from progmem.)
I investigated this a little further this morning and discovered the root cause.
In Mesh3D.h, struct Mesh3D defines .next as "const Mesh3D *next", but this should actually be "Mesh3D *next". This then allows us to remove the const from "const tgx::Mesh3D<tgx::RGB565> falcon_vs_60 = " from falcon_vs.h (line 15896). Finally, in loadFalconTexture(), the .next cast ("(tgx::Mesh3D<tgx::RGB565>*)") is no longer necessary, thus the line should be "mesh = mesh->next;".
This resolves the type issue with nullptr.
KurtE
Senior Member+
Still having some fun playing with some of this.
Something I have meant to do for awhile with ILI9341_t3n (and others based on it), was to support updateScreenAsync that optionally could use the clip rectangle or dirty area rect to limit how much of the screen to update using DMA.
So have been hacking on it. So far I have only done T4.x and it does not support continuous updates. But it appears to be working (needs some cleanup) and then try with 3.5/6
https://github.com/KurtE/ILI9341_t3n/tree/try_clipped_async
First trued it with the crazy clock setup.
Then tried the Borg 3d...
On the Borg one I have it such that I can compile for _t3n _t4...
One of the things I have not done yet, was to see what you are doing with the FPS output. Which I am not emulating yet.
Anyway having some fun!
Something I have meant to do for awhile with ILI9341_t3n (and others based on it), was to support updateScreenAsync that optionally could use the clip rectangle or dirty area rect to limit how much of the screen to update using DMA.
So have been hacking on it. So far I have only done T4.x and it does not support continuous updates. But it appears to be working (needs some cleanup) and then try with 3.5/6
https://github.com/KurtE/ILI9341_t3n/tree/try_clipped_async
First trued it with the crazy clock setup.
Then tried the Borg 3d...
On the Borg one I have it such that I can compile for _t3n _t4...
One of the things I have not done yet, was to see what you are doing with the FPS output. Which I am not emulating yet.
Anyway having some fun!
I have been busy with other things, but finally have some time to look into this some more.
I was playing around today with Vindar's ili9341_t4 driver, and I noticed that putting the 'internal frame buffer' onto PSRAM actually works pretty well when using double buffering and differential buffers. Looks like there might be change of adapting his library for the ili9488.
Failing that, I think I will have to scrap his library and drawing to a framebuffer.
I have been using this library on a different project without problems, it has been a big help, thanks!
Now I have another project that uses an 48x7 array of WS2812 LEDs with Adafruit GFX via neomatrix (neomatrix lets you use the LED array as a "screen" with the usual line, circle, etc) that works great, but i would like to use it with TGX to get transparency and nicer effects. but can not figure out what to do about the frame buffer in this:
For anyone that cares:
The array uses the new 1mm square WS2812B LEDs on a 4 layer board that is only 77x14mm (soldered by JLC) i will put it up on github eventually as "fakeVFD" which it was originally made for.
Now I have another project that uses an 48x7 array of WS2812 LEDs with Adafruit GFX via neomatrix (neomatrix lets you use the LED array as a "screen" with the usual line, circle, etc) that works great, but i would like to use it with TGX to get transparency and nicer effects. but can not figure out what to do about the frame buffer in this:
Code:
tgx::Image<tgx::RGB565> tg(???, 48, 7);For anyone that cares:
The array uses the new 1mm square WS2812B LEDs on a 4 layer board that is only 77x14mm (soldered by JLC) i will put it up on github eventually as "fakeVFD" which it was originally made for.