Carmack's Hands On Impressions of Xbox 360 & PS3

For all of the curiosity about Carmacks methods, you guys do realize that he does answer emails sent to him, sometimes. I don't remember what fora I used to frequent, but one of the posters there use to email him questions all the time (and usually got back answers as well).

Just thought I'd throw that out there.
 
Yup, that was Reverend. He's a Carmack fan par excellance and thinks JC is God.

Ah yes. New look of forum threw me off once again! Hmm I don't seem to recall seeing Reverend's presence in this thread. Is he still around? *Runs to check member list* hmm, nope not there....
 
It's his favoured console to develop on.

Spot on, there. Of course it's partly because of the hardware and partly because of MS's outstanding dev tools -- but Carmack has promptly and early on pointed all of that out, too. "Bias" would be a wrong word to use of simply sound pragmatic judgment.
 
Well I like to remind myself that Carmack isn't really that much of a gamer. He's a technologist. If he doesn't like a piece of hardware, there's usually something to it. I'd say it usually means that the hardware is poorly optimized for its intended task.

I highly, highly doubt he's partial to a particular vendor. The guy just likes things that make sense and are well-targeted to do what he wants. He has shown many times in the past to prefer open standards and doesn't exactly bow to these companys' demands. Heck, he developed Quake on a NeXTstation and preferred NT and OpenGL to 9x and Direct3D forever basically. It really is too bad D3D has won, but I think it was rather inevitable. It is entirely game developers' faults tho. He ported Doom to Jaguar and let people know the machine sucked. The GPUs we use today are at least partially based upon how his game engines have worked along with input for future 3D tech plans. Especially from NV, with all their optimizations for z-rendering (Doom3).

And, as has been said, Quake 3 was one of the very first games to ever make a stab at SMP support. He looked at the possibility, gave a shot at implementing it, and found that it wasn't going to be remotely simple or all that beneficial. And we've heard a bunch of other devs say the same thing rather recently.
 
I highly, highly doubt he's partial to a particular vendor.

I do not know if he is still partial but he is a business man and business men are partial to money. He was on xbox advisory board. Once all the meetings end you think they all stop talking to each other? No my friend. That is the network within which you operate. This is real world business. If I was Carmack, I would be partial to Xbox360 for business and personal reasons.
 
PC&Mac. But what's about the PS3? Does id's PS3 guy use PSGL/OpenGL ES or - as a smart boy - the other API, that is mauch closer to metal (Libgcm)?
To code to the metal, you need to know the hardware you are targetting. You can't poke around with memory address and registers if they're not there to poke around in. In the computer space, a software interface is needed as you don't know what hardware you'll have. You don't access the silicon directly, but lay out your intentions and have the driver translate them to the hardware. In the console space, because the hardware is identical betweens platforms, you know the memory maps and registers, so there's nothing in principle stopping you from coding your entire game in assembler. Obviously for ease of development higher level languages and APIs are nice, but AFAIK there's nothing on any console preventing devs from coding as lowlevel as they choose to go.

I guess there may be exceptions. A console manufacturer might limit devs to using high-level languages for BC reasons. eg. The Amiga provided a system for devs. Those that ignores this and wrote to the metal found their titles were incompatible with revisions of the hardware. You'd be sacrificing a lot of potential and developer freedom if you did that though. You may also have devs limited to some API for security and stability reasons, especially accessing the system services.

Still, unless someone can show otherwise, I'd expect developers on any of the consoles to be allowed to write as low-level code as they want, and the reasons not to are ease of implementation.
 
Would you happen to know a (relatively) simple example of a shader in ASM versus HLSL/Cg/GLSL :?: (for illustrative purposes)
 
Still, unless someone can show otherwise, I'd expect developers on any of the consoles to be allowed to write as low-level code as they want, and the reasons not to are ease of implementation.
On at least one current console there is a submission rule that means you cannot write GPU command buffers except by approved APIs.
 
Although XB360 is the most likely candidate, compatibility with PC isn't inherent in the platform nor a requirement of games. XB360 games don't need to be directly portable to PC. The fact it uses a PPC derivative CPU is proof of that! XNA provides a framework, and it could be devs are required to function within that framework for security reasons, or future BC reasons.

Another candidate is Wii. We know very little about how development is handled on Wii. Given Nintendo's love of reselling old title to new hardware, I expect they'd love to maintain compatibility between current hardware and future hardware, and enforcing devs through APIs means emulation becomes a lot easier.

And all that said, Sony could be wanting to take this route for those same reasons. Traditionally they've been open to hardware bashing code, but they may want to be more 'protective' this time around. If the API is thin enough, attainable with fixed hardware, they may consider it suitable benefit for future plans versus the trade-off in performance the best developers could get from the hardware.
 
Although XB360 is the most likely candidate, compatibility with PC isn't inherent in the platform nor a requirement of games. XB360 games don't need to be directly portable to PC. The fact it uses a PPC derivative CPU is proof of that! XNA provides a framework, and it could be devs are required to function within that framework for security reasons, or future BC reasons.

Very possibly, although im still of the opinion the MS wants the xbox to bump up PC gaming and vice versa, afterall, both ways MS wins and Sony loses.

So I believe encouraging cross platform development and compatability is in their best interests. Hence XNA, the common controller, Live etc...

Has anyone noticed how similar the 360 and games for windows logo's are? Similar to the point were one quite seemlessly transitions into the other on adverts...
 
I would see the PS3 with the submission requirement before the 360. Sony's made a lot of noise about changing and upgrading the PS3 platform over time, which would make more sense if programming to an API instead of the metal. Couple that with Sony's penchant for playing it safe to protect possible future features, i.e. the "just in case" RAM/VRAM reservation.
Of course, Deano did say "at least one."
 
PS3:

Cedric Perthius said:
Beyond High Level APIs
A low level graphics API exists:
  • proprietary
  • small and simple
  • let the user create and send command buffers
  • deep knowledge of the RSX®internals needed to really take full advantage of it

Xbox 360:


Matt Lee said:
Direct3D 9+ on Xbox 360
Communicates with GPU via a command buffer
  • Ring buffer in system memory
Direct Command Buffer Playback support

Matt Lee said:


GPU: Work Flow

Consumes instructions and data from a command buffer
  • Ring buffer in system memory
  • Managed by Direct3D, user configurable size (default 2 MB)
  • Supports indirection for vertex data, index data, shaders, textures, render state, and command buffers
This presentation mentions command buffers numerous times... Matt always seem to mention it with respect to D3D.
 
Back
Top