Sign in to follow this  
Thrawn80

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

Recommended Posts

Thrawn80    142
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

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites
Evil Steve    2017
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?

Share this post


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

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites
Evil Steve    2017
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?

Share this post


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

Share this post


Link to post
Share on other sites

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