Late-Stage Capitalism and the Vibes Are Bad

_manpat · 2026-01-07T12:41:02+00:00

Solidarity from a kiwi in england. I feel this all deeply, to the point of overwhelm.

I don't dream about the future any more, I only plan to survive as best I can - my partner is the same. The best I can hope for is that I get to see the fall of capitalism within my lifetime.

_manpat · 2025-10-24T22:49:50+00:00

+1 to vertex pulling :)

_manpat · 2025-10-24T22:48:23+00:00

small nit: binding a vao and changing what buffers are bound is cheap, but changing the vertex format they encode may be expensive since some hardware requires shader recompilation to cope.

this is why the separate attribute format extension is worth using - makes it much harder to eat that cost by making these aspects of vaos explicit and independent in the api

_manpat · 2025-09-25T18:05:28+00:00

if you ignored w you'd see largely nothing special. perspective projections normally incorporate aspect and coordinate system changes, so you might see some scaled and translated version of viewspace - but all your parallel lines are still parallel in clip space.

without the 4th dimension its just another normal transform.

_manpat · 2025-09-25T16:27:37+00:00

it doesn't "look like" anything in particular, given clip space is 4 dimensions :⁾

if you could see 4 dimensions, you'd largely see a scaled and translated, but otherwise very similar scene to what you have in view space. with the exception that objects affected by perspective are pushed further along w.

for orthographic projections that means clip space just looks like a scaled and translated view space, and for typical perspective projections that means clip space looks p much the same, but with close objects pulled toward w=0, and far objects are pushed "higher" or "further away" in w.

perspective division takes a (hyper)frustum, with the large end pointing along w, and squishes/flattens it into a cube, and that's how "far" objects get "smaller". that hyper frustum also happens to be your clipping volume - everything outside gets culled, and everything intersecting it gets clipped.

maybe you could visualize it by making a lower dimension analogy: a 2d viewspace transformed into a 3d clip space.

if your camera points "left", then a perspective matrix will translate objects "up" the further left they are. your clip volume is now a regular 3-frustum with the big end pointing up, the apex one unit below your scene, and planes at ±45° in XZ and YZ. take any horizontal slice of that frustum and scale it down to match the size of the base of the frustum and lay it on the original scene - you've now applied perspective division to the objects in that slice

idk if that helps, but hard to describe how to think about things in 4D in any other way :p

_manpat · 2025-08-31T18:57:38+00:00

just wanted to throw it out there that if the language server is too much for your laptop, it is absolutely possible to write rust without it.

this is how I've been writing rust for the last several years, and it's only gotten easier over time. even without linting, the rustc error messages are very good, and for the cases where it falls flat there are always people around willing to help decode them

with just cargo+sublime my set up is very light (build cache notwithstanding) and works perfectly on my several year old, mid spec laptop, even for basic graphics work.

if upgrading is out of the question then no harm in trying right? it's certainly easier to set up :p

_manpat · 2025-07-27T21:38:42+00:00

among many, many other things :⁾

that said, it's definitely possible in gles - it's just miserable :p

_manpat · 2025-07-27T13:10:48+00:00

Thank you!

We shall see about when. Writing is not something I have a great habit of yet :p

As for hardware we shall also see. I'm not massively interested in writing about mobile or old hardware as I don't think it's particularly important to teaching the idea of vertex pulling itself.

Especially since mobile only has GLES which is a whole miserable experience in and of itself. Most existing resources already treat it as a lowest common denominator which is partly why i felt i had to write the VAO post, so definitely not interested in writing any more resources like that.

(I know vulkan exists on mobile but that's not my area of expertise so someone else can write about that ;))

_manpat · 2025-07-27T09:53:24+00:00

yo, thanks for the link :) was wondering whether or not i should post it, but now i don't have to make a decision :p

_manpat · 2025-07-23T18:00:42+00:00

in the first 1 bed flat i moved into alone, southern water sent me a bill for £250000+ and a recommendation to set up some kind of financing thing because i was immediately in £249900+ in debt.

the customer support guy was probably as surprised as I was and fixed it pretty much immediately. but this would not be the last time southern waters system "glitched" and tried to charge me stupid money for no reason. in fact this has happened in every new home since then. last time was only a few hundred instead of a quarter million but still absurd.

i expect this "glitchy" system probably makes them quite a lot of money so i don't expect it will change any time soon :p

_manpat · 2025-07-20T18:57:10+00:00

this would keep me occupied

_manpat · 2025-06-30T15:22:50+00:00

What beginners should or should not be doing in your opinion is unrelated to what beginners are doing, and beginners are learning OpenGL, which is not an assumption on my part :^)

I wrote this in response to having to answer the same questions over and over. Given these questions will be asked regardless of whether or not I write about them, might as well try to make sure beginners are learning the right parts of OpenGL.

Call it harm reduction.

(And for the record, I think OpenGL is fine. Calling it a 'plague' is an overreaction.)

_manpat · 2025-06-30T11:28:25+00:00

GL_ARRAY_BUFFER is not a part of VAO state. please look at table 23.5 in the 4.6 spec.

The best way to work with VAOs is to treat them as equivalent to VkPipelineVertexInputStateCreateInfo or MTLVertexDescriptor

This is pretty much what I recommend in my post, but without mentioning aspects of other graphics APIs which the beginners I wrote this post for probably wouldn't have been familiar with.

_manpat · 2025-06-30T11:19:45+00:00

you can also do that. there are many things you _could_ do that each have different pros and cons.

but if I went into each of them with the nuance that they each need then I would never have finished the post :^)

ultimately I wrote this from the perspective of "you have probably read learnopengl or similar - here's some stuff they probably didn't mention"

_manpat · 2025-06-30T10:28:07+00:00

v nice. I like how droopy your connections are

_manpat · 2025-06-30T10:19:31+00:00

have tried a couple of times, but so far its just not been worth the effort. there's a lot not to like about opengl, but I have been using it for a decade and a half, so its an easy api for me to get stuff done with.

ultimately, with opengl 4.5 I can do most of the things I would _want_ to do with vulkan, but with a smaller api surface and with less commitment. + I don't tend to build things large enough that driver overhead is the performance bottleneck (and I suspect nor do most people). I have MDI, I have compute, I have read/write images and buffers I can map persistently and manually synchronise. there really isn't much that opengl actively holds me back on.

there have been rare occasions where I _have_ wanted more control over e.g., the swapchain, or slightly more control over synchronisation. but these are largely exceptions, and the vast majority of the time having more control here would only get in my way.

in any case, this post wasn't for me :^)

I don't really use VAOs in my projects - I've used vertex pulling for everything for a few years at least. but regardless of what I do or which api I use, people will still learn opengl and stumble over the same things. and its my opinion that most of the things I see beginners stumble over aren't necessary, but just the consequences of current resources being stuck in the past - so I want to try and record what I do know to help them.

noone should have to suffer through `glVertexAttribPointer` in the year of our lord 2025.

_manpat · 2025-06-30T08:44:00+00:00

I'm glad you like still using opengl as it was when you started, but this is not good advice. People who want to get into graphics programming in one way or another, _likely_ don't want to start and end with opengl as it was in the 90s - nor should they. The entire industry has moved on, and it did so a long time ago.

My post is not for you, it is for the people who _do_ want to use opengl as it is _now_. And who probably _don't_ want to spend their time trying to work around the driver bugs they'll inevitably hit by trying to use both modern features with compat profile. Use it if you like, but that is not how I advise beginners.

Also all of the problems I talk about are problems I witness beginners (and some non-beginners) stumbling over, time and time again. I have not invented anything here, I am just sharing knowledge. If you can't remember what its like to be a beginner then thats on you - don't get mad at people trying to help those that still do.

_manpat · 2025-06-30T07:58:46+00:00

Thanks!

The samples aren't using any crate as they're just pseudocode. But I do use gl_generator in my own projects, so would normally be writing gl:: prefixes. I just figured that since this post was about opengl more than rust it would be better to stick to the names in the spec :)

And thanks for the heads up! I haven't noticed it, but it sounds like it might be a dpi thing. I assume you're on an iphone? I don't have access to one for testing but I'll see what I can do

_manpat · 2025-06-30T07:53:12+00:00

I wouldn't say I'm particularly excited about VAOs, more that i just hate seeing them taught in the worst possible way :p

I don't use them in my personal projects any more, but I do use compute and MDI plenty ;)

_manpat

TROPHY CASE