Nitpick: What you're describing is the disk cache. If a process requests more memory than is free, the OS will not page out pages used for the cache, it will simply either release them (if they're on the read cache) or flush them (if they're on the write cache).
Still the best CRT simulation I've seen is in an X screensaver called XAnalogTV. It simulates both CRT artifacts as well as NTSC channel cross-talk and analog interference. It amazes me that still no one has produced a portable version.
You forgot one thing: flickering. At 60 Hz, a CRT is murder on the eyes. A few years ago I used a CRT for the first time in like ten years and my eyes hurt almost immediately.
I was never incredibly disturbed by 60Hz though I did notice it.
You reminded me of something I had forgotten though — remember when 100Hz / 120Hz TVs first became a thing? That I noticed!
I think most of my PC CRTs ran at 72Hz / 75Hz IIRC. At least with the monitor I had I remember pushing it to 90Hz but that would add bluriness / lose clarity so I never used it at that rate.
>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.
I didn't suggest it makes any sense, just explaining, based on my understanding of the article, why he analogized the game engines to renderers to cameras.
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.
It's not whataboutism, it's a legitimate question. How does it increase safety on the road to reject local SSH connections by a dumb user, when that same user can mess with the car physically?
Simplest example: a driver could probably disable attentive driving checks by pasting a script in from a web search in a few minutes. Nothing like an inattentive 3750 lbs weapon.
Yeah and they could hire a professional driver or a engineer and IPO for billions a life sized driving AI powered crypto robot too. Look, like clearly google + ctrl-v scripting or running an one click deployment exe on your computer on a whim is different than physically ordering/picking up something and then installing it into a vehicle?
Of course they're different, but you're trying to argue that the former takes objectively less effort than the latter, and it doesn't. One or the other may take less effort depending on who you are and what you know.
>The underlying tension is that "you own the car" means something very different from "you own the software running the car."
What does that mean? "The software" is a specific configuration of the hardware you own. How can you own the hardware and not the specific copy of whatever data is on it? Note that I'm not confusing the copy of the data with the IP rights to it.
Because American courts have entertained utterly moronic claims for decades now and the DMCA eliminates any sanity in consumer rights around IP products.
When you bought a DVD, you didn't "Own" the movie, but you had a legal right to do things with that data you didn't "own" anyway, like format shifting and selling that physical object on to another person. You could copy that data off and do things with it. I think technically it would be a copyright violation to then put that movie file into Movie Maker and cut up your own personal highlight reel, but good luck finding a judge willing to hear that case if you don't upload it to youtube.
Now, thanks to the DMCA and courts being absurdly credulous of bullshit arguments from corporate attorneys, you no longer have basic consumer rights. If you try to even inspect the code that runs to protect your literal life, that can be a crime. You own the literal hardware, but if you try to act like you own it, that's a crime. You technically still have the right to format shift a BluRay for example, but bypassing the math protecting that data overrides that "right" and you are guilty of a crime. A CEO's wet dream.
If the DMCA was older, IBM could have prevented the existence of the Clone PC market and ensured a locked up market. We would all be stuck on absurdly shit hardware because that's what was more profitable for IBM.
Pre-DMCA, Sega was told that their trademark rights were overridden by the innate market right to interoperate with their product. IP rights used to be fairly weak! Sony could not prevent a company from selling a software product that ran playstation games. To this day, Nintendo simply pretends these court cases didn't happen.
This is part of why China has so much success in manufacturing and product development IMO. They don't need to develop purposely worse versions of things just so some other company can sit on their hands for 20 years collecting rent. If you want a fast moving market, the ability to lock things down for 20 years is fundamentally unacceptable, only enriching a few owners, and outright harming our country. Basically every time in history that IP rights are weakened or nullified, you see a burst of development and advancement in products and solutions.
If you ever try to write a email client, you will immediately realize how difficult, if not impossible, to fix all the bugs for a email client. It is a multi-different-protocol-version-async-client-handling-same-database-with-thousands-of-race-condition backwards compatibility nightmare.
Writing a email client with support of just up-to-date protocols and assume it is the single client that will operate that account is trivial, write one that covers all corner cases is a totally different story.
I don't know about the rest, but surely the race conditions are the fault of whoever designed the concurrency part. An email client does not inherently have race conditions.
OK? Sure would be nice to hear why having a second email client talk to the remote server introduces race conditions on the local client (EDIT: that is, race conditions that are the local client's responsibility).
Adding a mobile version, MS Exchange integration, supporting OAuth2 login, refreshing the UI periodically because otherwise everyone whines about how "dated" it looks.
Anything can happen, but you're predicting the future without any evidence. You just made up a scenario in your head, predicted it would come true, then you can't believe people would say it's ridiculous.
When was the last time this happened with a gas car? How often are fires happening with lithium iron phosphate?
You think a car is going to crashing into a building AND burst into flames AND be impossible to put out AND burn the building down?
When was the last time this happened? Let's think about odds and statistics super hard.
>When was the last time this happened with a gas car?
ICE car fires are easier to put out.
>You think a car is going to crashing into a building AND burst into flames AND be impossible to put out AND burn the building down?
EVs catching on fire and then being impossible to put out is something that has already happened, and in fact as I understand it the latter invariably follows from the former. The only new thing that needs to happen is the fire happening while the car is not out on a road, but inside a building where it can set other things on fire. The fact that the vehicle cannot be put out and can frustrate firefighting and rescue efforts makes an already dangerous situation even more dangerous.
Which part of any of this is straining your imagination?
>When did one crash into a building, catch on fire, and kill people? Surely this must have happened at some point for you to put all this together.
You can't think of a single example of an ICE vehicle crashing into a building, starting a fire, and a bunch of people dying? I can think of two such crashes happening the same day, involving jet engines.
I don't know why this is relevant, though. The topic of discussion is lithium batteries, not ICEs. A vehicle crashing into a building and starting a fire that kills people is not some science fiction scenario that should need to be defended. Your incredulity is straying into bad faith territory.
>you changed what you're saying
I changed it because I think it's it's pretty obvious that the concerning thing is the EV catching fire where it can easily spread to other things. Whether that's because the vehicle crashed or for some other reason is inconsequential. The reason I gave that example initially was because that's just what I happened to have in mind at the time; it makes sense that a crash could damage the batteries enough to cause a thermal runaway, rather than the car randomly bursting into flames for no reason.
>It's only a matter of time before someone gets hit by lightning after winning the lottery too.
Winning the lottery doesn't increase your chances of getting hit by lightning, nor vice versa, but crashing your EV does increase the chances that it can catch fire, and a building is one of the things it can crash into. Having a fire that cannot be put out likewise increases the chances that someone may die from it, compared to if the fire is easily to be put out.
I don't know, do you really find it that unreasonable to be a little bit concerned that cars now have these giant energy stores that if they fail they're impossible to control until they burn out completely?
You can't think of a single example of an ICE vehicle crashing into a building, starting a fire, and a bunch of people dying? I can think of two such crashes happening the same day, involving jet engines.
So your argument is that electric vehicles are dangerous because of 9/11 ?
That's what you said. Cars became planes and suddenly 9/11 is your example and somehow it means that someone will crash a car into a building, the car will light on fire and everyone in the building will dies. These are your words.
I'm not really sure what you think the difficulty is. A firefighter in fire protection gear hooks the burning car with a large metal chain, the other end goes to the fire truck, tow truck or winch, the car comes out of the building.
The building is made of ordinary building stuff like wood and plastic which can be extinguished using ordinary means, you just need to remove the car so it doesn't set it on fire again. The same means (dousing it with a fire hose) can temporarily lower the temperature of the car. Firefighters already have the equipment necessary to deal with toxic smoke.
reply