D3DUSAGE_WRITEONLY problem

Started by
11 comments, last by Chett2001 16 years, 11 months ago
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 = vLocal; //Debugger says this line is the problem

	vbTree->Unlock();

Anyone any idea what the problem is?
Advertisement
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.
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. :) )
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.
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?
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)
I'm a bit of a newbie, how do I go about checking the return value like that? Cheers for the help.
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.
Sirob Yes.» - status: Work-O-Rama.
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?
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.

This topic is closed to new replies.

Advertisement