Jump to content
  • Advertisement
Sign in to follow this  
PixelPrime

A couple of DirectX (beginner) questions

This topic is 3684 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • 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!