As a developer who's worked in games, embedded, and real-time situational awareness software (ex. air traffic control), my feeling is exactly the opposite.
People often greatly underestimate the amount of performance sensitive software out there, often because they're used to working on software where the hardware isn't a fixed constraint, or are indirectly relying on optimized C/C++ software provided by the system itself.
Moreover, simple benchmarks which are often used for comparing languages are not a valid indicator of the performance available in a lower-level language.
For example, switching loop-processed data from a standard AOS (array of structures) to a SOA (structure of arrays) format can improve performance by orders of magnitude by reducing cache misses (on an i7, main memory latency is ~25x that of L1 cache).
With that latency difference in mind, imagine for a moment the impact of iterating an array of objects stored disparately in memory versus a tightly packed array.
Or more related to memory management, a common allocation optimization used in games is to provide a block of per-frame memory; allocations are a simple addition, and deallocation is an assignment. All the easy cleanup of GC, but with a constant (and insignificant) cost.
Certainly most of the code does not need to be C++, nor heavily optimized; even the 16/32ms per frame game industry tends towards garbage collected scripting languages for a significant portion of the code base. That does not however obviate the necessity for a systems level language to provide the capacity for such optimization.
All of them? It's unheard of at a AAA development level to sell an engine without full source access; CryENGINE, Unreal, iD Tech, and Gamebryo all offer full source licenses, to name a few examples.
At least the DMCA requires the submitter swear under penalty of perjury that the notice is accurate. The current YouTube system has no penalty for false claims.
Rebuilt from the core isn't very specific; the architecture has switched from PowerPC to x86. There are some solutions (emulation, secondary chipset), but none that aren't difficult and expensive.
As XNA is .NET based, they would only need to port the runtime libraries to the new native APIs.
They dropped support for the only SDK they offered that produced forward-compatible games.
Unless they announce a new form of XBLIG, the only way for indies to release games for the One will be via a publisher, and even with a distribution-only deal, it means MS is effectively enforcing a tax on indies that's paid out to AAAs.
People often greatly underestimate the amount of performance sensitive software out there, often because they're used to working on software where the hardware isn't a fixed constraint, or are indirectly relying on optimized C/C++ software provided by the system itself.
Moreover, simple benchmarks which are often used for comparing languages are not a valid indicator of the performance available in a lower-level language.
For example, switching loop-processed data from a standard AOS (array of structures) to a SOA (structure of arrays) format can improve performance by orders of magnitude by reducing cache misses (on an i7, main memory latency is ~25x that of L1 cache).
With that latency difference in mind, imagine for a moment the impact of iterating an array of objects stored disparately in memory versus a tightly packed array.
Or more related to memory management, a common allocation optimization used in games is to provide a block of per-frame memory; allocations are a simple addition, and deallocation is an assignment. All the easy cleanup of GC, but with a constant (and insignificant) cost.
Certainly most of the code does not need to be C++, nor heavily optimized; even the 16/32ms per frame game industry tends towards garbage collected scripting languages for a significant portion of the code base. That does not however obviate the necessity for a systems level language to provide the capacity for such optimization.