I think AI is fine, the problem is what you mentioned: vibe coding.
Have AI do work for you, it’s certainly faster in most cases. But just know exactly what it’s generating and building before putting it into production. That’s not some massive bar to surpass.
I was going to say, smooth scrolling is one place where VGA was fairly simple to work with, since it didn’t have to deal with chunky graphics/bitplanes or specific timing tricks.
In fact, Carmack specifically states that packed pixels were the impetus for id’s side scrolling experiments that led to Commander Keen and its ilk.
Yeah, OPs claim feels disconnected from C’s identity. C stayed conservative because the areas where it excels (to this day) benefit from its “portable assembler” design history. A history with no C++ wouldn’t have changed that, instead another (either non-C extended or alternative C-adapted [Obj-C, for instance]) language would have taken the market C++ did; likely with a larger runway time due to the lack of interoperability/superset compilation.
I mean, when you're getting paid 40-60% for doing more complex work than app/web development...yeah, the drop-off is almost inevitable. Eventually people (unless they just really love making games) just go "f this, my career is more important".
If you wanna do low-level code, you can go into embedded, sponsored OSI-companies, Microsoft, etc and get paid the same to more than gamedev with 10% of the stress and no crunch. If you wanna get paid much more and do more "vibe"/fun coding, you can go into app/web dev. If you want stability, you go into fintech/medtech/onsite/etc.
Gamedev offers the worst of all worlds and then constantly posits "why is there so much turn over?"...because you made the industry suck to work in.
The difference, and the reason these comparisons are always disingenuous, is that Rockstar didn’t have the consumers fund its development and miss its promises repeatedly.
The studio is funding it and has been clear they’ll release it when they feel like it.
That was the argument back in the day too. For people/devices not looking to run Windows XP/Vista.
I don't think the metric has ever changed. What has is the scope as Microsoft continues to chug along. But, I believe, their goal is still primarily some hybrid of Win98/Win2K compatibility.
The biggest limit with these older consoles is the VDP/PPU. You can't just render directly to the screen because a framebuffer doesn't exist, instead you have to render to tile and then have the pixel pipeline render those sequentially to screen. So you're fundamentally limited by how fast that can update.
Systems with DMA like the Genesis could just act as a dumb framebuffer to whatever the cartridge decides to dump down the address lines. The Gameboy is a little more difficult, but could also theoretically do it as well if you decide to dump the FPS a bit and/or lower the resolution, and buffer the frames. Which is essentially what the faceball2000 devs had to deal with. And you can speed that up a bit by "racing the beam" (rendering the next frame to a previous tile as the next tile is blitting).
"Structured" in this case refers to being able to be directly mapped to a data structure. Think protobuf and other similar transport mechanisms. The recipient knows what structure to expect because it's not a valid XML document if it's breaking those constraints.
JSON is not, it is closer to the PHP, JS, etc "object" type, which is an ephemeral object with arbitrary member associations.
And, to be clear, this is not a value judgement. They just excel in different fields. XML tends to be easier for strongly and strictly typed languages such as C/C++, C#, Java, etc where you can use the schema to generate your structs automatically. Vanilla JSON is easier for higher level languages that don't require you to manually create a mapping/validation level. JSON Schema tries to bridge that gap to a degree, but isn't built into the standard and isn't even universal.
But, ultimately, both are perfectly sufficient for either use case. It just depends on how much massaging you want to do to make them work.
JSON Schema is largely an answer to people seeking that type of built-in validation. As I'm not a huge proponent for either (a tool is a tool and you work with it in its ecosystem), I don't have personal feelings on it's adequacy.
But, I would suspect, proponents of XML would still point to it's deeper typing system, document structure (especially the hierarchical features of it), and extremely mature ecosystem + tooling (such as XSLTs) as reasons to prefer it over JSON w/ JSON Schema.
The main benefit of XML over JSON is that it is structured, and can be associated with Schema's for built in validation.
Obviously, that's only a benefit if you care about and utilize those features; most teams doing JSON integrations will just build those into the consumer in lieu of them being provided by the transport. But it is something that some people (especially larger enterprise organizations) value.
People also have have the choice to ignore their racist grandparents spouting right-wing ideology or try educating them out of hope they'll shift their viewpoints.
Unfortunately, like many in that group, it seems you'd rather double down on your ignorance.
They pay for the hardware that they run Linux on. Apple's hardware division is very profitable without the "value" adds they run through their ecosystem, and those people never would have bought into the ecosystem whether they used MacOS or not.
And yet, your little slice of the world doesn't represent the world at whole.
If you're ignorant of the situation, maybe don't come out with such a self-centered (and arguably, arrogant) statement; and especially don't double down on it when corrected.
The vast majority of people that buy Macs for the ecosystem aren't going to switch to Linux. That market will remain untouched. Outside of a few gamers who might want to put up with the x86-to-ARM translation layer and (for most A to AAA games) Proton to run some non-Mac games. And even they'll probably still dual-boot.
There's a portion of another market: people who want to run Linux and want a powerful laptop who buy x86 Laptops right now. Apple could expend very little relative effort while offering no official support by helping Asahi get that to a first class platform. They won't capture them in the ecosystem (and they never would have) but will still benefit from hardware sales to them.
Obviously, if they sold their hardware at a loss and subsidized that with ecosystem capture that would be a non-starter. But from everything we know, the hardware itself is very profitable.
Your comment said "welcome to Amiga games", as if it were unique to Amiga. The context of the thread is PC, where they had their own booter/bare-metal games.
So you don't have to go to "Amiga games world", you're already in the proper world.
Have AI do work for you, it’s certainly faster in most cases. But just know exactly what it’s generating and building before putting it into production. That’s not some massive bar to surpass.