|
- Buy sufficient amount of shares
- Fire the board
- Chill
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
|
|
At the end I got a DELL u4025qw and it's amazing, after scaling fonts to 120% the text is perfectly readable, 120Hz + 140W output in the thunderbolt port, with all that ports in the included dock station makes it perfect for work.
Again, thank you all!
modified 6-Sep-24 7:04am.
|
|
|
|
|
Wordle 1,175 5/6
⬜⬜⬜🟨⬜
⬜⬜⬜🟨🟨
⬜🟩🟩⬜⬜
⬜🟩🟩⬜⬜
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 1,175 4/6*
⬜⬜⬜⬜🟨
⬜⬜🟨🟨🟨
⬜🟩🟩⬜🟩
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 1,175 3/6*
⬜🟨⬜⬜🟨
⬜🟨🟨🟨🟨
🟩🟩🟩🟩🟩
"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!
|
|
|
|
|
⬜🟨⬜🟨🟨
🟨🟨⬜🟨⬜
⬜⬜🟨🟨🟨
🟩🟩🟩🟩🟩
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
Wordle 1,175 4/6
🟨⬛🟩⬛⬛
⬛⬛⬛⬛⬛
⬛⬛🟨🟨⬛
🟩🟩🟩🟩🟩
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
The shortest horror story: On Error Resume Next
|
|
|
|
|
Wordle 1,175 6/6
🟩⬜⬜🟨⬜
🟩⬜🟨⬜🟨
🟩🟩⬜🟩⬜
🟩🟩⬜🟩⬜
🟩🟩⬜🟩⬜
🟩🟩🟩🟩🟩
Scary one, was left with too many options!
|
|
|
|
|
Wordle 1,175 6/6*
⬜⬜⬜🟨🟨
🟩🟩🟨⬜⬜
🟩🟩⬜🟩⬜
🟩🟩⬜🟩⬜
🟩🟩⬜🟩🟨
🟩🟩🟩🟩🟩
Happiness will never come to those who fail to appreciate what they already have. -Anon
And those who were seen dancing were thought to be insane by those who could not hear the music. -Frederick Nietzsche
|
|
|
|
|
Wordle 1,175 3/6*
⬛⬛⬛🟨🟨
⬛⬛🟨🟨🟨
🟩🟩🟩🟩🟩
|
|
|
|
|
Wordle 1,175 3/6
⬛⬛⬛🟨🟨
🟩🟩⬛⬛🟩
🟩🟩🟩🟩🟩
Ok, I have had my coffee, so you can all come out now!
|
|
|
|
|
Wordle 1,175 X/6
⬜⬜⬜⬜🟨
🟨🟨⬜⬜⬜
🟩🟩⬜⬜⬜
🟩🟩🟨⬜⬜
🟩🟩⬜🟩⬜
🟩🟩⬜🟩⬜
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Wordle 1,175 4/6
⬜🟨⬜⬜⬜
⬜⬜🟨🟨⬜
🟨🟨⬜🟨🟨
🟩🟩🟩🟩🟩
Within you lies the power for good - Use it!
|
|
|
|
|
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).
|
|
|
|
|