|
|
130$  
Does the book do the knots for you or what?
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.
|
|
|
|
|
I learned a lot of useful stuff from that many years back, from a library copy.
My wife got me a copy last year for a gift. It's not just informative re how to tie the knots, but the stories and explanations of what each is used for. A bit of science in it too.
Totally worth it (though I think you can get a good condition copy of it for a better price)
Best!
|
|
|
|
|
Even if you do not plan to learn to make all these knots: You can enjoy Ashley as a book of art. The drawings are beautiful - he was a true artist in his use of the pen as well as in his use of the ropes.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
cool link. Thank you
There are two that I do more or less by instinct, because of the car trailer. But I will ditch and replace them with some I have seen in the web, as far as I learn them.
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.
|
|
|
|
|
Don't try to rope me in
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
|
|
|
|
|
Next thing you know you'll be knitting and doing crochet.
|
|
|
|
|
And the problem with that is ... what?
My daughter has become an expert knitter, and she's teaching me how to crochet. I'm learning as a way to improve my dexterity in the wake of arthritis, vision defects, and minor tremors due to medication.
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: I'm learning as a way to improve my dexterity in the wake of arthritis, vision defects, and minor tremors due to medication.
And that's a really good idea. My father makes Sudoku to train focus / concentration and short term memory (he is 84)
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.
|
|
|
|
|
Nelek wrote: And that's a really good idea.
Thanks  . The OP's post got my knickers in a bit of a twist  .
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: And the problem with that is ... what?
I re-read my message, and I fail to identify any allusion to any sort of "problem".
|
|
|
|
|
Hmm. I'm guilty of assuming you're male, and most guys think knitting/crocheting are feminine crafts. I'm used to getting odd looks when I mention it. My apologies.
Software Zen: delete this;
|
|
|
|
|
You've correctly assumed I'm male (let's not get into the pronouns thing)  and you're also correct in assuming most guys think of those as primarily female activities - because it's absolutely true. That doesn't mean in any way however that a male with that skill set is somehow "wrong". Being wrong for knowing something? Wut?
It is a skill I admire - I have zero knowledge on the topic, and (as a software developer thinking in terms of repeating patterns) I find it fascinating. I've always figured someone might be able to teach me how to knit something into a straight line, but how you then turn this into a shirt or a sock or a tuque is just something that still blows my mind. Crocheted table centerpieces, with those intricate patterns? That's insane.
And when you stop and think about it, at a fundamental level, I'd make the argument that learning how to tie knots has to be similar to very, very low-entry level knitting. Isn't it? That's where I was going with my initial post (although probably in a completely inept way).
|
|
|
|
|
dandy72 wrote: That doesn't mean in any way however that a male with that skill set is somehow "wrong"
I've been fascinated with knitting/crochet since I was a little kid. My great-grandmother crocheted a lot, and she taught my mother. Ironically, my daughter learned both from her mother-in-law, and is now teaching me.
Software Zen: delete this;
|
|
|
|
|
too repetitive
camping and fishing are my adventures in applied knotting
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
|
I've been working on my htcw_gfx 2.0 project and I got into the major shift for some reasons that were important to me, but maybe not the users of my library.
There were parts that were brittle, and there were areas that were going to snowball if I didn't make major breaking changes before I released any major libraries dependent on it - and I already have one of those, but it's not even 1.0 yet, so I'll probably move that to 1.0 and update it right after I finish with gfx.
I realized that most of what I'm doing is pruning and cleaning up.
That's all great, but from an end user standpoint, it doesn't add a lot of significant value, and that's what's got me hung up, in terms of when to call it good enough and release it (breaking all existing 1.x projects in the process)
I made little notes for myself in terms of what I've accomplished so far, in pursuit of making a change document, but there's not a lot there:
Major changes w/ htcw_gfx 2.0
Cutting floor:
Complete removal of driver integration, so no more "async" draw destinations, or write only draw destinations, etc, greatly simplifying the code.
Rationale: Even with those facilities in place, it's still faster to draw to bitmaps and then send bitmaps to the screen. It takes a little bit more memory, but it's always worth it.
On the other hand, the zoo that was the template specialization chains necessary to fully utilize a display device (batching, async, etc) was creating a maintenance problem.
Rearrangements:
svg_doc has been superseded by svg_image
All images (png,jpg,svg) derive from a common base class (gfx::image) and you can add more
All fonts (ttf, vlw, fon) now derive from a common base class (gfx::font), and gfx::font has been superseded by gfx::win_font
Primary additions:
Text and images can now be post-processed during the render by using font.draw() and image.draw() with their respective callbacks.
Text encoding is now pluggable, and should present no huge changes for anyone, but allows for adding additional encodings other than latin1 and utf8
Of that list, I only have two primary additions and only one that is likely to be used by more than one or two people.
So aside from text and image post-processing and a bit cleaner interface, what value am I really adding here?
Keep in mind these changes are breaking breaking breaking, and for them to not be involves dragging along a lot of dead compatibility code on an embedded library. They even break the gfx website's header generator utility, and my web guy isn't really available to me right now.
So it's a big change. I'm eager to release, and at the same time I want to be cautious and have all my ducks in a row.
As important, I want to add significant value to a major version change, from the perspective of the users of my lib.
Trouble is, my library already does quite a bit, and I'm sort of out of ideas. I considered adding a couple of tweaks to bitmaps, but there was nothing pressing.
Have you ever run into a situation like this? Especially if it's an open source project or otherwise project you own? What do you do? I'm about paralyzed with this, and i feel like i've got competing goals i can't reconcile.
And in terms of adding value, if anyone has ideas, I'd be interested. Just concepts. One big thing I wanted to add was anti-aliased draws, but I have not figured out how to combine that with alpha-blending using the algorithms i understand without either (a) ruining alpha-blending or (b) using a lot more memory. so i've shelved that.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Hmm... for anti-aliased draws maybe that could be done with smaller memory footprint by breaking the framebuffer into smaller rects. Maybe it'll go janky along the seams but maybe not.
Maybe implement some kind of filters similar to what Reshade does. I think this can possibly include AA. I'm not sure how useful these sorts of filters would be in context, but it is a feature.
|
|
|
|
|
It's not necessarily that it would be seams because it's not quite like bicubic resampling, but there is a wrinkle in terms of breaking it into parts as you suggest.
The issue is strictly the edges, and I end up drawing the edge pixels in the same place more than once, which if you understand how alpha blending works, utterly nukes it because the old pixel bleeds through the new one
What I would need to do is just hold a bitmap to encase the edge portion i'm drawing. Maybe even like 8x8 or something really small, but where and when to do it in the code is the part I'm not sure I can wrap my head around.
I should attack it more.
One reason I haven't worked harder at it, is I support building SVGs directly to an in-memory binary, ready-to-render form without ever going to XML. It does all of the anti-aliasing and alpha blending but it's not as fast as I'd like.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
What if you only AA'd something like 95% of the image?
The other 5% is margin of untouched pixels between the AA rect splits?
I'd expect maybe a weird sort of screen-door-like effect on the image but it might still look better than the source and the specifics might mean it's not noticeable at all.
|
|
|
|
|
I mean it seems like the same problem as splitting it up otherwise, in that's just confusing to know where and when to do it exactly.
LVGL creates masks for everything it draws, and it's kind of the gold standard in embedded for both fast and fancy graphics. I've tried to decipher that code to get an inkling of how it works, but it's C and there are function dispatch tables and such in the rendering process that make it impossible to follow.
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 want to add significant value to a major version change
Maintainability is a significant value. Maybe one of the greatest of all values, because it makes it far easier to go forward. Sounds like you've done good - congratulations! ![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif)
|
|
|
|
|
It is for me, but in terms of the exposed functionality of the library, very little has changed. I want to add value for the end users, not just myself.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
My understanding is that you are the sole developer of this library. Furthermore, users of 1.0 are not paying you for maintenance/support. Even though it's really cool that you have users and you want to make life easy for them, enhancing maintainability is an important major change (and not just for you).
I think you can absolve yourself of any guilt for not including any great new features for your users in 2.0. Ease of maintenance also helps your users. Bug fixes and future new features come quicker with fewer defects. Besides, if you're going to make a breaking change better to do it between versions 1 and 2 (more understandable/forgivable) rather than 6 and 7 (though, when it needs to happen, it needs to happen).
As long as releasing 2.0 doesn't force 1.0 users to upgrade they can just stay with 1.0 until it behooves them to upgrade and deal with the breaking changes. If this is true I think you can release 2.0 when you are ready. It's okay to leave the bitmap tweaks, anti-aliasing and other stuff for a later point release. (We'll hope they won't also cause breaking changes.)
You just need to document that 1.0 is as complete as it will get, new users should use 2.0, and upgrades will break existing code. 2.0 doco probably should mention it breaks existing 1.0 code as well as include some examples on how to perform those changes. Just the biggies, it doesn't need to be exhaustive. (Well duh, 'nuff said, I'm preaching to the choir here.)
Just my 2 cents, take it for what it's worth. 
|
|
|
|
|
The major values you are adding are:
1) Users who pick up your library now will get the new version and will get fewer breaking changes down the line.
2) Users already using your library will have longer to adapt to the new version, giving them more time to experiment with it and align it with their releases.
As a developer I would not consider these two points "small".
Just make sure you communicate clear what is in the release.
modified 29-Aug-24 14:00pm.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
