And both are wrong since the values would have to be in a linear color space for for the compositing math to make sense. But in some non-linear space to be useful when mapped to 0..255 (e.g non-linear sRGB).
Which happens right after the Porter-Duff Over operator above -- a smoking gun. Which one is it gonna be?
I.e. the display transform is omitted from this and the math involved with the latter makes your whole argument moot.
It can't be expressed well enough with bitshifts to keep your purported 10x speedup anyway (and which I strongly doubt btw).
And lastly: in a software renderer that stuff is usually <0.01% of the compute in the absolut worst case.
P.S.: I'm speaking from 30 years of experience with software rendering in the context of VFX.
From what I gather these are built-in types the compiler knows?
'i32', not 'I32' but 'List' not 'list'? In Rust the case is clear cut: built-ins that the compiler 'knows' are lowercase, types expressed in Rust itself are PascalCase.
Roto seems to mix this?
Reads like Rust but then "differs subtley" where it (seemingly?) does not matter at all.
What is the rationale? I'm not complaining, Roto looks great. I'm considering swapping my Koto integration in my project out for this. :)
I'm just genuinely curious. From the outside the above smell like "just because" decisions.
This is something we've been backpedaling a bit indeed. 0.11 changed some things to look a lot more like Rust. The reason for this being different in the first place is that were not trying to make Rust-but-simpler necessarily. Or target audience with Rotonda is also not Rust programmers. So we've been exploring different syntax options.
Regarding the List type, as we optimize that, it will probably become a different data structure from a Vec. Also in the Roto-Rust boundary, you cannot pass in a normal Vec. So different names male sense there.
Regarding the case, small primitive types are lowercase. String and List are heap allocated and therefore somewhat different. I'm open to changing that but there is some logic to it.
Ive seen this in the past with some phones (it actually gave me an idea for an advanced level), but I was able to fix it, although it seems the fix was not complete.
I would add that Rust also has naming guidelines and sticking to them removes or at least minimizes the occurrence of another common topic of discussions on PRs/reviews.
In the article, if you were to mention & follow them GetUser() in Go becomes user() in Rust[1], not get_user().
This matters a lot. And yeah, it seems this supports neither and it is unclear if operations happen in linear light at a bit depth of at more that 8bit/channel.
If they don't, most of them will produce subtly wrong results.
Two types of spaghetti (regular No. 5 and gluten-free) produced by the Barilla company (Italy) were purchased in a supermarket."
Are you kidding me? You did a study and tested /one/ kind of gluten-free pasta?
There are so many different kinds from different companies. One type from Barilla is nowhere near representative to draw a useful conclusion.
Especially as unlike many other gluten-free pasta products it lacks an important binding agent.[1]
As someone with a gluten-allergic partner I regularly make pancakes and bake bread with (Italian!) rice-based flour.
And they are difficult to distinguish from the flour based ones, in taste, texture, fluffiness and and structural integrity.
The secret to this is xantham gum. It acts as a binding agent in gluten-free baking, providing the elasticity and stickiness that gluten typically offers. It helps to hold ingredients together and improve the texture.
I learned this when eating excellent gluten-free pinza, in a small place in Catania, Sicily, whose owner has celiac disease.
Ah yes, as far as pasta goes there is also research about this ofc[2]
When I lived in Adelaide, Australia 2006 or 2007, flexible-neck LED lamps that you plugged into an USB port to have light on your keyboard (backlit keyboards were not the norm on laptops) were a novelty item.
People simply didn't /know/ about them/that they existed at all.
I went to a computer/electronics shop in town and asked for them.
The guy told me: "We don't stock them because people don't ask for them."
Like the author of the article, I write C/C++ since 30 years. Mostly close-to-the-metal code around computer graphics. Actually: wrote.
After switching to Rust five years ago I agree with all the Rust hipsters as far as disliking those languages go.
I just don't talk about it a lot. If every Rust person I know that was a C/C++ developer before was as outspoken about what they think of the latter, you'd see that these people are a majority.
We're just old hands who like to use stuff that works. And most of us don't get attached to code or languages.
It's also difficult to admint to yourself that you were never in command of a language as far as UB/other footguns go, as much as you thought. Or ever, for your enire career. For me that self-realization about C/C++ (enabled by Rust) was a turning point.
Lately you can read about the dichotomy re. AI use.
I.e. developers who define them themselves through what they build/ideas are embracing LLMs; for what they can do.
I.e.: I am what I build.
Whereas developers for whom software engineering is a craft that defines them hate them openly.
I.e.: I am how I build.
Now this seems to suggest to me that maybe Rust developers who openly hate C/C++ squarely belong to the latter group whereas the silent ones belong to the former. It's builders vs programmers. Just different world views.
Also you can not dislike something and still not speak about it. Because you decided to not care.
That is the most important feature this would make me use this over the good old wooden puppet, which is small (10cm). I.e. it travels with me with my drawing utensils.
I guess I am asking: what exactly is the value proposition?
What exactly is inverse kinematics? A short search tells me it is something like "if the hand goes in a certain position and a certain angle, elbow and shoulder must go into these angles", is that it?
Imagine placing the feet on the ground at some location and then pinning them there. Now you can move the hips and the upper and lower legs as well as the knee orientations change to keep the feet planted in the same position.
This image explains it pretty well, you typically chose between Forward Kinematics, or Inverse Kinematics, depending on what you're trying to accomplish and how you want it to look like: https://www.researchgate.net/profile/Ebrahim-Poustinchi/publ... (imagine the robot parts are human limbs, same thing applies :) )
Does it just make it easier to get in a position you want or does it give you more natural looking positions as well or any other benefits? It's pretty fun to play with!
It means that you can lock the end point to a position and figure out the rest of the pose.
Imagine a character walking with forward kinematics. Every time you move the characters hips , you’d have to rotate the leg joints and make sure the foot doesn’t slide. Remember virtual characters don’t have friction.
IK lets you lock the foot in a spot so you can animate the body above it without having to spend time matching the foot position.
In a real world, this is like if you tried to put your hand on a door handle while jumping up and down. It’s easier to keep position when you hold the handle than if you were to just touch it.
It also means you can move the point and the rest of the joints adjust. Want to make your model walk? Just figure out the foot motion and the rest of the details are calculated based on joint range of motion and limb length.
And when you go from float to 8bit you should dither to avoid banding.
If in doubt, error diffusion with a random number between -0.5..=0.5 is fine. 0.5 here is dither_amplitude:
round(255 * input_value + dither_amplitude * random(-1, 1))
See e.g. my dithereens crate: https://crates.io/crates/dithereens
reply