I'm gonna jump in here with some self promo - back in college I TA'd a class that, for a few weeks, taught Malbolge, and the only assignment was for students to write a program that printed their name.
After spending a lot of time thinking about the language, I came up with a relatively simple algorithm based on the language design - there are a few operators that mutate state, so basically just try combinations of those until your next memory cell contains the thing that you want, then lock those instructions in and advance.
BUT! The whole reason for this comment is to nerd say that printing stuff is relatively easy if you invest the time in learning the language's primitives and think of programming in it more as algorithms to operate on the op codes instead of literally writing code.
Now, to do more interesting things other than printing - I'd have to spend even more time thinking about the language, which I don't want to
Pretty funny that I off-handedly used Malbolge as a random pull from my brain for “an extremely weird and not-really-but-kinda programming language” without even really remembering any details about it; and then I got to learn about your project!
I guess we have very different ideas around what makes good music. Every single Suno produced song sounds like a 60kbps extremely compressed mp3 while also having extremely generic, uninspiring structures and complete lack of interesting sonic/instrumental layers.
It's great that people find joy in it, but as someone that is critical of both music production and fidelity, the current offerings fall incredibly short of anything I would ever want to listen to.
If this is a real thing, it needs a lot of work. Lots of failure modes, errors that are not being handled, sometimes exceptions, sometimes swallowing and printing to stdout, very inconsistent style, mixing and matching all kinds of C and C++ conventions, the fallback hard coded path of your specific user name + deep path ...
I would recommend not using this for any data that you actually care about.
Ah, yes, the "you're holding it wrong" defense. If one tool has a higher safety rating than another, significantly so, preventing entire classes of mistakes from happening that the other does not, in a kind of superset manner - even the most skilled craftsman will inevitably make mistakes that would have been prevented by the safer tool.
Anecdata, they might have had a system error. My Microsoft account that I use the free tier OneDrive on had the same email sent (you're over x% full, consider upgrading!). I suspected everything you did - eventually I logged in after verifying the email - nope, 5% usage or so.
I then went and deleted more stuff, but my money would be on a reporting glitch than a malicious money campaign.
Myself–and many redditors–got this erroneous notification too. I don't think Microsoft ever sent out an "Oops, sorry, you don't actually need to pay us" correction though.
I don't think you really need a tool for that, you can just add something like "after the task is finished, have a subagent review the work in an adversarial fashion. If any defects, no matter how small are found, have another subagent implement the findings. Repeat this in a loop until all subagents achieve consensus that the product is of exceptional quality with no defects" or similar to each prompt. Each subagent gets its own, fresh, context window. No tooling required.
From my experience with game engines and people that really care about CRTs - I believe the effect (confidence: 95%) can be entirely achieved with rendering glue in any of the modern game engines - Unreal, Unity, Godot, etc. Now, whether or not it is a literal shader, or a shader + custom sauce, not sure.
However, I have not tried, so I cannot verify that claim to 100% accuracy. The author ...might have tried? They definitely surveyed the landscape. My read of the article was that they went down this rabbit hole and back-justified it instead of investing a similar amount of time in a practical solution in a modern engine.
CRT look and feel is a niche full of very passionate and opinionated people.
I've done a version of this in Godot. It's kind of a hack, but it works and it's all Nodes without needing a script. You could do it more easily in a compositor effect but you have to deal more with the guts of the engine.
The basic idea was to use a chain of Viewports and TextureRects using the previous ViewportTexture to do the effect. This is essentially just setting up a chain of framebuffers that I can draw on top of at each step. The first step just does a simple calculation to convert the incoming color to an "energy" value with a simple shader on the whole frame. Then there are two decay viewports that feed each other to decay the old frame and overlay the new one. These just have a decay parameter that I can tweak to get different effects. There's a final Viewport that supersamples everything because I'm going for more of a vector display look than a CRT. And I can layer on other effects at either the energy state (like decaying phoshpor) or at the final stage (like flicker or screen curve).
Here I've exaggerated the decay quite a bit so you can see the effect. https://www.youtube.com/watch?v=2ZrvcZIfqOI The trails there are entirely from this effect. I'm only rendering the spinning figure. You can also see where lines overlap they are brighter than the surrounding lines because I cap the maximum energy value in the first layer.
Do you have an example? I’ve done a slightly-more-than-casual search for convincing post-processing and haven’t found success. Filters still tend to retain the sharpness of pixel edges in a way that CRTs don’t, and the contrast doesn’t look right either.
I'm not saying the tech currently exists in a form you can just plop into a project and have it give you the exact CRT look and feel that you want. What I am saying is that you can do that within any modern game engine - you just have to decide what, exactly, the look and feel you want is and how to get there.
As an example, I will quote the article:
> Retro Game Engine owns the full frame lifecycle. I decide what the input signals are, what the display does with it, how time affects it, what gets presented and when.
You can replace "Retro Game Engine" in that sentence with "Unity" or "Godot" and it is just as true.
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.
I think you are underestimating what a filter is allowed to do.
You could build a simulation of the universe, send the frame data to the CRT inside that universe and capture the output of the simulated CRT and show it on the LCD.
This is cool. I took a look at the public GitHub (not too deep) and this appears to use classical neural network training techniques - there is an exposed API that the author came up with a clever way to encode Doom state and inputs into. Well done!
After spending a lot of time thinking about the language, I came up with a relatively simple algorithm based on the language design - there are a few operators that mutate state, so basically just try combinations of those until your next memory cell contains the thing that you want, then lock those instructions in and advance.
Basically RNG yourself to victory.
The original code for that algorithm is here (python, + my own interpreter): https://github.com/wallstop/malbolge-toolkit/tree/dd942fb981...
I've since llmified it as an exercise.
BUT! The whole reason for this comment is to nerd say that printing stuff is relatively easy if you invest the time in learning the language's primitives and think of programming in it more as algorithms to operate on the op codes instead of literally writing code.
Now, to do more interesting things other than printing - I'd have to spend even more time thinking about the language, which I don't want to