Jump to content
  • Advertisement
Sign in to follow this  
Alex Red

Locking the VB Locks the Application...

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

Hi guys... Working on a DX7 engine... made a Vertex buffers manager... basically, I have 8 Vertex buffers created in VIDEO MEMORY as WRITE ONLY, where I can put objects in, so a single Vertex buffer may contain more than one object... I got a real problem now, and dunno why... when I ma going to put a new object in a Vertex Buffer, of course I Lock it with DDLOCK_NOOVERWRITE | DDLOCK_WAIT | DDLOCK_WRITEONLY | DDLOCK_SURFACEMEMORYPTR options...fill it and unlock it... well... sometimes it happens that the DX Vertex Buffer Lock call do not return, I got no error back...simply the application hangs... I have checked and disabled any function that may use such vertex buffer while adding objects, even the drawing has been disabled... but yet, it happens... Does any1 can give me an Idea about what may 'lock' the Lock call plz...? tnx [R]ed

Share this post


Link to post
Share on other sites
Advertisement
It shouldn't be locking your application. Debugging with DX7 isn't as easy as it is with newer versions of the SDK because there was little information in the Debug Spew, but check it anyway to see if there are any tips to what's causing the problem.

However, one thing that jumps out at me from your Lock call are you flags. You're specifying both DDLOCK_NOOVERWRITE and DDLOCK_WRITEONLY at the same time. These flags contradict eachother and may be casuing problems. Since you mentioned that you're using these vertex buffers to place vertices in all the time, I would suggest removing the DDLOCK_NOOVERWRITE flag because you are indeed overwriting them each frame. Perhaps that will fix the problem.

neneboricua

Share this post


Link to post
Share on other sites
tnx neneboricua...
the NOOVERWRITE was one of the many flags I tested to look for a solution...
in fact it should not be there... however...nothing changes...
What I have found seems to be related with threads...
not sure, but as the VB Manager is called by 2 threads... and only one owns the D3D interface...I believe that even if not called by both threads the same time ( Critical sections there ), the Lock call made by a not D3D owner thread may cause such problem...
have to check better...

tnx

[R]ed

Share this post


Link to post
Share on other sites
To access D3D from a thread other than the one it was created on you must use the D3D Multithreaded flag. Although this really slows the run-time and is very ill-advised, as everything to do with Direct3D really should be on it's own thread.

Share this post


Link to post
Share on other sites
Well I'm not saying that your complete engine should be on a single thread though, I just want to clarify that as there are many good uses of multi-threading in a game engine. But anything done in your Direct3D render system should be done on its own thread.

If your engine as a whole is working directly with Direct3D you probably want to rethink your design on that, as it is best to abstract that away and have a Direct3D render system that handles everything to do with that and you would make calls on that high level construct.

Share this post


Link to post
Share on other sites
Tnx Saruman...
My problem is this... I have a 'Loader Thread' which loads objects on the fly, and of course the G Engine... both of course access the same VBs created by just one D3D, for sure not the same time as they are under CriticalSections Flags...
So there is a way to have another D3D referring same VBs...?where is the D3D multithreading flag u spoke of, if it's the DDSCL_MULTITHREADED in the SetCooperativeLevel() call I am already using it... any more advice...?

tnx

[R]ed

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!