|
1. The lounge is for the CodeProject community to discuss things of interest to the community, and as a place for the whole community to participate. It is, first and foremost, a respectful meeting and discussion area for those wishing to discuss the life of a Software developer.
The #1 rule is: Be respectful of others, of the site, and of the community as a whole.
2. Technical discussions are welcome, but if you need specific programming question answered please use Quick Answers[^], or to discussion your programming problem in depth use the programming forums[^]. We encourage technical discussion, but this is a general discussion forum, not a programming Q&A forum. Posts will be moved or deleted if they fit better elsewhere.
3. No sys-admin, networking, "how do I setup XYZ" questions. For those use the SysAdmin[^] or Hardware and Devices[^] forums.
4. No politics (including enviro-politics[^]), no sex, no religion. This is a community for software development. There are plenty of other sites that are far more appropriate for these discussions.
5. Nothing Not Safe For Work, nothing you would not want your wife/husband, your girlfriend/boyfriend, your mother or your kid sister seeing on your screen.
6. Any personal attacks, any spam, any advertising, any trolling, or any abuse of the rules will result in your account being removed.
7. Not everyone's first language is English. Be understanding.
Please respect the community and respect each other. We are of many cultures so remember that. Don't assume others understand you are joking, don't belittle anyone for taking offense or being thin skinned.
We are a community for software developers. Leave the egos at the door.
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
modified 16-Sep-19 9:31am.
|
|
|
|
|
Does a hard of hearing dog go to the vet to get tutored?
"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!
|
|
|
|
|
Only if it's in grades K-9;
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
There was a Far Side cartoon with one dog bragging to another that he was going to the vet to get tutored.
EDIT: Found a link[^] to it.
|
|
|
|
|
1985? That's pre internet!
"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!
|
|
|
|
|
All the classic stuff is pre-internet!
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."
|
|
|
|
|
From where do you fetch this thoughts? Heel go where he nose there's a meal waiting - bitch brings up other possibilities as well.
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Yes. It learns that cars are bad for its health.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
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.
Basically, this is what i get when it works:
# # # # # # # #
# # # # # # #
# # # # # # # #
# #
# # # #
# #
# # # #
# #
# # # #
# #
# # # #
# #
# # # # # # # #
# # # # # # #
# # # # # # # #
This works for rgb888 (24-bit), mono1 (1-bit) and rgb565 (16-bit). rgb666 (18-bit) however, is being truly evil:
# # #
# # # #
# # # # # # # #
# # # # # # #
# # # # # # # #
# # # # # # #
# # # # # # # #
# # # # # # #
# # # # # # # #
# # # # # # #
# # # # # # # #
# # # # # # #
# # # # # # # #
# # # # # # #
# # # # # # # #
What gets me is the bits that it *is* clearing. Look at the empty run above. How the elephant did it get that? It's not even starting in the right place.
So now I know where a spare day of my life is going.
Never make rgb666 pixels. They are truly satan's children.
Real programmers use butterflies
modified 2hrs 20mins ago.
|
|
|
|
|
The PDP-10 had 36-bit words.
|
|
|
|
|
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"
Real programmers use butterflies
|
|
|
|
|
Example code? Does there really exist graphics hardware that has a pixel every 2,25 bytes in its framebuffer?
|
|
|
|
|
Wikipedia seem to think so. Mostly used in less expensive LCDs, which seems likely to be the displays attached to the types of devices the OP seems to have been targeting recently.
Keep Calm and Carry On
|
|
|
|
|
Yes indeed. In fact, as I recall the ILI9341 display adapter supports 18-bit color.
The place I had seen it before on the PC was the old VGA 320x200x8bpp mode where the 8 bit pixel was an indexed color into a palette. The palette colors were 18 bit.
Real programmers use butterflies
modified 2hrs ago.
|
|
|
|
|
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.
|
|
|
|
|
I don't have the driver code built yet. I'm building the graphics end of it right now.
At any rate, supporting 18-bpp wasn't even my initial goal.
It's just that you can do this:
using bgr888 = pixel<
channel_traits<channel_name::B,8>,
channel_traits<channel_name::G,8>,
channel_traits<channel_name::R,8>
>;
using rgb565 = pixel<
channel_traits< channel_name::R,5>,
channel_traits<channel_name::G,6>,
channel_traits<channel_name::B,5>
>;
using gsc8 = pixel<
channel_traits<channel_name::L,8>
>;
using mono1 = pixel<
channel_traits<channel_name::L,1>
>;
using rgb888 = pixel<
channel_traits<channel_name::R,8>,
channel_traits<channel_name::G,8>,
channel_traits<channel_name::B,8>
>;
using rgb666 = pixel<
channel_traits<channel_name::R,6>,
channel_traits<channel_name::G,6>,
channel_traits<channel_name::B,6>
>;
using pixel_type = rgb666;
using bmp_type = bitmap<pixel_type>;
pixel_type p = color<pixel_type>::light_green;
uint8_t buf[bmp_type::sizeof_buffer(16,16)];
bmp_type bmp(16,16,buf);
bmp[point16(7,7)]=p;
p = bmp[point16(7,7)];
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)
Real programmers use butterflies
|
|
|
|
|
The Univac 1100 series did, and 6 characters to a word.
|
|
|
|
|
Same with the PDP-10 when using SIXBIT[^]. I guess Univac did something similar.
|
|
|
|
|
What does that make a char in C?
6 bits?
I count on char being 8 bits in my code quite often.
Though to be fair when I do, it's usually uint8_t or int8_t that I'm using.
Who the elephant has time for a 6 bit character? I knew there were machines with unusual word sizes but this is ridiculous.
Real programmers use butterflies
|
|
|
|
|
Only those of us whose names end in -saurus wrote code for a PDP-10 or Univac.
The PDP-10's memory was limited to 256K words, so a little over 1MB. Hence things like SIXBIT.
I'm guessing that there were versions of C written for it while it was still in use, and a char must have been 8 bits. It did support ASCII, but I don't remember whether that was 7-bit or 8-bit.
|
|
|
|
|
It looks to me like it is the code that multiplies up the y direction. It seems to be giving values about 1/16 as large as they should be.
Good luck, brave programmer.
|
|
|
|
|
It was kind of. I was doing an add after a multiply instead of before it because I forgot some parens.
const size_t offs = ( (dstr.top()+dy)*dimensions().width+dstr.left() ) *pixel_type::bit_depth;
Real programmers use butterflies
|
|
|
|
|
It's the little things in life.
Jack of all trades, master of none, though often times better than master of one.
|
|
|
|
|
That describes much of programming perfectly!
|
|
|
|
|
Blowing a bit of smoke (pun?):
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.
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|