🔒 Locked

FAQ Updates

Started by Muhammad Haggag Jul 30, 2004 at 8:20 PM 47 replies 10.6k views

Original Post

Jul 30, 2004 at 8:20 PM

Here's the Forum FAQ. It needs to be updated a little. If you have any suggestions, post them here. If you'd like to help out with the answers, it'd be great, and you'll be credited. For a start:

Index buffers: What they're for, and how to use them
DrawIndexedPrimitive
Present() and the time it takes

It's 4 AM, and I've not slept, so I'm sure I've missed loads of other FAQs. Again, feel free to contribute.

jmutch

Jul 30, 2004 at 8:26 PM

Very nice. Only how 'bout adding
What is a matrix?
to it.

circlesoft

Jul 30, 2004 at 9:06 PM

Here are some for now...

Q: I want to draw my JPG (or BMP, PNG, ect...) image to screen. How can I do that?
A: The simplest (and probably fastest) way would be to use ID3DXSprite. It batches everything, so it actually only makes one DrawPrimitive call per frame, which can really improve performance (espeicially if you are rendering a lot of quads). See question below.

Q: How do I use ID3DXSprite?
A:

// Load-time(1) Create the ID3DXSprite object, using the D3DXCreateSprite factory function.(2) Load your textures// Run-time(1) Call ID3DXSprite::Begin()(2) For each texture you want to render   (a) Build the translation matrix   (b) Call ID3DXSprite::Draw()(3) Call ID3DXSprite::End()

Q: I need a .X file exporter for 3DS Max. I can't find the one that is with the SDK, or it isn't working correctly.
A: Give Panda a try.

Q: I still want to use DirectDraw for my 2D applications, but it's not included with the SDK anymore, and Microsoft doesn't have any of the older SDKs available for download anymore. What should I do?
A: You can still use DirectDraw7 - it is still a part of DirectX. However, all development for it has ceased, so Microsoft has stopped including documentation for it. Since DirectX is backwards compatable, you can still compile your DDraw applications with the latest SDK. (Also, if you want older SDKs, try this site.

Q: Where have DirectShow and DirectPlay gone in the Summer Update 2004 SDK?
A: Like DirectDraw, they have been deprecated and removed from the SDK. DirectShow has new life in a multimedia kit that Microsoft is working on. DirectPlay, however, is dead (it may be reincarnated later on the XNA platform).

Q: What is the difference between buffered mode and immediate mode in DirectInput?
A: Immediate mode is a current snapshot of the device. It tells you the current state of every button and axis at that current point in time. Buffered mode, however, is a list of all events that occured (events such as keyup, keydown, axis moved, ect...).

Here is an example of retrieving buffered input:

// keyboard is the IDirectInputDevice8 objectDIDEVICEOBJECTDATA data[8];  // You can change this if you wantDWORD numElements;if( FAILED( keyboard->GetDeviceData( sizeof(DIDEVICEOBJECTDATA), data, &numElements, 0 ) ) ){   // Handle lost keyboard}for( int i = 0; i < numElements; i++ ){   if( data.dwOfs == DIK_A )   {      // Test A key            if( data.dwData & 0x80 )      {         // A has been pressed      }      else      {         // A has been released      }   }}

Here is a parallel example that gets immediate input:

// keyboard is the IDirectInputDevice8 objectchar keys[256];  // Array to hold keystates inif( FAILED( keyboard->GetDeviceState( sizeof( keys ), LPVOID(&keys) ) ){    // The keyboard has been lost, try to re-aquire here    // and perform error handling}if( keys[DIK_A] & 0x80 ){    // The 'A' key has been pressed on the keyboard    // We don't know if it's keydown or keyup}

Q: My app runs at 1000fps when I'm not rendering any vertices. But as soon as I render one polygon, it drops to 500fps! What's the problem?
A: There is no problem. Frames per second is not a good indicator of performance once you get above a certain range (I'm not quite sure what it is, whether it be 70fps, or 100fps, or 200fps). A drop of 100fps to 50fps is many times more severe than a drop from 1000fps to 500fps. As soon as you push any vertices to the card (and make an DrawPrimitive or DrawIndexedPrimitive calls), you are instantly going to loose a lot of frames per second. It doesn't really matter though, because the human eye can't even pick up the difference.

[edit] - Fixed immediate input code

[Edited by - circlesoft on July 31, 2004 10:06:45 AM]

Raloth

Jul 30, 2004 at 10:18 PM

This one needs to be added, badly.

Q: I have a texture that I am applying to a quad with the same pixel dimensions on the screen as the texture, but the image comes out blurry. What's wrong?

A: This occurs because you are not directly mapping texels to pixels. There are two general causes for this:

1) Your texture is not a power of two with the same dimensions for height and width. When Direct3D goes to generate the mipmaps, it distorts the textures. Your quad distorts them back, but the process is not exact. You can solve this by using a power of two texture while only using a portion of it and adjusting your texture coordinates accordingly.

or, more likely

2) It would seem that the correct texture coordinates for the bottom left and top right are (0,0) and (1,1), respectively. However, this is not the case. Those texture coordinates map the edge of the texture to the edge-pixels of your quad, not the edge-pixels of the texture to the edge-pixels of your quad. You need to extend the texture coordinates out by half a texel to directly map texels to pixels. For a 256x256 texture, the bottom left coordinate would be (-.5f / 256.0f,-.5f / 256.0f) and the top right coordinate would be (256.5f / 256.0f,256.5f / 256.0f).

For more information, see the MSDN.

[edit] My explanation came out less coherent than I had hoped. It might need to be cleaned up a little before being added to the FAQ.

rohitgonsalves

Jul 31, 2004 at 3:53 AM

And What About Meshes?

1] Why mesh is rendered black?
2] Mesh Scaling problem?

Night Elf

Jul 31, 2004 at 8:23 AM

Quote:

Original post by circlesoft

// keyboard is the IDirectInputDevice8 objectchar keys[256];  // Array to hold keystates inif( FAILED( keyboard->GetDeviceState( sizeof( keys ), LPVOID(&keys) ) ){    // The keyboard has been lost, try to re-aquire here    // and perform error handling    if( keys[DIK_A] & 0x80 )    {       // The 'A' key has been pressed on the keyboard       // We don't know if it's keydown or keyup    }}

I believe that should read:

// keyboard is the IDirectInputDevice8 objectchar keys[256];  // Array to hold keystates inif( FAILED( keyboard->GetDeviceState( sizeof( keys ), LPVOID(&keys) ) ){    // The keyboard has been lost, try to re-aquire here    // and perform error handling}if( keys[DIK_A] & 0x80 ){    // The 'A' key has been pressed on the keyboard    // We don't know if it's keydown or keyup}

However, I don't understand why you say "We don't know if it's keydown or keyup." With the test you perform you find out if the key is down or not. What you can't say is if it's just been pressed or if it's just been released, but you can't do that either with the other code snippet you posted. To do that, you shoud see if there's a difference between two adjacent states:

// This array should be saved from on frame to the nextchar PreviousState[256];...char CurrentState[256];if(FAILED(keyboard->GetDeviceState(sizeof(CurrentState), LPVOID(&CurrentState))){    // The keyboard has been lost, try to re-aquire here    // and perform error handling}if ((PreviousState[DIK_A] & 0x80) && !(CurrentState[DIK_A] & 0x80)){    // Key has been released}else if ((CurrentState[DIK_A] & 0x80) && !(PreviousState[DIK_A] & 0x80)){    // Key has been pressed}// Save current state in PreviousState

The same idea can be applied to buffered input.
Please, correct any mistake I may have made.

circlesoft

Jul 31, 2004 at 10:34 AM

Quote:
Original post by Night Elf
I believe that should read:
*** Source Snippet Removed ***

Doh! That's what you get for making a long post with more than 1 source snippet [smile]

Quote:
What you can't say is if it's just been pressed or if it's just been released, but you can't do that either with the other code snippet you posted.

Yes, you can - you can do it with buffered input, without any further modifications. For further clarification:

// From buffered input snippetif( data.dwOfs == DIK_A ){   // Test A key         if( data.dwData & 0x80 )   {     // The high bit of the low byte has been set     // 'A' has been pressed (keydown)   }   else   {     // The high bit of the low byte is clear     // 'A' has been released (keyup)   }}

With buffered input, it does not give you the state of every key, button, or axis - only the active ones. For buttons, if the high bit of the low byte is set, the button has been pressed. If the high bit of the low byte is clear, the button was released.

Night Elf

Jul 31, 2004 at 1:40 PM

Quote:
Original post by circlesoft
Quote:
What you can't say is if it's just been pressed or if it's just been released, but you can't do that either with the other code snippet you posted.
Yes, you can - you can do it with buffered input, without any further modifications.
[...]
With buffered input, it does not give you the state of every key, button, or axis - only the active ones.

Oh! You're right. That's what you get for not reading the DirectX Docs carefully [smile].

Pipo DeClown

Jul 31, 2004 at 5:04 PM

Q: DirectInput, how do I scan for caps/signs?
A: Check if shift (DIK_LSHIFT or DIK_RSHIFT) was pressed or capslock (DIK_CAPITAL) was turned on.

And I don't think you should put that DirectDraw/DirectShow/DirectPlay are removed, but deprecated or dead. Removed might confuse people.

I suppose someone more experienced (hint: Coder & circlesoft & superpig) than me, could write a newer shader-article (series). Especially now FX are optimized, and recommended.

Mastaba

Jul 31, 2004 at 6:45 PM

Quote:
Original post by Pipo DeClown
And I don't think you should put that DirectDraw/DirectShow/DirectPlay are removed, but deprecated or dead.

I would not even use the word deprecated at this point. When something is deprecated it usually means something else has taken its place. This isn't the case with DirectPlay currently. At no point in the 2004 documentation notes is it stated that DirectPlay is deprecated. It is only stated that it wasn't updated and that there were no plans for further updates to it. However because DirectPlay Debug DLL's were not included, they are hinting that they don't want anyone to use it for anything new.

Now, here is my contribution:

Q: Can you use MSVC++ 6.0 with the DirectX 9.0c Summer 2004 SDK?
A: Contrary to what the documentation suggests, Yes! You most certainly can use VC++ 6.0, the only issue is that the D3DX.lib you need to use with VC++ 6.0 is in the DirectX 9.0c Summer 2004 Extras package.

ggs

Jul 31, 2004 at 10:21 PM

Quote:
Original post by Mastaba
At no point in the 2004 documentation notes is it stated that DirectPlay is deprecated.

The quoted section at the start of any DirectPlay docs:

Quote:
Warning: Microsoft® DirectPlay® has been deprecated. Deprecated components of Microsoft DirectX® 9.0 for Managed Code are considered obsolete. While these components are still supported in this release of DirectX 9.0 for Managed Code, they may be removed in the future. When writing new applications, you should avoid using these deprecated components. When modifying existing applications, you are strongly encouraged to remove any dependency on these components.

Is probably a good hint that DirectPlay is deprecated.

Coleco

Jul 31, 2004 at 10:33 PM

I COULD be wrong, but I believe the section under which version of DirectX comes with each version of Windows is wrong about the NT version.

If I am not mistaken:

NT3.x has NO DirectX support (it's command line only)
NT4.x by default install has NO DirectX. (Hell, only has IE 2.0)
NT4.x with SP/6 (not 4) gives you the max of DX 3.0a.

-cbmeeks

Mastaba

Jul 31, 2004 at 10:53 PM

Quote:
Original post by ggs
The quoted section at the start of any DirectPlay docs:
Quote:
Warning: Microsoft® DirectPlay® has been deprecated. Deprecated components of Microsoft DirectX® 9.0 for Managed Code are considered obsolete. While these components are still supported in this release of DirectX 9.0 for Managed Code, they may be removed in the future. When writing new applications, you should avoid using these deprecated components. When modifying existing applications, you are strongly encouraged to remove any dependency on these components.

Is probably a good hint that DirectPlay is deprecated.

Hmm, interesting. That only appears to be in the managed DirectX documentation. The unmanaged DirectX documentation does not say anything of the sort, nor do the directx documentation readme's. The unmanaged documentation simply suggests to use Window's core networking technology, but does not call DirectPlay deprecated at all. In fact, it sort of suggests that they are still working on some DirectPlay security issues.

Quote:
From the "What's New in DirectX 9.0 SDK Update (Summer 2004)" topic in the unmanaged DirectX documentation
Microsoft DirectPlay is intended to address identified security issues through December 31, 2004. Game developers should use enhanced core Microsoft Windows networking technologies as they become available.

Actually the wording in that quote, sort of doesn't make sense to me. Like either a word is missing from the statement, or some words are in the wrong order.

circlesoft

Jul 31, 2004 at 11:29 PM

Quote:
Original post by Pipo DeClown
I suppose someone more experienced (hint: Coder & circlesoft & superpig) than me, could write a newer shader-article (series). Especially now FX are optimized, and recommended.

I would be up for making some HLSL contributions, because we get a lot of questions like "where can I find HLSL tutorials". Most of the time, I end up referring them to books (like the ShaderX2 series), because there isn't that much HLSL reference out there on the web.

Etnu

Aug 1, 2004 at 1:55 AM

Quote:

Game developers should use enhanced core Microsoft Windows networking technologies as they become available.

Seems pretty straightforward to me: "What the hell is wrong with you? Use Winsock!"

S1CA

Aug 1, 2004 at 7:05 AM

Quote:
Original post by Etnu
Quote:

Game developers should use enhanced core Microsoft Windows networking technologies as they become available.

Seems pretty straightforward to me: "What the hell is wrong with you? Use Winsock!"

I'd only partly agree with that. [smile]

There are still some things that DirectPlay makes easier such as lobbying and even stuff like NAT traversal when compared to plain winsock.

If you take a look at the XNA site (http://www.microsoft.com/xna), there's a hint at what's going to happen and what the "as they become available" part means:

Quote:
In response to strong customer demand, Xbox Live™ development tools for functionality such as billing, security, login, friends and matchmaking will be made available to Windows developers. The tools will make it easier to create the same social, unified online gaming experiences on Windows that game players have come to expect on Xbox.

As well as plain sockets, Xbox has additional libraries for handling connections, QoS, matchmaking/lobbying, team handling etc

Many of those things are also covered by DirectPlay, but using a different API - so it makes sense to unify the API (thus XNA).

For a Windows PC only game which didn't require any *nix back-end stuff, currently, I'd be inclined to still use DirectPlay (as many other games do - I posted a list of a fair few well-known ones last time this came up). When the new Windows networking technologies did become available, I would of course switch to those.

The only hard call would be if I had a title in development now which was due to ship far enough after the release of the new stuff for Windows that it would make a difference to players of the game.

__Daedalus__

Aug 1, 2004 at 1:56 PM

Quote:
Original post by S1CA
If you take a look at the XNA site (http://www.microsoft.com/xna), there's a hint at what's going to happen and what the "as they become available" part means:

Quote:
In response to strong customer demand, Xbox Live™ development tools for functionality such as billing, security, login, friends and matchmaking will be made available to Windows developers. The tools will make it easier to create the same social, unified online gaming experiences on Windows that game players have come to expect on Xbox.

Wow, that sound like a very exciting development library! Thanks for pointing that out.

Pipo DeClown

Aug 1, 2004 at 4:05 PM

By the way, Richard (superpig) left a few e-mail links in the FAQ, might want to update/remove them.

And when I posted my humble suggestion about Dustin becoming DXmod, I thought Richard still was. Anyway, Coder/circlesoft/S1CA, doesn't mather! All goo..- grea..- ownage!!!

^^^^^^^
|||||||_____ wrong thread, but I'll leave it here! ^_^

circlesoft

Aug 2, 2004 at 10:48 PM

Ah, I just remembered one:

Q: I want my camera to move in the direction that it is pointing
A: You need to use quaternions.

D3DXMATRIX BuildCameraMatrix(){   // cameraVelocity is a D3DXVECTOR3, holding the velocity of the camera for each coord   // cameraPosition is a D3DXVECTOR3, holding the current position of the camera   // cameraRotationYaw is a float, holding the rotation amount for the yaw axis (Y-axis)   static D3DXMATRIX matOrientation;   // Normalize and combine   D3DXVec3TransformNormal( &cameraVelocity, &cameraVelocity, &matOrientation );   D3DXVECTOR3 cameraPosition += cameraVelocity;   /* Build the new transform matrix for the camera */   D3DXQUATERNION quat;   D3DXMATRIX matView;   // Genenerate a quaternion, using only the yaw from the player   D3DXQuaternionRotationYawPitchRoll( &quat, cameraRotationYaw, 0.0f, 0.0f );   // Now build the matrix   D3DXMatrixAffineTransformation( &matOrientation, 1.25f, NULL, &quat, &cameraPosition );   // We must take the inverse to get the appropriate transformation   D3DXMatrixInverse( &matView, NULL, &matOrientation );   return matView;}

Muhammad Haggag

Aug 3, 2004 at 3:57 PM

Quote:
Original post by circlesoft
Ah, I just remembered one:

Q: I want my camera to move in the direction that it is pointing
A: You need to use quaternions.
*** Source Snippet Removed ***

You don't need that. You can just grab the _31, _32, and _33 members of your camera matrix. These represent the camera's unit forward vector (if the matrix is orthonormal). Scale that with the distance, displace the camera with it, and you're done.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.