About the MSDN tutorials:

Not meaning to be unhelpful, but all of those questions are answered in the DirectX SDK documentation.

On the msdn site or in help files? Because the I could never help files for MSVC++ to install. It always gave up half way through the second or third disk. Some of the descriptions were a bit vague on the msdn site and I would have prefered a description of what effect I would notice when looking at the produced graphics. The ones I might have looked up more easilly, I probably should have but might have had a reply sooner.

EDIT: I also wrote them all down because I have to spend an hour travelling to get to uise the internet at the moment.

EDIT 2: Well the swap effects I get now, but it only explains what the default adapter is, but not what happens if you use other values. It looks like it's the graphics card but it doesn't really explain how I'd know what values I could use if there were adapters other than the default.

It describes D3DCREATE_SOFTWARE_VERTEXPROCESSING as "Specifies software vertex processing" but doesn't really say what can happen when that or hardware vertex processing is used.

[Edited by - CodeReaver on October 31, 2005 11:55:04 AM]

Quote:

Original post by CodeReaver D3DADAPTER_DEFAULT = 0, so would 1, 2, 3, be 2nd, 3rd and fourth graphics cards? Also is it definatly the graphics card?

Yes, these are for when you have more than one graphics card. You can retrieve the number of these by calling IDirect3D9::GetAdapterCount.

Quote:

D3DDEVTYPE_HAL = hardware, D3DDEVTYPE_SW = software, D3DDEVTYPE_REF, D3DDEVTYPE_NULLREF. What does the device type effect and what are the other two.

1) A HAL device is one that does rasterization in hardware, and may do transform and lighting (TnL) in software or hardware.

2) A SW device is one that is developed by a third party and plugged into Direct3D. This is sparsely documented (if at all), and is not that important. Forget it.

3) A REF device is explained well in the FAQ. Here.

4) A NULLREF device is one that does no rasterization at all. You can read about it in the documentation of D3DDEVTYPE if you want, but I advise you to forget about it for now. It's not important.

Quote:

What does using hardware or software vertex processing in the BehaviourFlags parameter effect?

Hardware vertex processing means all the transformation and lighting is performed on the GPU instead of the CPU. This frees the CPU to work on other stuff in parallel, like physics or AI, consequently improving performance. Legacy (read: Prehistoric) devices do not support hardware vertex processing. Perhaps some integrated chips too, not sure about this. Additionally, devices that support hardware vertex processing do not necessarily support all Direct3D features, e.g. vertex shaders.

Software vertex processing means all the transformation and lighting is performed on the CPU. This is used when:
- The device does not support hardware vertex processing.
- The device does not support the feature you want in hardware (e.g. vertex shaders)

Quote:

Is the LPDIRECT3DDEVICE9 ppReturnedDeviceInterface the same as the returned HRESULT in CreateDevice?

An HRESULT is a 32 bit integer that encodes success/failure as well as extended error information. DirectX functions typically return an HRESULT indicating the result of the operation (success/failure). This has nothing to do with what the function itself does. In the example you've given, ppReturnedDeviceInterface is 'returned' in the sense that it was created inside the function for you.

Quote:

What effect to D3DCLEAR_TARGET, D3DCLEAR_ZBUFFER and D3DCLEAR_STENCIL have? (In depth)

TARGET clears the surface you're rendering to, be it the backbuffer or a render-target. ZBUFFER clears the depth buffer. STENCIL clears the stencil buffer. If you don't know what a depth/stencil buffer is, search the docs for it, or check one of the tutorial websites listed in the Forum FAQ.

Quote:

In the clear function, what does "Clear the depth buffer to this new z value which ranges from 0 to 1" mean?

There is a buffer called the depth/Z buffer. When you pass the D3DCLEAR_ZBUFFER flag and specify a Z value, that buffer is cleared (filled) with the value you provide. The depth/Z buffer stores values in the range [0, 1].

Quote:

What's a stencil buffer? Need example with the "clear" function.

Don't be so hasty [smile]. Ignore stencil buffers for now, until you're familiar with the basics.

Quote:

What is the vertex buffer usage type?

Vertex buffer usages provide hints for the runtime and driver about the way you'll be using the buffer, so that it's stored in the optimum place for your usage. For example, D3DUSAGE_WRITEONLY indicates that you'll never read from the buffer, giving the driver an optimization opportunity.

The most common use for USAGE is to determine whether a vertex buffer is static or dynamic. I'd leave this for now until I'm familiar with the basics, if I were you.

Quote:

What does "the memory allocation for a buffer" mean? (As in D3DPOOL_DEFAULT)

There are gobs of documentation in the D3DPOOL documentation page. Check it out, and ask about what you don't understand [smile].

Quote:

What does rhw do?

RHW is the reciprocal of homogenous W. When using transformed and lit vertices (i.e. Direct3D just draws them directly to the screen without trasnforming or lighting them, assuming you did) this value is needed by Direct3D. Suffice it to say that you should set it to 1.0 for now.

Thanks for that. I managed to find answers to a few of my questions by searching msdn, but it seems much easier to understand this way.

"A HAL device is one that does rasterization in hardware."

So does that mean the hardware does the converting from the vertices I'd give to DrawPrimitive into pixels on the screen or something? I'll have to look that up.

From what you described about the vertex processing, I take it that means that has nothing to do with what I mentioned above, but it does speed up processing and I should use it whenever it's available.

The thing about ppReturnedDeviceInterface makes sense now. I was just asking because msdn had it down as a returned value or something, but at least I tried looking it up before asking.

I'm trying to understand what the depth buffer is and the best I can think of is that it might be like in cartoons they have a picture on some clear plastic and they put one on top of the other. Starting from one of the 2D (in direct3d) examples I drew two overlapped triangles in different colours. Then when I could change which one got drawn on top by changing the z values. I was kind of expecting the one underneath to appear smaller as though it was further away. It worked out more like the cartoons example, so perhaps the z buffer would be a way of deleting one of the triangles without the other.

"Vertex buffer usages provide hints for the runtime and driver about the way you'll be using the buffer, so that it's stored in the optimum place for your usage. For example, D3DUSAGE_WRITEONLY indicates that you'll never read from the buffer, giving the driver an optimization opportunity." This it a bit confusing because I would hve though you would need to read from the vertex buffer in order to draw the shape it makes.

I thing I found out about when I need to use RHW but I still couldn't tell what it effects when you change the value. I'll leave that one for now.


I think a lot of the things I'm not understanding right away are because I don't know what a lot of the expressions in the documentation mean. I think I should look up some of those next. I mean all I know about a device is that I need to create one before I can draw anything.

Quote:

Original post by CodeReaver "Vertex buffer usages provide hints for the runtime and driver about the way you'll be using the buffer, so that it's stored in the optimum place for your usage. For example, D3DUSAGE_WRITEONLY indicates that you'll never read from the buffer, giving the driver an optimization opportunity." This it a bit confusing because I would hve though you would need to read from the vertex buffer in order to draw the shape it makes.

D3DUSAGE_WRITEONLY means that YOU don't need to read from it. Only write to it. Let the hardware read the data when you tell it to draw.

Ah, ok. I was thinking passing it as an arguement was the same thing. I get that bit now.

Don't try to overthink the depth buffer. In short, it is just a buffer, so it stores values (past values in our case) and it's used to either pass or fail new pixels that need to be drawn.

In simple terms: For each pixel in your final rendered image, a value is stored in the depth buffer. As it sounds, the value is the last depth that passed a test. The test can be greater than, less than, equal, etc. The test is performed when a primitive is drawn and it resides over that pixel (so it could be hundreds or thousands of tests per primitive, depending on size and how many pixels the primitive covers). The depth of the primitive at that location (the pixel location) is then checked against the previously stored value in the depth buffer. The test determines whether it returns true or not. If it returns true, the old pixel value is discarded and the new pixel is drawn in that spot. Returning true, it also stores the new depth in the depth buffer.

If you draw one flat triangle at z=10, then you draw another one at z=11, and your depth test is "current less than buffer", then the test will fail during the second primitive draw (remember it only fails at this pixel location. It may pass at other pixel locations if the primitive is rotated and part of it is in front, part behind, the first primitive) and the second triangle drawn will not affect the pixel at that location. This is pretty typical for drawing normal perspective-based scenes. You want things behind to not show through the things in front.

If you turn alpha blending on, depth tests are ignored. The order in which you draw the primitives will determine the final color. You generally want to sort from back to front when using alpha blending.