| > I haven't encountered hand-written assembly outside the SDK. Right, that was my point — that there was always still hand-tuned non-portable code "in" each final game build, since such code was 1. part of the SDKs, and 2. the SDKs were themselves built using some sort of macro-based code-preprocessor framework (i.e. a custom compilation toolchain that did whatever the platform owner wanted it to do), rather than just being a regular linkable library of extern-C symbols that you could use with any compilation toolchain targeting the correct architecture. And, further, the reason for this, was that the 8th console generation was the first time we ended up, unilaterally across all platforms, with OSes that acted to provide Hardware Abstraction Layers for games, with "driver" code living in the OS, opaque to game application software, and able to be upgraded independently of game application software. Until then, games were mostly expected to know how to do MMIO against the various device ports of the CPU/GPU/etc. themselves — and the SDK helped with that by compiling down directly into manipulations of those device ports. (In short, the "device drivers" were part of the SDK, rather than in the console firmware.) We didn't get truly "just a C library, that just makes system calls to the OS kernel" SDKs until the 8th console gen. (It was a distinct shock to see when I first read through the Wii U SDK docs, after having been a Wii developer.) This was also precisely when we started to see third-party vendor-neutral game authoring solutions (e.g. Unity) ship "export to console title" features — because doing so now just meant cross-compiling the game for a known ISA, and linking against a plain-old directory of SDK libraries. And while yes, the Xbox was an interesting exception — "the Windows 2000 box" — it wasn't entirely immune from this. Much like Wii games shipped with their own customized/patched exokernel forks (the "IOS" firmware), Xbox games shipped with their own vendored [and potentially customized-by-Microsoft] versions of DirectX et al. And these weren't like the user-mode Windows DirectX library: they didn't go through the OS, but rather did MMIO directly, just like other platforms' SDKs were doing. (And this is why HLE emulation, which you'd intuitively expect would work great for the Xbox, actually sucks! You need to low-level emulate each game's variant of each DirectX library to get everything perfect.) > I guess it depends on what you mean by "regular user-mode applications" "User mode" has a specific meaning: that the CPU has virtual memory management, and privilege levels that mask out certain instructions; that there are privileged / ring-0 processes that run with full ability to execute instructions, and unprivileged / ring-3 processes that run without full ability to execute instructions, but which must instead use system calls to context-switch to an OS kernel that itself is privileged and will perform the privileged action on behalf of the unprivileged process. As of the 8th gen, all the consoles have a CPU of this type, and do this with their apps. It's the first gen where you can really call the games "application software." (Which all the platform owners seem to realize — they actually use the words "application" or "software" in the OSes for these consoles in ways they previously didn't.) |