DirectX 10 & the Future of Gaming

Homogeneous Cow writes "Brent Justice at [H] Enthusiast has put together a quick look at what DX10 has to offer gamers and what the main differences are between that and our current DX9. Unified Architecture and Small Batch Problems are shown to be addressed. There are a lot of ATI slides supporting the text as well." From the article: "The obvious question for the gamer that arises is, 'Will this terribly expensive and arduous upgrade path positively impact my gaming experience enough to justify the cost?' That has yet to be seen and can only be answered with the games we have yet to play. We can however discuss some of capabilities of DirectX 10 with a unified architecture and how it can potentially benefit gamers."

Comments

Re:What about OpenGL?

[MaestroSartori]

"It seems to me that "DirectX 10 hardware" may finally be approaching a phase-3 machine."

No, at least from a coding point of view it passed that around the time of maybe DX5 to DX7. Back then it was a real chore to write stuff for, documentation wasn't entirely great and textbooks got all confused and out of date really really quickly. Round about DX8 it really started to be OK though, and that's about when I did a bit of Xbox dev work. Since then, I've been on PS2 duties so have fallen out of touch.

The thing is, DX isn't the same as OpenGL. It's pretty much a full game middleware platform, only for Windows and Xbox instead of being really multiplatform. Open Source stuff can approximate the feature set if you combine things (OpenGL + SDL + various things for audio, networking, etc.) but they're all done by different people, with different coding styles and different levels of goodness. DirectX's strength is its coherence, and the big install base of Windows users.

DX10 is throwing away a big pile of audience, I'm not sure that's a good idea...

Re:What about OpenGL?

[Spy Hunter]

Display lists are an old solution, not used much any more. Vertex buffers are what is used nowadays. DirectX never even had a call analagous to glVertex3f, it started straight out with vertex buffers. The small batch problem refers to the fact that DirectX's rendering calls are incredibly CPU intensive. Making a call to render one triangle takes the same amount of time as a call to render thousands of triangles. Making more than about 200 draw calls per frame will cause your application to become CPU-bound, even if you're only rendering 200 triangles! The graphics card can handle the polygons without breaking a sweat but DirectX burns up your CPU doing God knows what instead of passing them along. This makes it difficult to render more than about 200 (depending on CPU speed) objects, which isn't really a whole lot when you think about all of the things that go into a realistic scene.

I don't know if OpenGL suffers from the same phenomenon. My guess is that it does to some degree, but I can't imagine that it's as bad as DirectX.

The geometry shader is actually a cool concept. It fits into the pipeline *before* the vertex shader, and it has the ability to create and delete vertices and polygons, which vertex shaders cannot do. This helps free up PCI bandwidth and CPU time by generating complex geometry completely on the graphics card. Applications using stencil shadow volumes and particle systems should benefit immediately, and in the future I expect a move toward lots more procedural generation of geometry. Today's graphics cards can render so many triangles that most applications just can't send them enough to keep them occupied, so having the card generate its own triangles makes sense. For example, you could send the card a list of points on the ground and it could generate a field of unique leafy plants swaying in the wind, one for each point. If the plants are complex then the bandwidth saved by generating that vertex data on the card instead of transferring it over the PCI bus from main memory could be huge.