Slashdot Mirror
Are Consoles Holding Back PC Gaming?
An anonymous reader writes "Despite all the excitement over Nvidia's upcoming Fermi GPU, there is still a distinct lack of DirectX 11 games on the market. This article points out that while the PC has returned to favor as a gaming platform, consoles are still the target for most developers, and still provide the major limitations on the technological sophistication of game graphics. Inside the Xbox 360 sits an ATI Xenos GPU, a DirectX 9c-based chip that bears similarity to the Radeon X1900 series of graphics cards (cards whose age means that they aren't even officially supported in Windows 7). Therein lies the rub. With the majority of PC games now starting life as console titles, games are still targeted at five-year-old DirectX 9 hardware."
DirectX 11 in this context does not mean 'version 11 of the Microsoft API for game programming' it means 'graphics cards with geometry and compute shaders and hardware tessellation support'. Whether these are programmed using DirectX 11 or OpenGL 4 (with OpenCL) is largely irrelevant. If you use these features effectively, you need quite a different design to the older model where you just had vertex and pixel shaders. If you target the older functionality, supported by consoles, then your game will work fine on newer hardware. If you target the newer hardware then a console port will involve a significant amount of rewriting.
The Voodoo card did texturing in hardware and the GeForce did transform and lighting as well, but these were just accelerating parts of the fixed-function pipeline. You used the same programming model with and without this acceleration, it just made your code run faster. With pixel and vertex shaders, you had two separate code paths, one for the fixed-function pipeline and one with shaders. This was a bit more effort, but you were mainly using the shaders to do the same thing as the fixed-function pipeline, just with a few more special effects. With geometry and compute shaders, you can generate a lot of your data on the GPU. Writing fall-back code basically means either writing the engine twice or not using the new hardware to anything close to its full potential.
I am TheRaven on Soylent News
The simple answer is that 95% of the PC gaming market** can use DX9 while only 56% can use DX10.
* That 39% for DX9 includes 22% people with DX10 hardware using DX9 Win XP.
** Assuming Steam account holders who allow the HW survey are indicative of the relevant PC gaming market. Personally I'm inclined to assume it's not far off, at least not so far that it matters.
"1) 360 doesn't support OpenGL, it supports DirectX"
I got some news for you, pal. The GPU in the 360 is 100% capable of OpenGL. Should you choose to write a game engine that doesn't use MS's crap, you're free to do so. Sure you'll probably have to jump through some hoops to get it to work but all the functions and calls are still in the hardware.
For example, Darkest of Days uses 8MonkeyLabs own proprietary Marmoset Engine, which in turn uses OpenGL, Physx, SpeedTree and OpenAL.
I swear, just because it has MicroSoft on the package doesn't mean you're stuck with DX.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
Right, because PC game developers have to write a separate version of their engine for each combination of CPU and RAM quantity that they want to support.
Wow, that's an incredibly stupid comment. There's a big difference between differences in the amount of RAM and completely different architectures. The consoles have ridiculously little common ground amongst themselves or with the PC. Of course you rewrite big chunks of your engine for each of them. You can tell when someone hasn't rewritten their engine for the target platform because it invariably becomes yet another shitty port!
For example:
The PC has a bunch of homogeneous cores. You set up some threads. You allocate some memory. You run your algorithms, being mindful of synchronization and cache misses. The OS schedules things relatively sanely (you hope).
The XBOX 360 has six hardware threads split across three cores. Each thread has identical capabilities, including decent math performance. The paired threads can stomp each other's caches very easily if you don't have compatible tasks running on them. Cache misses are incredibly expensive. The pipeline also penalizes branches very heavily, so you'll need to do things that might be slower on PC to avoid if statements.
The PS3 has one core with not that much for math horsepower on it. You also have seven coprosessors that run a specialized instruction set and can perform ridiculous number-crunching feats, but they can only work out of their own dedicated little bit of memory. The main core's job is to DMA math-heavy tasks into them, wait for them to finish, and DMA the results back while running high level logic. Write your own synchronization code. Also, you get to restructure all of your physics (and maybe AI) data so that you can very efficiently batch it into little chunks of math-heavy work.
The Wii has ridiculously fast RAM. It's just silly fast. Cache misses are not a concern. Cramming everything into the limited amount of RAM you have, however is. This affects the core structure of almost every compute-heavy subsystem.
Graphics: just as varied. IO: varied, again. Controls: also very different...
I'm a game developer. The only good point you make is that using OpenGL makes Mac ports a bit cheaper. The rest of your rant is bullshit, and if you're actually a gamedev (which I doubt) you should know better than to make such silly claims. There's a hell of a lot more to porting to a new platform than porting the graphics subsystem (and porting between DX and GL is trivial compared to what you have to do to squeeze stuff like physics onto console architectures).
We all want to use OpenGL because it's a nicer API than Direct3D
Hah! Bullshit. OpenGL might become a nicer API if Khronos ever gets their heads out of their asses and stops pandering to the CAD crowd. Until then it's an annoying mass of gotchas. Seriously, the backwards compatibility provisions in OpenGL make every Windows release look like a clean break from the prior version.
we can develop for it on our Macs, and our games will support just about every modern gaming platform imaginable (because we aren't tied to Microsoft's platforms).
Mac I'll grant you. What are these other modern gaming platforms? Seriously, what are they? Linux? Unless you mean all the mobile devices using OpenGL ES, but you need to rewrite significant portions of your engine and redo almost all of your art to get a reasonable experience on those, and a DX -> GL ES port is trivial when you're already doing all of that.
DirectX 11 doesn't support Macs, it doesn't support the PS2 or the PS3, it doesn't support the Wii, and it doesn't support most mobile devices.
Again, I'll grant you the Mac. What the fuck are you smoking as far as the rest goes? OpenGL doesn't magically give you free (or even meaningfully cheaper) ports to any of those platforms either:
PS2: No OpenGL here. Just a DMA controller and some hardware registers. The entire create/bind/release metaphor that both GL and DX are based around does not exist. The shading unit can't even express all of the common blend modes, and you have to do ridiculous gymnastics to fit textures into the tiny amount of video RAM you get. You should know this if you've ever worked with a PS2.
PS3: You're an idiot if you're using the GL library directly on the PS3. There's a reason Sony gives direct access to the hardware - if you care about performance you won't be using the wrapper libraries. But again, you'll be rewriting a bunch of your engine to get AI, physics, and other stuff running on the SPUs anyway and a graphics port from either DX or GL is fucking trivial next to that.
XBOX and XBOX 360: DirectX-ish API, so OpenGL gets you nothing here. Even if you start with a DX game you're still porting a bunch of code if you did anything worth mention since there are still fairly significant architectural differences between it and PC. About all you get out of the similarity is a good idea of what entry points will likely be named.
GameCube/Wii: Calling what those platforms expose "OpenGL" is just silly. The structural similarities between the libraries you get and OpenGL are trivial when compared with the mountains of restrictions, special cases, and other odd differences you'll be dealing with. And again, you're going to be rewriting a bunch of your engine to the execution environment so a 5% more direct graphics port saves you fuck all once you tack on the art changes and another QA cycle.
Mobile devices: we already covered the mobile devices. Have you actually worked on one? You should know better than to imply that you get magic free porting to them if you just use OpenGL. There's a hell of a lot more to a usable mobile port than flipping some defines and recompiling with GCC.
Seriously, the starting graphics API is fucking irrelevant to any serious porting effort. GL and DX have near identical capabilities, identical object lifetime management, trivially mappable entry points and trivially mappable state bits, and near identical performance and synchronization behaviors. Porting between the two is trivial compared all the other work a proper port requires.