SSE never had aliasing, so OP’s comment is strictly incorrect either way.

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.

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.

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 studio is funding it and has been clear they’ll release it when they feel like it.

Quite an achievement…

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.

If they can pass that hurdle + add WDDM, I'd be willing to take another look at them even if application compatibility remains hit and miss.

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).

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.

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.

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.

Unfortunately, like many in that group, it seems you'd rather double down on your ignorance.