Sign in to follow this  

D3DUSAGE_WRITEONLY problem

This topic is 3870 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

I'm trying to create a dynamic vertex buffer that is write only (for the performance boost). I keep a local copy of all the data in the buffer so that I never hace to read directly from the buffer itself. I only ever modify the data in this local copy and then later I write the contents of the local copy into the vertex buffer. However, this causes an error. This seems odd to me as I'm writing to the buffer, not reading from it. Here's how I create my buffer:
Device->CreateVertexBuffer((iNumPointsPerSeg * (iNumTotalSegments + iNumTotalBranches))  * sizeof(d3d::VertexPos), D3DUSAGE_DYNAMIC | D3DUSAGE_WRITEONLY, 0, D3DPOOL_DEFAULT, &vbTree, 0); 
and here's the part where I update the buffer with the local copy (I'm only writing to the buffer, not reading from it):
	vbTree->Lock(0, 0, (void**)&v, 0);

	for(int i = 0; i < vLocal.size(); i++)
		v[i] = vLocal[i]; //Debugger says this line is the problem

	vbTree->Unlock();

Anyone any idea what the problem is?

Share this post


Link to post
Share on other sites
Try the lock flag D3DLOCK_DISCARD. Dynamic buffers need be locked with either DISCARD or NOOVERWRITE. The debug runtimes will likely (like 99% probability) tell what what failed and why. Turn them on, set the "debug level" slider to about half way, and look at the output window in visual studio next time you run your app.

Share this post


Link to post
Share on other sites
I'd suggest that you run Direct3D in debug mode (use the DirectX Control Panel utility in the SDK), with break on errors. It's also a good idea to test return codes. I suspect that the lock failed (and the debug runtime might tell you why), and therefore your pointer is not valid.

(Oops, noticed that Namethatnobodyelsetook said much the same. Still worth repeating. :) )

Share this post


Link to post
Share on other sites
Quote:
Original post by Namethatnobodyelsetook
The debug runtimes will likely (like 99% probability) tell what what failed and why.
Make that 100% [smile]
If the debugger halts there, then the vertex pointer is invalid, which means the lock failed. And the debug runtimes always report errors.

Share this post


Link to post
Share on other sites
I enabled Direct3D debugging and the problem disappeared. I switched back to retail and the problem came back. This is quite mysterious as the problem disappears in D3Ddebug mode so I can't diagnose it. What would cause it to do that?

Share this post


Link to post
Share on other sites
Quote:
Original post by Citizen Erased
I enabled Direct3D debugging and the problem disappeared. I switched back to retail and the problem came back. This is quite mysterious as the problem disappears in D3Ddebug mode so I can't diagnose it. What would cause it to do that?
You need to check the return value of Lock(). If it's failing, all bets are off as to what happens in the following code. As it is, the debug runtimes probably don't set the pointer to NULL or something when the function fails, meaning you're writing to random memory instead of an invalid address.

What does Lock() return? (As a 8-digit hex number)

Share this post


Link to post
Share on other sites
Quote:
Original post by Citizen Erased
I'm a bit of a newbie, how do I go about checking the return value like that? Cheers for the help.


HRESULT hr = myThingy->Lock(...);

then set a breakpoint on the following line, and run. When it reaches the breakpoint, put your mouse over hr or look in the Locals tool in VS.

Share this post


Link to post
Share on other sites
Ok, I did
 HRESULT hr = vbTree->Lock(0, 0, (void**)&v, 0); 
and hr = 0. I made sure the breakpoint was on the line after. Even tried the line after that and it's still 0. What does this mean? What's going on here?

Share this post


Link to post
Share on other sites
HRESULT of 0 means everything is okay. The lock succeeded.

Are you sure the buffer was created large enough to hold the data you're putting in it? Check vLocal's size, and compare that to how many vertices you're allocating. Ensure vLocal is of type d3d::VertexPos, or update the creation to use the same vertex structure.

How did you declare v? Since you're casting, it's possible it's not the right type and causing problems.

Share this post


Link to post
Share on other sites
Quote:
Original post by Citizen Erased
Ok, I did
 HRESULT hr = vbTree->Lock(0, 0, (void**)&v, 0); 
and hr = 0. I made sure the breakpoint was on the line after. Even tried the line after that and it's still 0. What does this mean? What's going on here?

If you use the DirectX Error Lookup tool that comes with the SDK and look up a value of 0, you'll see that 0 translates to S_OK, which means the call succeeded.

I notice you never actually specified which error it is you're getting. What kind of error, and when does it happen?

Share this post


Link to post
Share on other sites
Another question: what's the value of 'i' where the program fails? If it's high, it might be that your buffer is too small, and you're writing outside it. If it's 0, then you have a problem with 'v' itself.

Share this post


Link to post
Share on other sites
I know its basic but make sure your vertex buffer is big enough as others have said, maybe try making it a lot larger than needed just to see if thats the problem at least that way you can eliminate it if not.

Share this post


Link to post
Share on other sites

This topic is 3870 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.

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

Sign in to follow this