Yeah, EA open sourced their STL, although now that C++23 is supported (aside from on MSVC? Still not flat_map there?!?) there is some replication in the STL.
Not uncommon for audio companies to also write their own containers and internal STL for ex. plugins as well.
We can all agree it's not medical systems, but audio DSP and game dev both end up rewriting a lot of STL stuff to suit their needs, and often using a restricted subset of modern C++ features for similar reasons.
That isn't some arbitrary choice, but pretty much where everyone continually ends up when solving real-time problems using C++. Whether those be games or not.
You can prevent more than enough crashes with enough testing to make gamers happy. Even if you prove there is not out of bounds error I still want a medical device to check
Even with an extreme high level of inhouse testing (which is needed anyway) you'll never find the bugs that are discovered when a hundred-thousand gamers try to exploit every little feature of your game.
The reason to keep asserts in release mode is so that when one of those asserts is triggered "out in the wild" the bug investigation is dramatically simplified. The assert message and callstack is usually enough to figure out what went wrong. With a regular crash that happens without asserts the actual reason of the crash may already be obfuscated enough that a useful bug diagnosis is no longer possible. E.g. an assert is usually triggered very close to the bug, while crashes are usually only the end result of a whole cascade of events triggered by an initial bug.
Fair, but the counter is eventually you have enough real world testing to have confidence and so you no longer need the assert. If 1 in 10 user's have a crash that is unacceptable. However, what if it's only one in a million, or one in ten billion? At what point can you say, 'it's no longer worth worrying about that rare case.'
And this is why games are different from medical devices. In medical devices, I would worry anyway. In games, especially in a tight loop, it may be that extra CPU instruction is an important difference in performance.
It depends what you want to get out of it, and what you think art itself really is.
If it's nothing but an end product, that needs to fit a specific aesthetic, with a specific sound, then I probably agree. AI is making that "pointless" in a way.
Almost everyone I know who's been an artist for years though, has come to a similar realization: What you set out to create, and what it turns into through the process of creating it are different things. The meaning, truly is found along the way.
You can always be better, there's always more to learn. Nothing is ever truly perfect, or "complete"
If you write harmony, there's always a different way it could be written, that might fit better, or be more interesting. If you do sound design, whether that's with getting different guitar tones, synth programming, unique recording techniques, there's always more to learn, or a different way to approach it.
If the only point is an end result, then AI can deliver a simulacra of that.
For everyone I know that loves music, or working with DAWs, the end result is an ever shifting target as you learn more, and understand music in a different way.
Ultimately, there are no shortcuts to making something new, because the practice of trying to make things is what results in what your art becomes. Tools and technology can shape what that thing ends up being, but they (traditionally) don't replace the process of creating it, and the feedback loop between who you are and the decisions you make along the way.
Stripping all of that out, and jumping to a "finished" product, is, well very product focused, but to me completely devoid of art or musicianship.
Some people seem to compare this to sampling, but anyone who's ever actually worked with sampling in a creative way will realize how hollow that comparison is. Almost all good sampling still requires a good deal of active feedback, between the person working with it and the way THEY hear what's going on.
Remove the person from that loop, replace the decisions with a general vague notion, and you end up with something that sounds "like" music, but that feedback loop is broken.
I see the same thing with all the AI UI design that's coming out. It's all generally quite competent, and exactly the same. Great for a business tool, where maybe the velocity and an acceptable MVP is the only point, but terrible for actual design and novel thought.
TL;dr: Why do it? Because you want to, and you think that with enough time engaging with something you'll change, just as it does, and the result isn't something you could have ever predicted when you started. It changes you, and that's the point. Just like learning an instrument, or learning to code. It's not purely about the produced result, and that very result fundamentally is changed by you actively engaging with whatever the medium is.
> Stripping all of that out, and jumping to a "finished" product, is, well very product focused, but to me completely devoid of art or musicianship.
This hits very close to the philosophical core of the AI debacle.
All hardcore fans of AI just want things done. The process is of no interest to them.
This is truly an eschatologic problem of desire. Consider:
Some people want to grab their result, attain satiation, have orgasm, and die, right now.
Others would much rather enjoy the process, the meal itself, indulge in gentle act of love in tune with the partner, and just keep on living their lives, continuously.
Thanks, I like this answer. I think part of my problem is more general, a struggle to enjoy something when I can tell I'm not good at it. It's kind of a circular problem, I will need to spend more time on it to get better and I need to conjure confidence that I could do so out of the ether.
I have experienced the process you're talking about, although to some degree I feel it's symptomatic of a lack of skill. I start out with some kind of inspiration in mind, but end up with a compromise between what I can do and what sounds good when I fiddle around with things. Part of me feels dissatisfaction that I don't know which knobs to turn to get what I want, but I suppose that's just the normal learning process (albeit less structured than those I have gone through in the past, which is its own obstacle sometimes).
I’ve also struggled with the “not enjoying something because I suck at it” problem, and it’s a tough one. The answer is to remove expectations, but much easier said than done.
That said, I wonder if doing it with other people who suck would help. I started playing ice hockey as an adult, and the thing that got me over the initial hump of being completely useless was doing lessons with other newbies in my exact shoes (or skates) rather than trying to go right to full speed games.
This works for simple apps, utilities, and demos/mvps. Not great for actual applications.
What about when you're embedding your GUI into an existing application? or for use on an already taxed system? (Audio plugins come to mind)
What if something is costly, that you need to compute dynamically, but not often, makes it into the frame? Do you separately now create a state flag for that one render object?
> What if something is costly, that you need to compute dynamically, but not often, makes it into the frame? Do you separately now create a state flag for that one render object?
The point of immediate mode UIs is not necessarily that there is no state specific to the UI, but rather that the state is owned by user code. You can (and, in these more complex cases, should) retain state between frames. The main difference is that the state is still managed by your code, rather than the UI system ("library", whatever).
> What about when you're embedding your GUI into an existing application? or for use on an already taxed system?
You should check out the gamedev scene. It's soft real-time, and yet dearIMGUI is the choice for tooling. Immediate-mode is an API-design, not the implementation details. All Immediate-mode GUIs retain data some data, and for that reason they each have their own APIs for retaining data in various capacities. Usually something really simple like hashing and component-local state.
> This works for simple apps, utilities, and demos/mvps. Not great for actual applications.
Respectfully, I don't think you're informed on this. Probably the most responsive debugger out there is RAD Debugger and it's built with an IMGUI.
Immediate mode UI optimizes for the worst case. That is the case you care about most for real time applications.
Retained mode is more optimal when not much changes but if a lot of stuff changes at once it can be worse. So for real time applications like your audio example or games you want immediate mode. Retained mode is better for saving battery though or can be.
> Do you separately now create a state flag for that one render object?
That can be a reasonable choice sometimes. Note that the point is that you introduce state where necessary, rather than stateful UI being the default as with retained mode.
> What about when you're embedding your GUI into an existing application? or for use on an already taxed system? (Audio plugins come to mind)
I've used ImGui in exactly these kinds of projects. Game engines already render graphics, so it is just part of the same pipeline. Rendering the gui is instant, how many fps you want to render is up to you.
For interest sake, have a look at the flutter engine. It does this kind of diff on each build (meaning, each time the ui tree gets modified & triggers a rebuild); they split their objects into stateful & stateless, and then in your own code you have to make sure to not unnecessarily trigger rebuilds for expensive objects. So it kinda force you to think & separate cheap & expensive ui objects.
Gemini & ChatGPT have not done well at writing or analyzing OpenGL like rendering code for me, as well. And for many algorithms, it's not good at explaining them as well. And for some of the classical algorithms, like cascading shadow mapping, even articles written by people and example source code that I found is wrong or incomplete.
Learning "the old ways" is certainly valuable, because the AIs and the resources available are bad at these old ways.
I can definitely say I wouldn't know half of what I do and probably wouldn't have kept at it with writing GLSL and learning more about how GPUs really work without a lot of his freely shared knowledge over the years.
His articles on his website are very much worth a deep read too!
>Try to buy Need For Speed Most Wanted (2005). You can't.
I searched the biggest used online (flea)marketplace in my country and I could find the DVD for sale from several people. So I can buy it and play it right now legally if I want to, without resorting to piracy.
What point were you trying to make with this? Because I also can't buy a brand new 1969 Ford Mustang. Nothing is made forever.
Agree. However I'm willing to cut EA some slack here. NFS series (like some other games) has music in it that's been licensed by the devs for a limited time.
Selling the game today would mean either ripping out the music which is what made the game fun, or paying the record labels more money, which will not be offset by the few sales to 30+ year old nostalgics.
But at least EA isn't actively preventing you from playing that old game if you own a licensed copy by requiring always-on DRM.
> However I'm willing to cut EA some slack here. NFS series (like some other games) has music in it that's been licensed by the devs for a limited time.
If that practice gets killed as well, that'd be a bonus.
> Selling the game today would mean either ripping out the music which is what made the game fun, or paying the record labels more money, which will not be offset by the few sales to 30+ year old nostalgics.
Well if the market can't provide, Pirate Bay can. Maybe they should fix "the market".
Not agreeing with either side here, but, printing money and handing it to an investment class who then launders it through their companies, to acquire more assets vs printing money that goes into infrastructure, works projects, or R&D are wildly different.
Not all monetary inflation is the same, and the destination of the money and the work produced with it can actually have quite an impact on the true wider economic effects of that increased money supply.
To be very clear, I'm not saying monetary policy is magical, or that it doesn't cause inflation.
It has very little to do with "things you like" and a lot more to do with "utility to society accomplished with the policy" along with the velocity of that money afterwards in local economies (IE. a worker is more likely to buy, well, food and rent, education. A PPP loaned exec will buy assets, or another yacht)
Believe it or not, one of those can generate more widespread economic growth than the other, for the same amount of money printed
> They're identical from the perspective of creating inflation, even though they might have different outcomes
That will only hold true if you look at only the singular issue:
Printing money while not changing economic output increases it's availability and thus decreases it's purchasing power, which we call inflation.
However: if the money goes towards things like clean air and other infrastructure, there are suddenly less things you need to pay for (clean air, water, cooling in summer, cost of transportation become cheaper), which effectively leaves more money for you to spend on wants, offsetting the effect of inflation partially/fully.
Another effect is that correct public can increase overall value generated (think: "nice, with cheaper transportation my home sales business is now viable and contributes to the value/tax pool"), so the "new" money can become backed by real value, again offsetting the loss of spending power for the average Joe.
I agree that if you add more variables that counter the effect then the effect will be countered. But that seems tangential to whether you pay for something by printing more money vs another means. If you use another means you don't inflate the currency, and you decrease inflation, leading to a better outcome.
Spending on things like infrastructure or R&D might in theory increase productivity by more than it increases money supply, in which case it would not result in inflation.
Not uncommon for audio companies to also write their own containers and internal STL for ex. plugins as well.
reply