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.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
Larson did another on the same theme, which was published in The Prehistory of the Far Side but never submitted to newspapers. For obvious reasons. One dog is explaining a jar on the mantel to another, saying, "The vet let me keep them. They're my testicles."
Update: WHO'S A SUPERSTAR? I FIXED IT. I needed a pair of parentheses.
I spent weeks - weeks! working on a device independent pixel in C++
I finally built it, and it seems to work, but they're tricky because they store the pixel in the form of its final memory representation in a frame buffer, so if you defined a pixel as 24-bit color, there's a new pixel every 3 bytes, and if you defined a pixel as 18-bit color (6 bits each for R, G, and B - shockingly common) then there's a new pixel every 2.25 bytes!
So it gets ... tricky. There's bit shifting, masking and whatnot.
I'm not testing on an actual display device yet, so i have code that converts small bitmaps to monochrome and then renders them as "acii art"
My blting works, my filling works, and my clearing works, when the pixels are either byte-aligned (like 24 bit pixels) or 1 bit (monochrome), but the 18-bit one is weird, and clearing isn't working.
I think it's with my bit setting code, i thought, but also no, because it's clearing in the wrong place?
Each pixel is #, or black is just empty space. I have a hatch pattern i bltted and them i'm clearing a box inside of it. The clearing is what is failing.
That would actually make things easier in this one case. But because pixel definitions are completely arbitrary in terms of the channels they have and the bit depth of each, the total bit depth of the pixel can be anything more than 0 or less than 65, so it would only help in that one case.
It's just weird that it works with everything else but catastrophically fails on "satan's pixel"
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)