...and getPixel(... is not even implemented... at least at the time I used it. I wrote my own retrieval (and so did @JumJum).
Going for a bit more elaborate UI, for example for having drop-down menu / overlay, the current serial connectivity is too slow and memory is too scarce... and repainting the whole screen is even slower (if even possible... because state in source form would have to be preserved).
Check out this conversation about Graphics.getPixel(x,y) on ILI9341 Module for ILI9341 LCD CONTROLLER and Resistive Touchscreen directly (no touch controller), especially post #12, where I'm talking about calibration of the resistive touch screen. For calibration (at any time), 5 squares would overlay the current display to provide defined touch targets. Before the display the underlaying area is saved and afterwards restored.
After that 'slow' experience my excitement about the display and its display capabilities weren't of prime interest anymore. The display would need its own controller implementation beyond just managing the display memory and fixed font usage. I struggled with the display update speed as well when going for DIY Marine GPS using enhanced GPS Module, u-blox NEO-6M GPS receiver, and ILI9341 Module controlled 2.8" Color TFT LCD. One second was not enough to update longitude, lattitude, number of satelites, time, etc... I had to resort to update only changed data, and of that only a section, and the next second, another section, etc.
My initial intent with the display was to write the PacMan game... but the speed let this project fell into a deep sleep. The only game I then successfully implemented was the 15 out of 16 number puzzle game Puzzle16+ Game on ILI9341 2.8" 262K Color TFT LCD w/ Resistive Touch Screen. I'm sure you can load the code and experience the behavior yourself... I optimized already the implementation by choosing what is working the fastest...
© Espruino, powered by microcosm.
Report a problem