hrydgard

This is just AI slop explaining the very basics of what a pixel/fragment shader is. The usecase is not particularly useful. Doesn't belong on HN.

Got taught this one in Sweden in the early 90s. Not too surprising though, as much of the Swedish school system used to be modeled on DDR...

Maybe a cache coherency issue, where data written by the CPU is not visible to the GPU, without some kind of explicit cache line invalidation, maybe on both sides? Caveat, I don't know much about the memory system on the XBox but this is a typical issue with homebrew code on consoles.

Or you just go ahead and forget that big endian ever existed. It's not coming back.

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.

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?

Parody account

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.

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.

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.

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.

What else would it possibly mean?

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

Nice!

Could save a couple of cycles per iteration by preloading the shift amounts into several GPRs before entering the loop, instead of initializing them just before use.

I think "cover shooter mechanic" refers to ducking behind cover and a system for smoothly shooting from behind it like in Gears of War - or in Winback. This mechanic was not there in Wolfenstein 3D.

It's probably just a very good guess, since that's how it always goes.

oklab might be an even better alternative to LCh:

https://bottosson.github.io/posts/oklab/

Only the user mode part of the driver is replaced, the kernel interface is actually shared between the closed source and the open source driver. So it's just loaded like a DLL/.so and hooked up to the API.

You can have a Vulkan driver that only exposes a video decoder queue and no raster/compute/copy queues, not a problem.

valgrind runs on your unmodified binary, it's asan that needs a separate build.

What dropoff? The newest number is on top.

(Though yeah, there will be a dropoff for sure, it's just not visible here).

There is no good reason to flip the flag dynamically at runtime and apps just don't do that, so flushing the pipeline should be perfectly fine, even in an implementation of the clip control extension.

The Witcher 3 scratches that itch fairly well to tide you over, if you haven't played it, although it is a bit different.

This is old, cute, but simply slow and a really bad idea on modern hardware.

If you generate the rays the linear way instead, you don't even need any correction.

Generate two points which represent the left and right edges of the screen - you'd put them in at say 45 degrees left and right of the forward vector of the player. Then to generate the direction vector for each column of the screen, just interpolate linearly between those two points, and find the vector from the player to that intermediate point.

The animation speed isn't the same for some reason but otherwise it's exactly like back in the day.

The PSX CPU did not even have floating point support. It's nowhere close to a Pentium 90.

Consider ICL instead of LASIK if it's an alternative for the level of vision you have. Super happy, and the procedure was really no big deal.

CPUs haven't replaced GPUs for graphics though, and are very far away from doing it...