D3D9 Vertex Buffer Lock doesn't fail but doesn't return a pointer either

Started by
7 comments, last by Thrawn80 14 years ago
Dear all, I've been experiencing this weird problem with a particular vertex buffer during locking operations. It seems that all the rest are working except for the 2 primitive types: 1) D3DPT_LINELIST 2) D3DPT_POINTLIST Let's just deal with D3DPT_LINELIST first. There isn't an index buffer - only a vertex buffer exists. I wonder if that's illegal or not. Next, D3D9 doesn't return any errors in the HRESULT value. Instead, the buffer pointer remains 0x0000000 after the call. In any case, I've tried to use D3D debug and so on. The strangest thing is - D3D debug library managed to render my lines afterall, however the release library failed. I wonder if anyone ever had this problem before.... Thanks, thrawn80
You'll never see heaven if you haven't been through hell.
Advertisement
Rendering without an index buffer is fine, as long as you use the correct drawing call (the one without 'indexed' in its name).

If Direct3D manages to render the lines, then the lock must have worked. Perhaps you tried to debug in release mode by mistake, and didn't see the correct values for your variables?

You can try PIX as another tool. That can should you what data buffers contain. Do a single frame capture, click the 'render' tab, and then you'll have access to the device and buffers.
Hi ET3D,

Thanks for your recommendation! I've managed to find PIX under my DirectX program files area and will try it out...

I'll update everyone on the results...

Strange enough - it really only happens on the Retail library.

Regards,
thrawn80

You'll never see heaven if you haven't been through hell.
Can we see your code? If it only works with the retail libs, that means that there's a good chance your code will crash on other hardware - if it doesn't work with the debug runtimes, you can assume that it's not working at all and needs fixed.

And do the Debug Runtimes give you any information?
Hi Steve,

Er... just a few corrections

1) The lines appeared on the DEBUG D3D library but not on the RETAIL D3D library. I selected using the DirectX icon in the control panel. (just to be clear)

2) I'll try to see if I can release the codes out since it has some weird NDAs around it. Here's a few points about the code though:
a) It uses shaders which I don't think it affects the lock process
b) The vertex cache manager builds an unique ID for every vertex buffer to ensure that batching is done with as little state changes and texture switching as possible
c) The vertex buffer appears to be instantiated properly and reflects the right values when I stepped through other than the lock returning a null pointer problem that I've mentioned at the beginning of my post.

I'm trying to use PIX to see if I can find out anything. Basically, from PIX, the vertex buffer seems to be empty. The only possible condition for it to be empty after a successful lock is:
1) There are no vertices added into the buffer
2) There was a lock called, but returned S_OK and did not return the address of the buffer. This works across for every other primitive types except points and line lists. (not strips)

I'm just perturbed by the fact that DX did not voice out any warnings or errors when it returned a null pointer to my void*.

Is there something else here that I'm missing?

Please advise.

Thanks!
You'll never see heaven if you haven't been through hell.
I just need to clarify a few more things here... coz I thought that my initial thread post isn't clear enough in some areas.

1) The vertex buffer object IS created with a proper address and so on and it is a DYNAMIC buffer. Therefore it's created in the DEFAULT pool.

2) The lock operation is of course, called from the vertex buffer object. As we know, it returns a void** pointer which we have to cast and write in manually.

3) The lock flags used are D3DLOCK_DISCARD and D3DLOCK_NOSYSLOCK (these are the flags used for a dynamic buffer).

4) There's a final guard check against the void** being a null pointer afterall. If that's the case, I'll consider my lock as failed even if DirectX didn't return an error code.

5) Since it's not "locked" in the point of view of my own implementation, the vertices will not be allowed to be added into the vertex buffer since we're risking writing a potential null pointer.

Does anyone think that this could have been a synchronous issue? I'm not sure about that...

Thanks and please advise!
thrawn80
You'll never see heaven if you haven't been through hell.
Hi guys,

This is it!

It doesn't work!

I'm beginning to wonder if it's due to the fact that I'm running my own codes in Debug against the DirectX retail libraries that caused the problem.

It simply doesn't work in retail.

The problem lies ONLY with the LOCK function. The rest are ok. The nature of my codes is such that if the LOCK pointer is null, it's not considered locked which will then explain why the vertex buffer in PIX comes up empty.

Also, I've noticed that my RELEASE game application doesn't work properly with the DirectX DEBUG library.

I seriously wonder what's going on now...

I've just updated the latest runtimes for DirectX... should I update my SDK as well?

Please advise...

Thanks,
thrawn80
You'll never see heaven if you haven't been through hell.
Is this a problem just with your hardware, or does it happen on other machines?
Can you produce a minimal example that shows this behaviour?
Can we see the source code of the minimal example?
Hi Steve,

I'll try to post my codes up once I get clearance from the NDA.

As for the possible hardware problem, I'll try the same thing on another machine and see how it behaves.

Regards,
thrawn80
You'll never see heaven if you haven't been through hell.

This topic is closed to new replies.

Advertisement