Well, it is what is done on several tiler architectures, and it generally works just fine. Normally your computations of the position aren't really intertwined with the computation of the other outputs, so dead code elimination does a good job.

BC1-3 are like that, but BC7 is far, far more complex. The search space is huge.

It works just fine and is natively ARM, since a year or so.

Great, thanks for the feedback.

What about implementations? libpng seems pretty dead, 1.7 has been in development forever but 1.6 is still considered the stable version. Is there a current "canonical" png C/C++ library?

I mean, if the spec has been stable for two decades then maybe there just hasn't been much to fix? Especially since PNG is a relatively simple image format.

Seems that logic does not apply to jpeg though.

For modern C/C++ PNG implementations, consider lodepng (header-only), stb_image/stb_image_write (single-file), or libspng (active fork focused on performance and security) as more actively maintained alternatives to libpng.

libpng updates are either already landed or nearly landed.

Parody account

Video is real though

How do you know?

It's the same video that is used at [1]. It likely originated from an unnamed Indian news website.

[1] https://www.wsj.com/world/india/air-india-plane-carrying-242...

Great stuff!

Small UX thing: Make it so you can just click a word to fill in the next empty spot, instead of having to drag, similar to when building sentences in Duolingo. Especially when not on a touchscreen, having to drag is pretty painful and reduces accessibility.

Aaa, you saved me, thought it's broken, but you have to drag this thing!

ps. video shouldn't loop as default, it's annoying.

I actually like the default looping. When I’m learning and trying to train my ear, I need to listen to the phrase over and over and it’s helpful to not have to click play again.

I also don't read all of the terms and conditions, and I feel free to get mad at unreasonable items that I discovered while using the product. Fight me.

FYI: when people say "X is default and it's annoying", it doesn't necessarily mean that they don't know how to turn off X.

You don't need to be so combative in this feedback thread for someone's language learning app.

It’s not clear that those controls are for the video on first glance. I thought they referred to the exercise itself (eg, restart exercise).

I think you’re not thinking like a new user.

I've changed the UX to be click & drop instead of dragging it. Much better on mobile (and desktop too).

Will do. I also like the click to place more than dragging & dropping.

Function calls are very fast (unless there's really a lot of parameter copying/saving-to-stack) and if you can re-use a chunk of code from multiple places, you'll reduce pressure on the instruction cache. Inlining is not always ideal.

Perhaps the use cases are different (heavily data-parallel), but FWIW I do not remember many cases where we were frontend bound, so icache hasn't been a concern.

Not sure if you care at this point, given that you stopped working on project, but there's a better way to find the ray direction for each column than using sin/cos for every one, which will also get rid of the slightly warped look:

Calculate the two vectors from the camera at the very left and right of the screen (using your fov angles and sin/cos, that's fine). Then, to find the ray direction vectors for each column, interpolate linearly between your left and right direction vectors, and possibly normalize the resulting vectors if your ray walking algorithm requires it.

This will create a perspective that integrates tightly with sprites that you 3D project the usual way, and lines will stay straight lines.

In my experience there are two mistakes people sometimes make that leads to the fisheye lens look. The first, as parent mentioned, when calculating the ray directions you should linearly sample a line rather than interpolating view angles. Second, when doing per-column perspective division, you should divide by dot product of the forward vector and the difference between the ray intersection and the camera location. Often if someone is making the first mistake they are also making the second.

Following this will give you the normal pinhole camera 3d projection that we all expect to see from a 3D game.

Rule of thumb I found as a beginner in 3D graphics: any time polar coordinates seem like the obvious solution, there's usually a better way.

Of course I still care :) Thank you for sharing this technique, I will try it out.

Pack Z and 32-bit color together into a 64-bit integer, then do an atomic min (or max with reversed Z) to effectively do a Z-query and a write really, really fast.

Nanite writes out the ID of the primitive at that pixel rather than the color, but otherwise yeah that's the idea. After rasterization is done a separate pass uses that ID to fetch the vertex data again and reconstruct all of the material parameters, which can be freely written out without atomics since there's exactly one thread per pixel at that point.

What else would it possibly mean?

k is very common shorthand for kB, at least historically.

14000 lines of assembler?

Something along that line (oops, pun not intended). I was thinking 14000 of something, not sure exactly what that is, until I realized it was kind of obvious.

Indeed a decade ago I would not have any doubts. Using "k" to refer to "kB" was much more common.