Slashdot Mirror
John Carmack Discusses 360's Edge, Considers DS
Via a Gamasutra post, John Carmack's comments on upcoming id choices. Game|Life has a few quick comments on Carmack's hope to bring Orcs and Elves to the DS. This would be id's first game on a Nintendo platform in some time. Likewise, he makes it clear that he considers the 360 the dev platform of choice due to the ease of development on the console. From the article: "the honest truth is that Microsoft dev tools are so much better than Sony's. We expect to keep in mind the issues of bringing this up on the PlayStation 3. But we're not going to do much until we're at the point where we need to bring it up to spec on the PlayStation 3. We'll probably do that two or three times during the major development schedule. It's not something we're going to try and keep in-step with us. None of my opinions have really changed on that. I think the decision to use an asymmetric CPU by Sony was a wrong one."
He makes impressive engines. I'd say when you're talking pure development, then what he says carries a lot of weight.
I sure as hell wouldn't take his advice on game design though. He repeats the same tired formulas over and over. DOOM was cool in the 90's, but these days you gotta be a bit more creative.
The hardware designers at Sega probably thought much like the way you do. That's the idea behind the massive failure called Saturn. Keep in mind, Sega's arcade boards used to have multiple processors. If their coders could deal with that, why wouldn't everyone else?
Now, don't get me wrong, I love the Saturn. Good developers could do amazing things with it -- Radiant Silvergun, Panzer Dragoon Saga, NiGHTS, Powerslave, Virtua Fighter 2, Astal, Guardian Heroes... but most chose to develop for the slightly less powerful and far more developer-friendly PlayStation.
And why? Because it made sense. It's not just a matter of developers being lazy or unskilled; if it is too hard to develop for a system, that also means doing so will take longer and cost more.
Circumcision is child abuse.
I think maybe you misunderstand the issue here... it's not that multithreading is hard. In fact, the XBox 360 has three cores if I remember correctly... any game for the XBox 360 is multithreaded. The problem is that the Cell processor uses heterogeneous cores... that is, there is one main core which is basically a regular PowerPC core, as well as 8 additional cores (1 of which is disabled on the PS3) which are completely different, designed for number crunching on large amounts of data, and are radically different to program for. Having actually done a good bit of programming on this architecture, I find that it is not actually that difficult to get a program to take advantage of a reasonable amount of the processing bandwidth in the Cell processor... however, it is VERY difficult to utilize a larger amount of the available computing capability of the processor. Therefore, most developers have found it to be much easier to get X amount of performance out of the XBox 360 than it would be to get X amount out of the PS3, even though in theory the PS3 is capable of X+Y.
So, it sounds to me like you haven't DONE any Cell development.
There's a huge difference between Cell and "PPC with vectors". It's called local store. Each SPE has 256KB of local storage. You have to have your code in there, and then stream data through. That means you have to do a fair amount of setup and partitioning specifically around that 256KB limit, which wouldn't apply on a multi-core PPC. That's a real issue, and you can't just paper it over for real projects.
And yes, in theory, the tools should be able to hide some of that from you. That's why Carmack's comments about the tools are so damning. If there has ever been an architecture which desperately needs polished and mature tools, this is it.
Also, I don't know where you get the idea that SPEs can do scalar code. They are 100% vector-only. The closest they can get is to emulate scalar code by ignoring the rest of a vector while manipulating only its first slot. That can be done, but it leaves you with a very slow processor spending a lot of its time masking things out and merging vectors together. (or, if you just omit those slots, and use only one slot out of each potential vector, your data takes much more space; 4x as much for 32-bit objects, 16x as much for bytes.)
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
No, Carmak is NOT using DX9. He's using an Xbox 360 - that's something completely different. Granted, the API looks a lot like Direct3D 9, but it's not actually compatible, and it exposes 100% of the hardware features directly with minimal (virtually zero) driver overhead, no stupid driver bugs, no emulation, no possibility of missing features...
On a PC, OpenGL and Direct3D 9 are almost exactly equivalent. On a modern engine, 70% of the code is (or could be, if you put a little effort into the design) API-independent. Things like scene traversal, resource management, batching, loading and generating geometry and so on. In the API-specific part, you have a small piece of code that does useful work, and in an ideal world this is all you'd need. It simply manages resources for you, so you can (for example) tell it to load a mesh onto the video card and it does it, or give it a triangle mesh and tell it to draw it.
The larger part is dealing will all kinds of stupid garbage. For example, in Direct3D 9 you can lose any data you have stored in VRAM at any time, so you have to detect this condition, re-load (or regenerate) all the data, and fix it before you can do any more rendering. It's not difficult, but it's more work. In OpenGL (and on games consoles) you do not need to do this. With OpenGL, you need to detect and load appropriate extensions, which you don't have to do as much in Direct3D 9 (you do have caps bits, which serve much the same function). So in the OpenGL code, you might need a couple of extra paths to deal with hardware / drivers that don't support specific extensions. You could have four separate paths for things like render-to-texture, or several different texture formats for floating point textures, you might have to deal with drivers that don't support S3TC compression, and so on. You've got to deal with the operating system, other software components you're using, and the whole thing's a huge mess.
That entire part is unnecessary on a console. You have one piece of hardware, which maps directly to the available API, with 100% of all features exposed, including things that PC APIs deliberately prevent you from doing. It makes writing code so much simpler - you write some basic, low-level rendering code which interacts directly with the hardware, then get on with the useful task of writing the game engine. You never have to worry about whether or not you've hit a slow path (happens in OpenGL a lot) or a bug (happens in Direct3D a lot, and OpenGL if you're using Intel's rather crappy drivers) in the driver, because the drivers don't actually do anything more than queueing command packets for sumbission to the video hardware.
The same applies to the Xbox, but also to the GameCube, the Wii, the Dreamcast, and to a lesser extent the PS2 (because you have to write all rendering code in VU assembly to do anything useful).