Interesting article. I hope their engine gets to the point where it actually looks like CRT instead of the blocky filters we see nowadays.
Here’s an entertaining video showing the difference in retro games on crt and lcd screens. It’s pretty incredible if you aren’t aware. Games back then were designed on CRTs and can look awful on LCDs in comparison.
>But a CRT isn’t a camera filming the world. Its a physical device that generates an image as an output of physical process. [...] That’s not a post-process overlay or filter effect, its an entirely different mental model of what it means to draw or render an image. I think this is why I struggled when trying to bolt this onto a modern engine. The foundations between the two models is just so fundamentally different. At this point, I was already beginning to consider my options. I was half inclined to give up.
An LCD or an OLED are also not cameras. I honestly don't understand what insight this person believes they've stumbled upon.
This is also very mystifying:
>The frame is never a single instant, its a culmination of integrations over time.
Strictly speaking, a CRT doesn't understand frames. It just fires whatever intensity of electrons is indicated by an analog signal at any given time as the magnets steer the beam across the screen in whatever pattern has been designed into them. If the tube is controlled by a digital source, there will likely be some kind of framebuffer of some size somewhere on the pipeline that stores at least a full scanline, and nowadays invariably a complete frame, so a DAC can convert the values in it to the analog signal expected by the gun.
The entire article supposedly addresses the "why", but after getting to the end, I still don't understand the why. What's wrong with Unity or Unreal architecturally that this guy's engine addresses?
From my understand after reading, he's suggesting that Unreal and Unity's post processing are just applying effects to a camera/rendered frame, when what he wanted to do is simulate the CRT itself across the renderer to the frame that hits the swapchain.
But that's nonsensical. The CRT doesn't see the graphics pipeline of, say, an SNES, it just sees an analog signal. The graphics processing is done in the digital realm, not in the analog realm. If you want to simulate a CRT, all you need is a physical model and a digital image to display, which can come from Unreal, Unity, or whatever any other engine or program or whatever. It makes literally zero sense to write an entire engine to implement a CRT simulation.
Yeah I’m with you. Hate to assume such things but with how much AI spam is out there on programmer blogs these days I kinda just give up reading the blog post once something becomes confusing. Most of the time there’s not any insight to be learned by investigating deeper.
This one also has a lot of Its not X, its Y type phrasing
As you said, the CRT just receives the frame data and turns that into a visible image. This means you can simply build a filter that transforms the final frame buffer by simulating the physics of a CRT.
A filter is not a game engine and a game engine is not a filter.
Building a custom game engine for CRTs represents a fundamental misunderstanding of how a CRT works and what the responsibility of a game engine is.
Mmm, while this person's articles are clearly AI written, they do make some sense. Their renderer keeps samples the previous frame to achieve the effect, which of course is totally possible to do in Unreal or Unity but they also seem to have their own lighting and PBR models, which might be a bit harder to achieve.
>Lighting systems are designed to remain readable under CRT-style color quantization. Sprite and mesh pipelines emphasize bold shapes and strong contrast. Even debugging tools in the engine, like the grid overlays and scene visualization systems, exist partly to help developers maintain spatial clarity and composition.
This is AI nonsense but it could be a summarisation of something real.
My advice to anyone even minimally interested in retro games or just clear motion in the image is to get a cheap crt monitor and play a bit with it. You'll surely will appreciate that even against today monitors they hold their ground very well (not in brightness, though) and easily surpass them in motion clarity.
We did lose quite a lot when we trasitioned to lcd screens.
I get the overwhelming feeling that the author was convinced by an AI that he had a good idea without ever contacting an actual graphics programmer.
"Retro Game Engine owns the full frame lifecycle." - This is completely meaningless. Your engine controls whatever data is in the buffer that's sent to scanout, but the operating system and the GPU drivers and the scanout hardware in the GPU and the input processing and row/column drivers in the display control everything else.
The only actual screenshots this guy has are some "multiply the image with the subpixel mask" demos that.... don't look anything like a real CRT, and certainly nowhere near modern CRT shaders like CRT Royale.
The rest of the posts in the substack page are similarly devoid of actual content, but very heavy on the AI woo-woo this-is-important-and-deep stylings that I've come to find nauseating.
Hey Author, if you can see this - You're clearly a smart guy, but you need a basic grounding in 3D rendering if you're gonna do weird stuff - more than an AI can give you. In particular, the phrase "Light is linear" will be useful to you. Good luck.
29 comments
Here’s an entertaining video showing the difference in retro games on crt and lcd screens. It’s pretty incredible if you aren’t aware. Games back then were designed on CRTs and can look awful on LCDs in comparison.
https://youtu.be/bC-8y2R6IxI?t=166&si=D6K2v28RIR4bACQ3
>But a CRT isn’t a camera filming the world. Its a physical device that generates an image as an output of physical process. [...] That’s not a post-process overlay or filter effect, its an entirely different mental model of what it means to draw or render an image. I think this is why I struggled when trying to bolt this onto a modern engine. The foundations between the two models is just so fundamentally different. At this point, I was already beginning to consider my options. I was half inclined to give up.
An LCD or an OLED are also not cameras. I honestly don't understand what insight this person believes they've stumbled upon.
This is also very mystifying:
>The frame is never a single instant, its a culmination of integrations over time.
Strictly speaking, a CRT doesn't understand frames. It just fires whatever intensity of electrons is indicated by an analog signal at any given time as the magnets steer the beam across the screen in whatever pattern has been designed into them. If the tube is controlled by a digital source, there will likely be some kind of framebuffer of some size somewhere on the pipeline that stores at least a full scanline, and nowadays invariably a complete frame, so a DAC can convert the values in it to the analog signal expected by the gun.
The entire article supposedly addresses the "why", but after getting to the end, I still don't understand the why. What's wrong with Unity or Unreal architecturally that this guy's engine addresses?
This one also has a lot of Its not X, its Y type phrasing
A filter is not a game engine and a game engine is not a filter.
Building a custom game engine for CRTs represents a fundamental misunderstanding of how a CRT works and what the responsibility of a game engine is.
>Lighting systems are designed to remain readable under CRT-style color quantization. Sprite and mesh pipelines emphasize bold shapes and strong contrast. Even debugging tools in the engine, like the grid overlays and scene visualization systems, exist partly to help developers maintain spatial clarity and composition.
This is AI nonsense but it could be a summarisation of something real.
We did lose quite a lot when we trasitioned to lcd screens.
"Retro Game Engine owns the full frame lifecycle." - This is completely meaningless. Your engine controls whatever data is in the buffer that's sent to scanout, but the operating system and the GPU drivers and the scanout hardware in the GPU and the input processing and row/column drivers in the display control everything else.
The only actual screenshots this guy has are some "multiply the image with the subpixel mask" demos that.... don't look anything like a real CRT, and certainly nowhere near modern CRT shaders like CRT Royale.
The rest of the posts in the substack page are similarly devoid of actual content, but very heavy on the AI woo-woo this-is-important-and-deep stylings that I've come to find nauseating.
Hey Author, if you can see this - You're clearly a smart guy, but you need a basic grounding in 3D rendering if you're gonna do weird stuff - more than an AI can give you. In particular, the phrase "Light is linear" will be useful to you. Good luck.