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

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

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

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.

Tnx Saruman...
I confirmed my doubts then...
and as I dnt want a slow engine... I will make it all Single thread...

tnx

[R]ed

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.

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