docs(twitter): add 27 new NOTimothyLottes threads (Jul 2026 Linux dev bringup)

Processed 38 URLs from the user's list. 1 was already in the corpus (2072194202851549432). 9 were duplicates within the new batch (same post IDs at different anchor URLs); removed those. This commit contains the 27 unique new threads. Content spans the Jul 2026 era and is mostly Lottes's Linux development environment bringup work: - 1674757854471806977: 'Nothing Oriented Programming' (NOP) philosophy - 1990260050485797063: reversed projection matrices - 2030722033286328426: STP conspiracy theory - 2058166883044516181: 'crap-o-grammers' C++ bloat-ware critique - 2060191401883619479: relevant timestamp article - 2060730425929080874: CPU clock code (TSC) - 2061123768429211767: no-debugger-debug + mmap log pre-history - 2061416116694442141: Windows thread priority - 2061933917137932437: mmap'd page file - 2061937134756380682: Windows HIGHEST_PRIORITY_CLASS - 2062031187023982879: back running 640x480 on VGA CRTs - 2064858927829745887: on Linux now (SteamOS) - 2065804972378243476: nanorc done + iPhone font issue - 2065832746757341482: cross compilation up - 2065872197147578751: @axelgneiting bypassing libc - 2066184005632786736: Linux mlockall - 2070337342854832468: why not pselect/ppoll/epoll_pwait2 - 2070734717825986566: deterrant to ALSA = parsing through snd_pcm_open - 2071415096304193820: aplay to actually play a wave file - 2071706805114216559: 'ALSA hell month continues' - 2071937360288235902: Linux thread priority code - 2072135292115427728: Linux doesn't allow priority increase by default - 2072445315370590266: 'Wine workarounds - I could just detect' - 2072506103401754653: snd_pcm_sw_params for ALSA - 2072804183992922296: starting on WDM/KS audio for WIN32 - 2073096069529907441: re-trying WASAPI - 2073110092447203466: CPP_(obj) for mmdeviceapi Cleanup: removed 9 duplicate dirs (same posts at different anchor URLs), script temp files, and the '1857803914604618029' which was already a duplicate of '1857820858162753661' (mmap log canonical).
2026-08-01 15:49:22 -04:00
parent 8c93fba658
commit c3a9978d03
108 changed files with 4212 additions and 0 deletions
@@ -0,0 +1,56 @@
+---
+title: "I wish everyone would just adopt "reversed with infinite far" projection matrixe"
+author: "NOTimothyLottes"
+handle: "@NOTimothyLottes"
+post_url: "https://x.com/NOTimothyLottes/status/1990260050485797063"
+post_id: "1990260050485797063"
+timestamp: "2025-11-17 03:25:47"
+post_count: 9
+reply_count: 5
+repost_count: 2
+like_count: 85
+view_count: 6057
+---
+
+# @NOTimothyLottes — I wish everyone would just adopt "reversed with infinite far" projection matrixe
+
+## Post 1 (2025-11-17 03:25:47)
+
+I wish everyone would just adopt "reversed with infinite far" projection matrixes so I could only optimize for the fastest and highest precision option, but I'm guessing people haven't all migrated over :(
+
+![Media 1](./media/1990260050485797063_1.png)
+
+## Post 2 (2025-11-17 03:28:35) — reply to Post 1
+
+Reversed is a significant improvement but it still has its limitations when doing planetary-scale rendering that needs good precision up both close and far away. Your options there are either a logarithmic depth buffer to linearize things (albeit losing early z), your own integer-based depth test system in compute shaders, or a stack of multiple frustums layered on top of one another.
+
+## Post 3 (2025-11-17 03:31:41) — reply to Post 2
+
+@AgileJebrim Yes for my non-tri stuff I'm log depth already. This is just for games, not simulation.
+
+## Post 4 (2025-11-17 03:41:27) — reply to Post 3
+
+Simulation can usually localize enough that reverse Z is good enough. Google Earth style geospatial visualization is where things get trickier.
+
+Another option is to dynamically change the far plane, moving it closer as you get closer to the terrain and further back as you move further back. I don’t think I tried this one but I imagine it requires a lot of tuning.
+
+## Post 5 (2025-11-17 05:03:02) — reply to Post 1
+
+@NOTimothyLottes I've never had real depth precision issues in our game ports but I guess I'd better just adopt and get used to reversed infinite projection cause it's objectively better. Promise to try it for our next project :)
+
+## Post 6 (2025-11-17 05:06:11) — reply to Post 1
+
+@NOTimothyLottes Many are still on OpenGLES and WebGL, which don’t properly support inverse depth due to still using a -1 to 1 clip space. Not really a problem for inverse depth in its own, but does cause problems for infinite far depth.
+
+## Post 7 (2025-11-18 16:26:49) — reply to Post 1
+
+@NOTimothyLottes Infinite far doesn’t apply to ortho, and many of editors/engines need to switch camera viewports.  But it’s great for persp.  Also too much code handing modeInv for normals, which is wrong and unneeded.
+
+## Post 8 (2025-11-19 18:56:58) — reply to Post 1
+
+@NOTimothyLottes I haven't really done graphics in a while, but I've never heard about infinite far nor reversed z, where can I read up on it more?
+Some cursory googling didn't return anything useful on this topic.
+
+## Post 9 (2025-11-20 03:47:56) — reply to Post 8
+
+@stainless_code I put some docs (based on an old blog post) on projection matrix stuff inside STP source: https://github.com/Unity-Technologies/Graphics/blob/master/Packages/com.unity.render-pipelines.core/Runtime/STP/Stp.hlsl - Documents the maths to take depth and 2 projections and get a static reprojection vector for example.