A couple of DirectX (beginner) questions

Started by
3 comments, last by PixelPrime 15 years, 9 months ago
Due to the wonderful assistance of this community, I've finally been able to get a complete grip of the C++ language, and have recently started to work my way into DirectX. I've been progressing through the SDK tutorials - and so far I'm getting along really well. I have a couple of related questions, however, so as to better understand the way DirectX behaves. I've noticed that when declaring most DirectX objects, the memory that the object occupies is zeroed-out using the typical method as follows: ZeroMemory(&objRef, sizeof(objRef)); I understand what the function is doing (takes the memory address of objRef as a starting point, and sets the appropriate number of bytes (sizeof) from that point onwards to a zero value. My question is, why does this procedure need to take place? When this object is referenced for other purposes, i.e. for matrix rotations etc. Does not having the *entire* address region cleared prior to being used cause weird things to happen, or unexpected behaviour? Or will the object just not work at all? I'm guessing that since some data structures in DX don't always use the entirety of their memory-space, that the redundant portions need to be set to zero - just so as not to confuse anything. And a final question. When creating materials, lights etc. Do you really need to create them every single render pass? The tutorial I'm working through has me setting up material definitions and light objects routinely via each render pass. This seems a little inefficient? Surely it would make more sense to declare these objects independantly of the render process, and adjust them via reference during the rendering phase as required? Or do the methods to manipulate these objects explicitly require that they be defined and used during the render pass? I.e. Do you need to call both a new instance of D3DXLIGHT9 and g_pd3dDevice->EnabledLight(0, TRUE) during the render pass? Or can you set them up before to free up the render processing? I appreciate any help anyone can give, and I apologise for making my questions so verbose! Thanks.
Advertisement
Quote:Original post by PixelPrime
I've noticed that when declaring most DirectX objects, the memory that the object occupies is zeroed-out using the typical method as follows:

ZeroMemory(&objRef, sizeof(objRef));

I understand what the function is doing (takes the memory address of objRef as a starting point, and sets the appropriate number of bytes (sizeof) from that point onwards to a zero value.

My question is, why does this procedure need to take place?

Laziness. It doesn't happen for objects (that's a very bad idea in fact), but rather for structures that are passed to functions. Often, the default value of a lot of members is zero, so instead of setting them one by one, just zero the whole structure and override just what you need.
I don't like it on the basis that you can't always assume 0 is the default, so I set every member seperately.

Quote:Original post by PixelPrime
And a final question. When creating materials, lights etc. Do you really need to create them every single render pass? The tutorial I'm working through has me setting up material definitions and light objects routinely via each render pass. This seems a little inefficient? Surely it would make more sense to declare these objects independantly of the render process, and adjust them via reference during the rendering phase as required? Or do the methods to manipulate these objects explicitly require that they be defined and used during the render pass?

I.e. Do you need to call both a new instance of D3DXLIGHT9 and g_pd3dDevice->EnabledLight(0, TRUE) during the render pass? Or can you set them up before to free up the render processing?

DirectX is a state machine and if a certain state doesn't change during rendering, you can set it up once it advance and never touch it in the render loop. That's basically it.

To illustrate, enabling and setting lights can be done outside the loop, assuming the lights are constant during the rendering of a frame.
However, often you'll be rendering objects with different materials, so you'll change the material more than once during rendering (set material A, render object A, set material B, render object B). So then you obviously need to call SetMaterial every time in the render loop.

Also note that you don't 'create' materials and lights. All you do it call SetMaterial() with a pointer to a D3DMATERIAL9 structure. Ditto for lights. And that's it as far as DirectX is concerned.

Also, when you reset the device (you lost the full-screen window, or you resize the window), you need to reset the once-only render states.
Million-to-one chances occur nine times out of ten!
Quote:Also, when you reset the device (you lost the full-screen window, or you resize the window), you need to reset the once-only render states.


Presumably, I can catch this event by watching for the WM_PAINT message (which I believe is sent when the user resizes (or re-positions?) the application window?

I'll probably have to check this.

Many thanks for your helpful reply!
Quote:Original post by PixelPrime
Presumably, I can catch this event by watching for the WM_PAINT message (which I believe is sent when the user resizes (or re-positions?) the application window?

Yes, but also when it just needs to refresh. WM_PAINT doesn't always mean you've resized, so you'll be doing unncessary work.

It's easy to just make a function that sets up the initial render states and call that after you've created the device and after you've called Reset() on the device on a resize (WM_SIZE), which you need to do anyway (unless you want to stretch your backbuffer across the render window in windowed mode).
Million-to-one chances occur nine times out of ten!
Perfect, that makes sense.. thanks!

I'm still learning about the different types of messages that the app window can recive - WM_SIZE is another new one for me (but in theory makes sense in any case).

I appreciate you taking the time to answer my questions, thank you very much.

This topic is closed to new replies.

Advertisement