Some platforms are more equal than others

re: Some platforms are more equal than others

Shawn Hargreaves - MSFT — Wed, 03 Mar 2010 18:44:33 GMT

> Instead of checking cap-bits, why not *request* certain capabilities.

That makes the opt-in more explicit, but it doesn't really fix the underlying problem if there are so many optional features that it isn't clear how to navigate your algorithms through the resulting maze. What do you do when you request 50 optional features, but only 20 of them come back as supported? How do you test all the crazy number of possible permutations that can result?

re: Some platforms are more equal than others

Adam — Wed, 03 Mar 2010 10:39:18 GMT

That lack of the border caps bit being set on old ATI cards is not because the cards can't do border addressing at all.

I'm not sure if XNA will let you do this, but with D3D9 on ATI cards that don't have the cap bit set, if you ignore that and set the render state anyway it will usually work correctly.

That doesn't work with the debug runtimes enabled, because they stop the call getting through to the driver.

According to the discussion linked below the cap bit is disabled because there are some edge cases where border doesn't work according to spec, so the driver would fail WHQL testing if the cap bit was set.

http://discussms.hosting.lsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0406E&L=DIRECTXDEV&D=0&1=DIRECTXDEV&9=A&J=on&d=No+Match%3BMatch%3BMatches&z=4&P=454

re: Some platforms are more equal than others

AR — Wed, 03 Mar 2010 05:08:35 GMT

When you enumerated that list of possibilities, it gave me another possible idea:

Instead of checking cap-bits, why not *request* certain capabilities.

This removes the possibility that you use a function without checking for capability (and end up with an exception or a mess when you port it). It also means the runtime could report what you're using ("XNA: this won't run on Zune").

re: Some platforms are more equal than others

JoelBennett — Tue, 02 Mar 2010 20:49:15 GMT

Shawn: That's one thing that amazed me about the Halo port for PC - it'd run on some amazingly low hardware (like Intel integrated graphics). I was impressed that they even went that low with things. It ran like a dog, but it did run.

Oh, the amazing things you find out when bored in a college class and the person before you had installed Halo on the machine...

re: Some platforms are more equal than others

Shawn Hargreaves - MSFT — Tue, 02 Mar 2010 16:36:16 GMT

> And here I was rooting for cap bits for being the least surprising.

Caps bits suffer from what Raymond Chen likes to call the "what if everybody did that" problem.

For any single feature, sure, attaching a boolean to it is simple and not too confusing.

But what happens when you have 100 different features, all with their associated boolean?

That gives more possible feature permutations than a 32 bit integer can evaluate without overflowing :-)

I think the resulting minefield is a poor developer experience. When you can't do anything without checking caps first, that makes it hard to write clear, maintainable code! And it's even harder to properly test code that contains so many conditional branches and optional execution paths.

In practice, I've never seen anyone properly check all of the possible DX9 caps. Most developers choose one of these simplification strategies:

- Some people just code for whatever happens to work on their development PC, and are surprised when the resulting game doesn't run on other hardware.

- Some people code for the lowest common denominator hardware, carefully avoiding any optional features. Trouble is, pretty much everything in DX9 is technically optional!

- Some people pick just two or three "feature levels" that their game will adjust to: the fancy version with all the special effects, the more limited version where they disable some of the fancier stuff, plus maybe a super stripped down version where they just render basic textured objects with no effects at all. They check caps at startup to decide which of these codepaths best fits the current hardware, then just use the selected rendering logic. This way they have just a handful of codepaths to maintain and test, as opposed to billions of possible overlapping permutations.

re: Some platforms are more equal than others

Morten — Tue, 02 Mar 2010 07:51:42 GMT

Are you seriously implying that anyone cares about avatars on Xbox? :)

re: Some platforms are more equal than others

Clayton Hughes — Tue, 02 Mar 2010 07:27:02 GMT

And here I was rooting for cap bits for being the least surprising.

While they certainly require more work on the client programmer's end--they ought to query anything they want to do, and come up with an alternative (or let the user know why they're failing--e.g. they're on 1995 hardware) if it's not supported. You could even throw an exception if they call something unsupported.

At some point, you'll have to rely on the programmer to do a little bit of thinking on their own.

Cap bits don't really become a surprise if it's the standard procedure for most of the API.

I can see where they would fail, though: In the worst case, cap bits could be essentially useless--if they're going to have to roll their own Audio system because they're doing cross-3-platform audio, then it might be easier to just ditch XACT entirely and use the same custom code on all three devices.

On the other hand, cap bits make the most sense in an environment like the GPU department where you can ask things like "do you support x in hardware?" and if so taking that path, otherwise doing it in code.

re: Some platforms are more equal than others

Iarus — Tue, 02 Mar 2010 00:38:26 GMT

One thing to note is that "Game for Windows" and "Game for Windows LIVE" are not just a brand name that takes lots of place on the cover of your game's box.

They are APIs, a good run of QA testing and more importantly TCRs (A TCR (Technical Certification Requirement) is a test case that must pass before software can be certified as compliant to a given standard).

In XNA they are only good practices, with the GRWL stamp you MUST implement some things in a specific way if you ever want your game being released.

re: Some platforms are more equal than others

Matthew — Mon, 01 Mar 2010 23:33:02 GMT

How does your verdict fit with an example like TextureAddressMode.Border?

re: Some platforms are more equal than others

JoelBennett — Mon, 01 Mar 2010 23:24:54 GMT

Erzengel: I'm guessing probably a fair bit of politics behind something like that. Just think about this: if the whole Live platform was free to develop for and run on, what would prevent developers from making games and sucking the Live bandwidth dry, while Microsoft foots the bill for everything? At least with Xbox Live, Gold members pay a fee to use the service, which I imagine is used to maintain all the servers that everything is running on. That, and what would prevent people from reverse engineering the Live components, especially if they have access to the API, more information, and the distributable DLLs? I'm guessing cheating would definitely become a bigger issue for Live enabled PC games.

That's just a guess, but that could be part of it.