D3D #8: I tried my application on a different comp

Published May 19, 2006
Advertisement
Another entry for the FAQ. Slowly working my way through them as/when I've got time (really should be revising for exams [rolleyes]).

As usual - comments are appreciated!

btw, anyone got any suggestions for an avatar? I lost mine in my recent identity crisis [sad]D3D #8: I tried my application on a different computer and it didn't work or looks different.

Once your software project is complete it is conventional to distribute it - either freely online as a demo, or possibly as part of a commercial paid-for package. In either case it is of obvious importance that it works correctly on the end-user's computer; if it doesn't they're most likely to come asking/blaming your first!

However, in the PC market there are millions (if not billions) of possible hardware and software configurations. If you're lucky you might own several computers with different configurations, or better yet you have access to a suite of test machines. Regardless of this, you're very unlikely to get close to covering all of the combinations available in the "real-world".

Unsurprisingly, Direct3D 9 is defined from a set of specifications (for both hardware and software) - however this specification is not entirely water-tight. Specifically it leaves some points as being "undefined" or in some cases "suggests" and "recommends" rather than "requires". This becomes a problem when multiple IHV's (Independent Hardware Vendors - e.g. Intel, Nvidia and ATI) have to create their hardware and drivers to support the API. Each company is perfectly entitled to interpret the "undefined" parts in different ways.

The best strategy is to not rely on any undefined behaviours, and also to be very wary of cases where you might be using optional capabilities. Refer to the previous D3D #5 "Hardware capabilities and enumeration". Despite this, it is possible to accidentally rely on a default/undefined feature or result.

In these cases it pays to use the "Reference Rasterizer" (sometimes referred to as "RefRast") - a special software device included only in the DirectX SDK. As the name suggests, it is for reference purposes - it implements all the features of Direct3D 9 in software in a way that conforms to the specification. Whilst the reference rasterizer must still choose what to do in the "undefined" cases, in all other situations it should be correct according to the specifications.

To use the reference rasterizer you will need the DirectX SDK installed - this is important to note as it will mean that it is unlikely to work on your end-user's machine. The switch is simple - in your IDirect3D9::CreateDevice( ) call you would typically use D3DDEVTYPE_HAL as the DeviceType parameter - simply swap this for D3DDEVTYPE_REF.

You will quickly realise that the reference rasterizer is very, very slow - getting above 3-4fps on a powerful PC is rare. This is quite intentional due to it being written for accuracy/correctness rather than performance. It is worth building a debugging aid into your software to allow you to jump to different parts, or to play back previously recorded input. This way you can either quickly focus in on the section that you need the reference rasterizer for, or you can leave it to automatically collect data for you!

In most cases the reference rasterizer will pick a side - closely (or exactly) matching the results from one of your real-world test samples. This is particularly useful as it helps you isolate where the problem might lie. The next steps are not easy to define - it is largely a case of experience and trial-and-error. Trying to determine the differences between the two pieces of hardware is often a good start - many differences come down to your software incorrectly assuming that hardware is capable of something it is not. As previously mentioned, see D3D #5 "Hardware capabilities and enumeration" for more details.

If you get to a situation where one particular hardware manufacturer differs from others it can be very useful to contact the manufacturer directly. Most companies offer a "developer program" and have specific "developer relations" departments. The two of the most common graphics IHV's have developer sites found at: developer.nvidia.com and ati.com/developer/.

As a forward looking note, the Direct3D 10 specification is much more strictly defined than in previous versions. This should hopefully reduce if not eliminate the aforementioned problems!
0 likes 3 comments

Comments

sirob
I think a section about the D3DX DLLs would be very appropriate here. This is a pretty common issue, and I'm sure people would appreciate the legal issues involved, and the correct way to distribute it. I bet most people just stick it in their app directory when they distribute [wow].
If theres a different section on that, maybe you should at least add a link to it in this one as well.

As for the avatar, maybe Google can help? :).
May 20, 2006 07:59 AM
jollyjeffers
Yup, I plan on covering the distribution/D3DX DLL's in another section.

However, my current draft plan puts them under "DirectSetup" rather than "Direct3D"... hmm... might well merge/move those around a bit.

So which of the following do I pick:





??

Jack
May 20, 2006 12:59 PM
sirob
cropped any ready for next Christmas:
Image Hosted by ImageShack.us

hehe :).

(this is of course a lousy pick, don't really use it :P, though I don't think you were planning to :))
May 21, 2006 01:57 AM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement
Advertisement