Jump to content
  • Advertisement
  • entries
    422
  • comments
    1540
  • views
    490086

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

Sign in to follow this  
jollyjeffers

96 views

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!
Sign in to follow this  


3 Comments


Recommended Comments

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? :).

Share this comment


Link to comment
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

Share this comment


Link to comment
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 :))

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!