The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Hi,I know 18bpp is used, I use it myself. The question was: Is there any hardware around that stores this information in a framebuffer every 2,25 bytes? I do not think so.
So I am not quite sure, what the use of this higly flexible pixel is. I can see a use for transforming of images. But the framebuffers I know are byte based and for performace reasons, aligned to byte, word or dword boundaries.
So when you do drawing, you can use an array (virtual area) of your pixels but I fear the performace would lack.
In a framebuffer, you normally have lots of pixels and it comes to processor cycles when you do drawing, copying, moving etc.. and want to get a useful frame rate So it is always nice if you can work with the register size of the CPU.
It sounds for me, that you plan to draw on a virtual area of pixels which are finally converted to the hardware equivalence in the framebuffer.
But maybe I did understand your problem wrong, that's why I asked for a code example.
No matter how I declare a pixel, it has to work. The channel bit depths and even the number of channels and their types are arbitrary. The only thing above that even requires an RGB color model is the source colors like light_green above and they are convertible to the destination format in cases of black&white vs RGB
I think the ILI9341 doesn't align it's frame buffer in 18-bit mode, but I could be wrong.
Either way, it doesn't matter, since the above has to work.
(It's possible to add a NOP channel to a pixel, so I can pad out an 18-bit pixel to 24 bits)
A few posters have shown discomfort with the idea of 2.25 bytes/pixel - I don't really understand their discomfort - the pixels are just there. Indeed, they are most easily grouped by the hardware/firmware in powers of two but that's only an artifact.
The problem, then, is that the artifact of basically all of our tools and abilities is geared towards powers of two and the data is not. Shyte, right ?
So, and here's the blowing smoke part - since you're going to commit a day of life to this (or so you threatened yourself). It's a matter of a proper set of masks - perched in an array that matches the pixel layout - but maybe the mask sizing should be larger than is usually intuitive. Find the lowest common multiple of 8 and 18 - and make that your mask size (at least to start) and then you simply (?) need to iterate through that array to isolate pixel (and/or their components).
You're much better at this than I, for sure, so the forgoing is an "out of the mouths of babes" type of suggestion.