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.
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.
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.
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 sort of way outrun it's initial premise: it's lightness channel is inverted compared to every other color space, and it's L has nothing to do with LCH or LAB. It's success brought more intellectual poverty, unfortunately. The initial blog post needs a laundry list of corrections, it goes off the rails when it starts making claims about accuracy based on gradients using CAM16 UCS.
No, it's a really interesting situation, doesn't directly claim to have lightness like Lab/LCH, or that there's something fundamentally good about having a blue-yellow gradient. But the L thing is crucial for WCAG (c.f. article), and designers, and the blue/yellow stuff is interesting.
- it's _not bad_
Its better than HSL in that its lightness is correlated to "true lightness", and it's __much__ simpler to implement than a more complex thing like HCT's CAM16 x L. That's about 500 LOC, versus 15 I'd guess. And substantially faster too, few mat muls in each direction.
- Oklab L is not L:
The problem for engineers and designers: no relation to LAB L*/XYZ Y, so no correlation to WCAG.
The problem on the designers end: it's not a linear ramp in dark to light visually. This usually goes unnoticed in a cross-disciplinary scenario unless you're really going deep into color, designers are used to working under eng. constraints.
- Color space accuracy / blue and yellow gradient:
It's a warning sign, not a positive sign, if a color space _isn't_ gray in the middle of a blue to yellow gradient. They're opposites on the color wheel and should cancel out to nothing. Better to instead note the requirement that you don't want gray gradients, and to travel "around" the colorspace instead of "through" it, i.e. rotate hue to make the gradient, travelling along the surface of the colorspace, rather than going into the color space, reducing colorfulness.
> Oklab L is not L: The problem for engineers and designers: no relation to LAB L*/XYZ Y
That should not be considered a bug by itself. CAM16-UCS lightness J also does not depend only on XYZ Y.
> no correlation to WCAG
Y does not necessarily have to be the standard used by WCAG (see CAM argument). And a stick that's a little skewed is still very well correlated with an upright stick, statistically speaking.
> The problem on the designers end: it's not a linear ramp in dark to light visually.
Now that is the actual issue which has nothing to do with which variables L depends on. The L_r (lightness with reference) derived from L is designed to deal with that: https://bottosson.github.io/posts/colorpicker/
> That should not be considered a bug by itself. CAM16-UCS lightness J also does not depend only on XYZ Y.
I avoided the word bug, I believe. Let's say someone else claims it is. I would advise it is not a bug, but the absence of a feature. And that I'd struggle to come up with a good reason to switch away from HSL without that feature. If you're just picking colors, HSL is fine. The process advantage and magic is built-in "oh I know this color passes a11y with this one without guessing" is ___huge___. At least at BigCo, you can't skip a11y.
> Y does not necessarily have to be the standard used by WCAG (see CAM argument).
Sure, but it is used by WCAG and that's important: see above. Also, there's a reason Y has survived since 1900, and it's not because it's an arbitrary decision.
> And a stick that's a little skewed is still very well correlated with an upright stick, statistically speaking.
I assume it's a reference to the shape of Oklab's L, but I'm not sure if you meant that, so apologies if this sounds aggressive because it's not what you meant / I'm repeating another comment: Oklab's L is not Lab's L, and it's not close, and when you plot Oklab's L versus any other color spaces its very oddly shaped. This isn't a problem for an engineer or color scientist, but it is a problem for a designer.
> Now that is the actual issue which has nothing to do with which variables L depends on.
I agree that if we say "well WCAG could use any lightness measure" and decide we'll switch away from HSL to an arbitrary color space because the science on spatial frequency might be rewritten or WCAG may divorce itself from it completely, that we can completely write off a11y as a non-goal.
> Also, there's a reason Y has survived since 1900, and it's not because it's an arbitrary decision.
1931. And Y is known to be problematic since Judd (1951) and Vos (1978), with the latest approach being the Stockman & Sharpe 2005 "fundamental" redefinition. This error has real bearing on how narrow-spectrum display works.[1]
> I assume it's a reference to the shape of Oklab's L... not close
The "a little skewed" refers to the shape of the L (or CAM "J") axis projected into the 3D XYZ space, not how the values are scaled in 1D (which I have addressed separately as L_r). They will not perfectly match the Y axis and appear bent, even skewed, because they don't just mathematically depend on Y. But they will be quite close and score a good (> 0.90, I guess) correlation coefficient over a set of color samples because they are trying to model the same aspect of human vision. That is still good correlation, and given the limited nature of gamuts you'd still be able to derive some sort of "this much difference means at least this much ratio".
While it's not perfect, I've been using oklab and oklch (depending on the circumstances) for color interpolation in some scenarios and the results are really visually pleasing compared to interpolating in RGB or HSL.
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.
This is only possible because of a very specific quirk of Linux: the interface between the kernel and user mode halves of the GPU driver is considered as sacrosanct as normal Linux syscalls[0]. If you want to get a graphics card driver in kernel you have to get your driver's UAPI approved by the kernel maintainers because it will be supported in Linux until the end of time.
No other operating system does it this way, nor will this work on Nvidia proprietary drivers. Everywhere else, the point of demarcation for graphics is OpenGL, DirectX, Metal, or Vulkan entrypoints in userspace. To be clear, there IS a UAPI here too - hardware isolation demands it - but it breaks constantly and nobody bats an eye. If you were willing to deal with that fragility, you could do the same trick on Windows or macOS.
[0] For those unaware, Linux has a very explicit policy of never breaking userspace. That means no ABI changes whatsoever.
> For those unaware, Linux has a very explicit policy of never breaking userspace
But has no qualm with constantly refactoring the kernel side of the coin for the most minor of reasons, which causes endless trouble when it comes to supporting out of tree drivers and is the true reason why Android will never be able to provide long term support. SOC manufacturers are not interested in the churn involved in updating their drivers to support the newer kernels that come with new android versions. Most often, it's because they want to keep their driver proprietary, but it is not the only reason, there is a cold hard truth about the nature of the market: new phones are released at a high cadence, while the process of mainlining a driver into upstream linux kernel is arduous, depending on the attitudes of kernel maintainers, truly painful, and no company out there could see any value in waiting for this process to end before releasing their hardware onto the market. Since they're already going to make it out of tree and release it as is, why would they bother? a year later, they'll repeat this process again, and again. Then Android updates, and the devices are obsoleted.
On the other hand, you can install the latest GPU driver on Windows 10 just fine, and it is the same driver as the one on 11. Windows doesn't constantly break your not-maintained-by-microsoft drivers with newer versions of their kernel.
For the part that most people care about (which is the userspace side, that comes from the Mesa Project) you can freely update it to whatever is the latest version without really having to care about the kernel side. The only point at which the kernel side of the GPU equation actually matters for Mesa is when new HW comes out.
>>you can install the latest GPU driver on Windows 10 just fine, and it is the same driver as the one on 11
MS is certainly well known for breaking Windows drivers across major releases. The only reason that Win10 and 11 driver is the same is because Win10 and 11 are more or less the same thing.
To put a finer point on driver breakages... part of why Vista was so disastrously bad at launch was specifically because they'd drastically changed the DirectX kernel driver model to support DWM[0]. Nvidia in particular was responsible for a third of all Vista crashes, with another third being ATI (now AMD RTG). WDDM was a moving target right up until launch and it took about a year for Vista to actually be usable[1].
>MS is certainly well known for breaking Windows drivers across major releases. The only reason that Win10 and 11 driver is the same is because Win10 and 11 are more or less the same thing.
Not quite accurate, it depends on whether a new version of Windows has a significantly newer kernel.
Windows 2000 and Windows XP (and all its derivatives) share the NT5.x kernel, and thus drivers for any of them generally work in the others. Likewise Windows Vista/7/8/8.1 which all share the NT6.x kernel, and Windows 10 and 11 which share the NT10.0 kernel.
In other words, it's pretty common for Windows users to experience major driver breakage every time they upgrade to a new major version of Windows. Because it was pretty normal to go from Windows 9x to XP (skipping 2k), then skip Vista and not upgrade until 7, then skip 8 and 8.1 and not upgrade until 10. The exceptions were mostly if you bought a new computer that had one of the more disappointing releases preinstalled, but in those cases driver breakage would have been much less of a concern anyways.
>In other words, it's pretty common for Windows users to experience major driver breakage every time they upgrade to a new major version of Windows
This is really a high level arguing in bad faith here. Windows XP was released in 2001 and mainstream support ended in 2009 with the last security update in extended support being in 2014. Vista to 8.1 covers 2006 to 2023, that's 17 years of having compatible drivers. Windows 10 was released in 2015, 8 years ago, with 11 having a compatible driver model and will go for many years still.
What does "common" to experience breakage is supposed to mean here? you call this common? meanwhile you can't even get a Google Pixel, the official Google phone, to be supported more than 3 years of feature update, with 2 more years of security updates. This is all because supporting the linux kernel is a pain in the ass.
I'll also add that it is very common for hardware manufacturers to just provide drivers for newer versions of Windows as they come out if necessary, with the hardware ending up supported across multiple versions of Windows.
It is very seldom when you actually come across hardware without drivers, unless the hardware is so old that the manufacturer isn't selling (and thus isn't supporting) it anymore.
