Thinking ahead. Just reflecting on some perhaps "overengineered" code
-
One of the key features of my graphics library is the ability to create arbitrary pixel formats so you can for example, create a bitmap with any kind of color model and memory footprint you like. I thought I was a bit crazy, because most IoT devices are 16-bit RGB if not monochrome. I thought I was overengineering Then along came color e-ink and all of the sudden even my palette support made sense. Then I started doing professional displays on embedded outside the IoT realm and many are 24-bit color.
using rgb24 = gfx::rgb_pixel<24>;
And Bob's your uncle Well then I made an Arduino emulator for the PC, and directx threw me for a bit of a loop because there are 4 channels but one is unused:
// creates a BGRx pixel by making each channel
// one quarter of the whole. Any remainder bits
// are added to the green channel. One channel
// is unused. Consumed by DirectX
template
using bgrx_pixel = gfx::pixel<
gfx::channel_traits,
gfx::channel_traits,
gfx::channel_traits,
gfx::channel_traits;
using screen_t = uix::screen>;Bam! I have not redesigned this feature of my library since its inception in like 2021. It keeps just kicking ass. I do not design with any expectation that what I designed will remain unchanged that far out because it's usually not realistic. I am not that smart. This was all luck.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
One of the key features of my graphics library is the ability to create arbitrary pixel formats so you can for example, create a bitmap with any kind of color model and memory footprint you like. I thought I was a bit crazy, because most IoT devices are 16-bit RGB if not monochrome. I thought I was overengineering Then along came color e-ink and all of the sudden even my palette support made sense. Then I started doing professional displays on embedded outside the IoT realm and many are 24-bit color.
using rgb24 = gfx::rgb_pixel<24>;
And Bob's your uncle Well then I made an Arduino emulator for the PC, and directx threw me for a bit of a loop because there are 4 channels but one is unused:
// creates a BGRx pixel by making each channel
// one quarter of the whole. Any remainder bits
// are added to the green channel. One channel
// is unused. Consumed by DirectX
template
using bgrx_pixel = gfx::pixel<
gfx::channel_traits,
gfx::channel_traits,
gfx::channel_traits,
gfx::channel_traits;
using screen_t = uix::screen>;Bam! I have not redesigned this feature of my library since its inception in like 2021. It keeps just kicking ass. I do not design with any expectation that what I designed will remain unchanged that far out because it's usually not realistic. I am not that smart. This was all luck.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
honey the codewitch wrote:
I am not that smart. This was all luck.
It's not a coincidence that luck always prefers smart people.
-
One of the key features of my graphics library is the ability to create arbitrary pixel formats so you can for example, create a bitmap with any kind of color model and memory footprint you like. I thought I was a bit crazy, because most IoT devices are 16-bit RGB if not monochrome. I thought I was overengineering Then along came color e-ink and all of the sudden even my palette support made sense. Then I started doing professional displays on embedded outside the IoT realm and many are 24-bit color.
using rgb24 = gfx::rgb_pixel<24>;
And Bob's your uncle Well then I made an Arduino emulator for the PC, and directx threw me for a bit of a loop because there are 4 channels but one is unused:
// creates a BGRx pixel by making each channel
// one quarter of the whole. Any remainder bits
// are added to the green channel. One channel
// is unused. Consumed by DirectX
template
using bgrx_pixel = gfx::pixel<
gfx::channel_traits,
gfx::channel_traits,
gfx::channel_traits,
gfx::channel_traits;
using screen_t = uix::screen>;Bam! I have not redesigned this feature of my library since its inception in like 2021. It keeps just kicking ass. I do not design with any expectation that what I designed will remain unchanged that far out because it's usually not realistic. I am not that smart. This was all luck.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
There's a saying "You make your own luck".
-
One of the key features of my graphics library is the ability to create arbitrary pixel formats so you can for example, create a bitmap with any kind of color model and memory footprint you like. I thought I was a bit crazy, because most IoT devices are 16-bit RGB if not monochrome. I thought I was overengineering Then along came color e-ink and all of the sudden even my palette support made sense. Then I started doing professional displays on embedded outside the IoT realm and many are 24-bit color.
using rgb24 = gfx::rgb_pixel<24>;
And Bob's your uncle Well then I made an Arduino emulator for the PC, and directx threw me for a bit of a loop because there are 4 channels but one is unused:
// creates a BGRx pixel by making each channel
// one quarter of the whole. Any remainder bits
// are added to the green channel. One channel
// is unused. Consumed by DirectX
template
using bgrx_pixel = gfx::pixel<
gfx::channel_traits,
gfx::channel_traits,
gfx::channel_traits,
gfx::channel_traits;
using screen_t = uix::screen>;Bam! I have not redesigned this feature of my library since its inception in like 2021. It keeps just kicking ass. I do not design with any expectation that what I designed will remain unchanged that far out because it's usually not realistic. I am not that smart. This was all luck.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
There's a Swedish former ski-star that, among others, had a saying: "The more I prepare and train, the more luck I get" Stefan Stenmark, my translation. Cheers
-
One of the key features of my graphics library is the ability to create arbitrary pixel formats so you can for example, create a bitmap with any kind of color model and memory footprint you like. I thought I was a bit crazy, because most IoT devices are 16-bit RGB if not monochrome. I thought I was overengineering Then along came color e-ink and all of the sudden even my palette support made sense. Then I started doing professional displays on embedded outside the IoT realm and many are 24-bit color.
using rgb24 = gfx::rgb_pixel<24>;
And Bob's your uncle Well then I made an Arduino emulator for the PC, and directx threw me for a bit of a loop because there are 4 channels but one is unused:
// creates a BGRx pixel by making each channel
// one quarter of the whole. Any remainder bits
// are added to the green channel. One channel
// is unused. Consumed by DirectX
template
using bgrx_pixel = gfx::pixel<
gfx::channel_traits,
gfx::channel_traits,
gfx::channel_traits,
gfx::channel_traits;
using screen_t = uix::screen>;Bam! I have not redesigned this feature of my library since its inception in like 2021. It keeps just kicking ass. I do not design with any expectation that what I designed will remain unchanged that far out because it's usually not realistic. I am not that smart. This was all luck.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
You really shouldn't denigrate yourself. You are definitely one of the smart ones on this site.
Bond Keep all things as simple as possible, but no simpler. -said someone, somewhere
Oh, I simply meant that I'm not smart enough to think into the future several years out and design ahead. That was luck, is what I'm saying. :)
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
There's a saying "You make your own luck".
Napoleon's usual Q at promotion time for an officer: "is he lucky?"
-
One of the key features of my graphics library is the ability to create arbitrary pixel formats so you can for example, create a bitmap with any kind of color model and memory footprint you like. I thought I was a bit crazy, because most IoT devices are 16-bit RGB if not monochrome. I thought I was overengineering Then along came color e-ink and all of the sudden even my palette support made sense. Then I started doing professional displays on embedded outside the IoT realm and many are 24-bit color.
using rgb24 = gfx::rgb_pixel<24>;
And Bob's your uncle Well then I made an Arduino emulator for the PC, and directx threw me for a bit of a loop because there are 4 channels but one is unused:
// creates a BGRx pixel by making each channel
// one quarter of the whole. Any remainder bits
// are added to the green channel. One channel
// is unused. Consumed by DirectX
template
using bgrx_pixel = gfx::pixel<
gfx::channel_traits,
gfx::channel_traits,
gfx::channel_traits,
gfx::channel_traits;
using screen_t = uix::screen>;Bam! I have not redesigned this feature of my library since its inception in like 2021. It keeps just kicking ass. I do not design with any expectation that what I designed will remain unchanged that far out because it's usually not realistic. I am not that smart. This was all luck.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
I mean this next statement as a compliment, not a dig. I think you are confusing "engineering" with "overengineering". "Overengineering" would have been adding n-dimensional planes to cover you when holographic (and imagined 4+D graphics were in vogue). Seems you like you made a sound design decision that may have felt too liberal because perhaps you had seen one too many poorly designed graphics implementations. Probably why you went to the trouble of writing your own to begin with. Been a long time since I looked at DirectX, but typically Windows (and quite a few other platforms) use a RGBA model where often you see 8 bits for each (the 'A' is an Alpha channel which is an opacity value). Color models are like opinions ... everyone has one ;-) I haven't looked at your library, but from your example you might be able to use variadic templates to make your 'pixel' definition a bit easier. Or perhaps that would just put you on the path to true overengineering :-) Keep up the good work. Cheers, DL
-
I mean this next statement as a compliment, not a dig. I think you are confusing "engineering" with "overengineering". "Overengineering" would have been adding n-dimensional planes to cover you when holographic (and imagined 4+D graphics were in vogue). Seems you like you made a sound design decision that may have felt too liberal because perhaps you had seen one too many poorly designed graphics implementations. Probably why you went to the trouble of writing your own to begin with. Been a long time since I looked at DirectX, but typically Windows (and quite a few other platforms) use a RGBA model where often you see 8 bits for each (the 'A' is an Alpha channel which is an opacity value). Color models are like opinions ... everyone has one ;-) I haven't looked at your library, but from your example you might be able to use variadic templates to make your 'pixel' definition a bit easier. Or perhaps that would just put you on the path to true overengineering :-) Keep up the good work. Cheers, DL
Thanks. I mean in hindsight, I agree because I used the stuff I engineered for. :) Edit: As far as directx, that's true, except for the format used for the last mile native draw surface. the alpha channel is not used in that situation. I actually do use variadic templates to do my template definitions. (background docs if you're interested: https://honeythecodewitch.com/gfx/wiki/pixels.md[^]) Each pixel has one or more channel_traits that are fed into it using variadic templates. Like so:
// creates an RGB pixel by making each channel
// one third of the whole. Any remainder bits
// are added to the green channel
template
using rgb_pixel = pixel<
channel_traits,
channel_traits,
channel_traits;
// creates an RGBA pixel by making each channel
// one quarter of the whole. Any remainder bits
// are added to the green channel
template
using rgba_pixel = pixel<
channel_traits,
channel_traits,
channel_traits,
channel_traits
;
// creates a grayscale or monochome pixel
template
using gsc_pixel = pixel<
channel_traits
;
// creates a Y'UV pixel by making each channel
// one third of the whole. Any remainder bits
// are added to the Y' channel
template
using yuv_pixel = pixel<
channel_traits,
channel_traits,
channel_traits
;
// creates a Y'UV/A pixel by making each
// channel 1/4 of the whole. Remaining bits
// are added to Y'
template
using yuva_pixel = pixel<
channel_traits,
channel_traits,
channel_traits,
channel_traits
;And here's the actual pixel class.
// represents the pixel base class
template
str