THQ Clarifies Claims of "Horrible, Slow" Wii U CPU 281
An anonymous reader writes "THQ has clarified comments made by 4A Games' chief technical officer, Oles Shishkovtsov, about why their upcoming first-person shooter, Metro, won't be available for Nintendo's new Wii U console. Shishkovtsov had told NowGamer, '[The] Wii U has a horrible, slow CPU,' by way of explaining why a Wii U version of Metro wasn't in the works. Now, THQ's Huw Beynon has provided a more thorough (and more diplomatic) explanation: 'It's a very CPU intensive game. I think it's been verified by plenty of other sources, including your own Digital Foundry guys, that the CPU on Wii U on the face of it isn't as fast as some of the other consoles out there. Lots of developers are finding ways to get around that because of other interesting parts of the platform. ... We genuinely looked at what it would take to bring the game to Wii U. It's certainly possible, and it's something we thought we'd like to do. The reality is that would mean a dedicated team, dedicated time and effort, and it would either result in a detriment to what we're trying to focus on or we probably wouldn't be able to do the Wii U version the justice that we'd want.'"
Re:Better get used to it, THQ (Score:5, Informative)
Consoles traditionally were single purpose devices. The OS consumed next to nothing and the game could have most of it. Plus, games were supposed to be tweaked to come in as low in resouce usage as possible.
Obviously, some of that has changed with them able to stream netflix/browse/online gaming. Even the Wii U, which has 2GB ram, 1/2 of that is dedicated to the games and GPU and the other half to the OS, which is pretty damn disgusting, if you think about it.
Re:Return of the SNES (Score:5, Informative)
SNES wasn't slower than Genesis. While the clock speeds in MHZ may say one thing, the 65c816 runs most instructions in fewer cycles than the 68000.
Re:Return of the SNES (Score:5, Informative)
IBM's PowerPC are similar, plenty of instructions that offer one cycle completion as the old 65C816 did. Or better, look at the z196 that IBM has developed, its capable of 5 operations per clock cycle as IBM is a fan of one core, multiple sub-processing units.
The Cell processor used in the PS3 is one PPE "core" with 8 SPE's (processing units), one is locked from the factory, one is dedicated to the OS, and 6 are for the game itself. While the newer IBM PowerXCell 8i, at a mere 2.8Ghz, it is capable of 179.2 GFlops (SP). Because it can process 64 single precision floating point math instructions per clock cycle.
Verses the x86 (and many others from that period such as the Z80) which is actually designed as a 3 cycle per operation machine, especially when fetching data, it took 3 clock cycles to access or write the new data. The 68C816 is 1 cycle for a read or write operation.
More then likely its not a issue of the processor in the Wii, and more of a issue of how much time/money investment the Wii market is really worth to them to recompile a dedicated Wii capable binary.
Re:Return of the SNES (Score:5, Informative)
As part of the overall plan for the Super Nintendo Entertainment System, rather than include an expensive CPU that would still become obsolete in a few years, the hardware designers made it easy to interface special coprocessor chips to the console. Rather than require a console upgrade, these enhancement chips were included inside the plug-in game cartridges.
http://en.wikipedia.org/wiki/List_of_Super_NES_enhancement_chips [wikipedia.org]
Re:Better get used to it, THQ (Score:3, Informative)
ugh, first off a i3 is a completly different (slower) architecture, and second nintendo usually clocks there cpu's way down so they can have a small/quiet/reliable console. which is perfectly acceptable, wanted actually.
and finally when it comes to the vast majority of games the GPU does the heavy lifting and upgrating the cpu does little, the wii has a great gpu, and thus why it's comprable to the ps3/360 but is smaller and quieter.
you calling the cpu "shitty" is both rude and uninformed
Re:any objective numbers? (Score:4, Informative)
You realise that lower scores are better with SunSpider, right? That would make it 2 and a half times slower than the iPhone 5. Of course, a large part of that will be down to the browser.
For reference, a 2.4Ghz Core i7 scores 252 in Safari, so it would appear to be a *lot* slower than a 3.6Ghz current x86 CPU.
Re:Better get used to it, THQ (Score:5, Informative)
Consoles traditionally were single purpose devices. The OS consumed next to nothing and the game could have most of it
How traditional are we getting? Traditionally, consoles didn't even have an OS...
Re:any objective numbers? (Score:5, Informative)
Seriously guys, mod parent up. Every report that I've seen that seems close to "official" states a quad-core processor with some level of hyperthreading. If this is indeed true, it explains quite a bit why some say it is "horribly slow"... it is only a matter of single-thread vs multi-thread performance.
If this is true that there is 4x hyperthreading per core, that would give 1/4th the CPU processing power to each thread, putting it at 750MHz per thread (assuming no HT Combine). This would very quickly and easily explain why things like JavaScript benchmarking would be slower, as that generally runs in a single thread within the browser.
The software mentioned in the article is most likely not designed for multi-threading that well either, since it is designed for the PS3 (single-core PowerPC) and XBox 360 (3-core PowerPC). Their statement even suggests that the Wii U is capable of running the game just fine, if they "changed" something (which would be to make their game engine more optimized for multi-threading)
Re:Better get used to it, THQ (Score:3, Informative)
NES had built-in 2Kbytes "work RAM" and 2Kbytes VRAM (to hold "name tables"). Work RAM was directly addressable and useable by the CPU, VRAM accesses needed to "go through" the PPU and could not hold executable code or otherwise be directly accessed.
It also had 256 bytes of OAM RAM that the PPU used to determine sprite attributes such as X position, Y position, pattern index, and other attributes. Also only indirectly accessible via PPU. Using this for any other purpose was difficult put probably possible - supposedly the contents of this RAM would fade if not refreshed - meant to be done per-frame using a PPU DMA feature.
NES by default had 32k of ROM accessible unless external mapper chips were used, which could also provide additional RAM.