|
Codeium makes me laugh. It figures out even anticipates the boiler plate code I am attempting to write and does it for me. I can not but laugh in amazement. By the way am becoming proficient w/ Vim. Between Codeium and Vim I am sometimes surprised the code does not appear fully formed at a touch of one of Vim's magic buttons. By the way I have been watching TV series "StartUp". Close up shots of the great code reveals it to be nonsense and not even compileable. The producers should have asked Codeium for help.
"I want to sing, I want to cry, I want to laugh. Everything together. And jump and dance. The day has arrived - yippee!" - Desmond Tutu
modified 6-Sep-24 5:30am.
|
|
|
|
|
Hi rubber ducks! 
My graphics library has stateless raster operations:
draw::filled_rectangle(destination,destination_rectangle,color,optional_clipping_rectangle)
draw::ellipse(destination,destination_rectangle,color,optional_clipping_rectangle)
etc
where destination is the drawing surface, be it a bitmap, a viewport or whatever.
i really want my vector operations to work that way too, but there are underlying complications.
basically, you have to build out paths with multiple calls, and then you can render that.
I can't decide how I want to expose the canvas - which I need to have bound to a "destination" (as above)
a template class called canvas? (the destination is arbitrary, with no common base, so must use source level linking eg: templates)
a class with a bunch of template methods? (actually thinking about it this won't work in this case)
If I use the template class I can potentially do like this:
auto canvas = draw::canvas(destination,destination_rect);
at which point I could do
canvas.arc(...)
for example
I don't like that it works so different than my raster functionality. It's stateful, but I'm not sure I can avoid that
I'm not sure if I like binding it to a destination using the draw:: class (draw::canvas)
And there are a bunch of details that I need to work out like
Do I combine stroke and fill data in one structure, or do I require you to define strokes and fills using multiple calls? (my prior SVG stuff worked the first way, pluto works the latter way, but I can make it work the first way)
I have so many questions spinning around in my head, and it's stopping me from moving forward.
I still think if you're working on software correctly, this is part of the process - better to get hung up in design then to paint yourself into a corner during implementation.
Still, it's frustrating.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Prolly not what you fancy, but if it gives you any ideas...
The way I picture vector graphics is basically an infinite 2D-canvas.On that, we draw all the ellipses, rectangles and cats. The rectangle only comes to play when we render.
Canvas canvas;
draw::ellipse(canvas, bounding_rectangle, color); draw::shape2D(canvas, shape, color);
canvas.render(source_rect, raster_destination)
Personally, I would cut the mooring to draw:: and even
Canvas canvas;
canvas.ellipse(bounding_rectangle, color); canvas.shape2D(shape, color);
canvas.render(source_rect, raster_destination)
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
That's essentially how i envision it to work. There is no explicit render method however, due to the way it functions.
The issue with the color is you don't just have one. You have potentially a stroke color and a fill color. Or you can do linear and radial gradients or textures. It gets complicated.
The way it works currently in pluto, is you call series of functions (in straight C) to set the various color properties for stroke and fill, or textures or whatever. Then you render your shapes, more or less.
I'm thinking of making it more like your way, except if I do the parameter list will be struct heavy due to all the options. Still not sure.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Adding, the only way I could cut the binding to draw is to provide an alternative mechanism to bind to a destination and destination rectangle for the canvas.
The canvas itself cannot actually render without something to render to, like a bitmap.
The issue is the backing draw target can be of any sort of color model or pixel format. RGB8888, RGB565, etc. Each different model has a different type signature, so the canvas class would have to be a template, and a binding template function makes it easier to attach a canvas to a surface.
draw:: is currently where people go to do all drawing operations on a draw target, so it makes at least some sense to use draw:: to bind, depending on how you look at it.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
After writing graphics code since the late 80s, I'm not quite sure what you are attempting to achieve other than code purity.
Raster - draw into the backing bitmap using primitives, slap it into the display buffer. Move along.
Vector - never had the need for it, overly complicated, could use raster all day long. Mind you, I was almost always working on a fixed resolution display. Examples:
- customer had a 1280x104 monitor as dictated by the contract. I did not go out of my way to hard code stuff.
- customer had 1024x768, 800x600, 320x240 - all of which required raster operations for performance.
Might I suggest you are overthinking? Don't get me wrong, if you want to be flexible enough to target every random device that hits your market, knock yourself out.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
The arbitrary pixel formats for bitmaps is already baked into my library.
The native pixel format for all of my vector graphics is RGBA8888 (32-bit RGBA). Raster has no native format. It can draw in any format. I had to limit the vector graphics canvas to one color model and bit depth both to enforce that it always has an alpha channel for the pixel as well as to simplify design and use. Vector graphics can do things like source dodge colors, not just strict alpha blending so there's additional complexity. I decided to forgo all of that and fix the pixel format to RGBA8888
The reason I went with vector graphics is both to support SVG and as important to allow for anti-aliased graphics. My raster cannot do it, because it *can* alpha-blend. Unfortunately algorithms like the Wu algorithm don't work with alpha-blending. The only solution I've found is full vector graphics. Fortunately 32-bit MCUs can handle it, as long as you don't go crazy with it.
But yeah, this library is kind of for every random device that hits the market.
It runs on PC
Arduino
ESP-IDF
Zephyr
Pretty much anywhere C++17 can compile
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Okay, I concede that your requirements are a bit more than mine ever were.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
|
raddevus wrote: (don't have to download)
...but why wouldn't you, if one has any interest in it at all? Dead links, things getting taken down...
raddevus wrote: I couldn't understand BASIC programming
As a kid growing up in French, I understood the examples better than the English explanations.
I had a 64, a 64C, then a 128 (in that order). I remember my folks sold my original 64 to some acquaintance of theirs, but I cannot remember where the 64C and 128 ended up (nor my collection of apps/games on a few hundred floppies).
|
|
|
|
|
Great story, thanks for sharing.
I had a Coleco Adam (and one class in High School where we used a TRS-80 to run/learn BASIC) and I would type programs in from magazines & invariably they wouldn't work because of some typo (in the magazine or typed by me). Then I'd be stuck.
|
|
|
|
|
My first computer was an Altair, but the C64 soon followed.
Ah fond memories!
A home without books is a body without soul. Marcus Tullius Cicero
PartsBin an Electronics Part Organizer - Release Version 1.4.0 (Many new features) JaxCoder.com
Latest Article: EventAggregator
|
|
|
|
|
That's truly amazing you had an Altair!
That really goes back & could/should probably be considered the 1st PC.
Just blinkenlights though. 
|
|
|
|
|
Switches and lights, that's what made the C64 so amazing.
A home without books is a body without soul. Marcus Tullius Cicero
PartsBin an Electronics Part Organizer - Release Version 1.4.0 (Many new features) JaxCoder.com
Latest Article: EventAggregator
|
|
|
|
|
I was gifted a Commodore 64/Plus 4 which was not compatible, and mine had some ROM errors.
I never really did much with it. I had an Apple ][gs at the time - hateful thing, and that's what I was coding on.
They have emulators out there, but it's something I'd rather keep well in the rear view mirror.
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 had an Apple ][gs at the time - hateful thing, and that's what I was coding on.
I had an Apple IIc, back when it was new, and only $3800. What a heap of steaming dingo entrails that was; I couldn't wait to dump that thing. That was my first store-bought computer, and there have only been few since that I didn't build from scratch - none of them have ever again been made by Apple.
Will Rogers never met me.
|
|
|
|
|
Roger Wright wrote: I had an Apple IIc, back when it was new, and only $3800.
Nice to be reminded that "overpriced" has always been part of Apple's history.
And that was in 70s/80s money.
|
|
|
|
|
I started with a Spectrum 128k, had to load games like "Panic in the orient express" from cassettes and started programming basic from the book that came with it, explaining to my elder brothers what it "meant" a bit later.
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Specifically:
I'm looking for a USB-C hub that has nothing but USB-C ports. I have a crap-ton of old(er) USB hubs that have 4, 8, or even 10 USB (type A) ports, supporting up to USB 3.0, but I haven't yet encountered an equivalent that has USB-C only. No matter what I search for, I can only find hubs/docks that also offer HDMI, Ethernet, etc. I need something much simpler. I want wall-to-wall USB-C.
Assuming these things are out there - should they be suitable for monitors that (supposedly) only need a USB-C connection to a PC (plus maybe a wall wart, which I suppose is fine)...?
I have the room so I could line up 3 such 15" monitors above (or below) my main display, a 40" 4K TV hooked up to my PC via HDMI. I obviously don't have an infinite number of spare HDMI ports, so I'm wondering if multiples of those USB-C monitors (+ hub) might be a viable option. Do I have unrealistic expectations?
I'm getting tired of having some windows constantly getting buried by other windows and having to dig them out 100 times a day. I'd be perfectly happy if I could dedicate a (smallish) monitor for Teams, another for my email client, another for notes and such, and leave my other monitors free for "everything else".
|
|
|
|
|
|
Well it certainly looks like it.
No idea though whether it would work with USB monitors. Based on what I've been reading, it's not necessarily just because the cable will physically connect that it'll be able to carry video.
At least now I know for sure they do exist.
OTOH - Your link shows it as "currently unavailable".
[Edit]
Amazon.ca shows it available...for CAD$185.25. Wut, for a hub??
|
|
|
|
|
|
RickZeeland wrote: Otherwise you would need an "MST hub"
That looks like the technical term I was missing. Thanks for that.
|
|
|
|
|
If you're looking to daisy chain monitors, take a look at DisplayPort systems. DisplayPort was designed to daisy chain monitors.
|
|
|
|
|
CalDigit TS4 Thunderbolt 4 Dock - 18 Ports, 98W Charging, 3x Thunderbolt 4 40Gb/s, 5 x USB-A, 3 x USB-C (10Gb/s), 2.5GbE, Single 8K or Dual 6K 60Hz Displays, Mac, PC, Chrome Compatible with 0.8m Cable - Newegg.com[^]
This thing also has that thing of which has now bespoken itswelf into relative time and space, since out last RSS crepusculation.
Yes, it does seem expensive but ... what has anything got to do with (subject that shall remain unspoken)?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
