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.
Why write a line of code for a car's fuel injection and go back home at 5pm to your wife and kids when you could stay overnight and be hacking on an ill-designed networking protocol for an AAA game while eating 5% discount cheetos?
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.
Yeah. I've offset that by then long-pressing on any particularly sensitive apps I don't want to risk other people potentially being able to control via Siri and turning on "Require FaceID" just for those apps. Which then blocks Siri from being able to interact with them too.
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).
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.
JSON Schema is an unofficial spec with a bunch of competitors and multiple versions, not all of which are compatible. I don't think you can compare it to XML schema validation.
I'm also not so sure about JSON being easier to map to common data structures. The lack of order guarantees within objects makes things like ordered maps quite annoying (you need to either use an array of entries with key and value, or an index within the mapped objects).
"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.
Gotcha! Thanks for the rundown. I started programming at the time when we were transitioning from XMLHTTPRequest to Fetch with json so I know of XML but basically only learned about json.
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.
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.
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.
reply