strage behavior on different GPUs with direct3d9

Well if the 2d is working the problem lies somewhere else, As the Max2d driver sets up vertex and index buffers and drives them fine. I have feeling its the creatation of your vertex/index buffers some combination of the flags or mechnism for filling is causing the fits.

	D3DDevice.CreateVertexBuffer(vert_array_size, D3DUSAGE_WRITEONLY, D3D_VERTEX_FORMAT, D3DPOOL_MANAGED, VertexBufferObj, Null) 
			D3DDevice.CreateIndexBuffer(tri_array_size, D3DUSAGE_WRITEONLY, D3D_INDEX_FORMAT, D3DPOOL_DEFAULT, IndexBufferObj, Null) 
		

Looking at this you are creating the Vertex Buffer the managed Pool and the Index Buffer in the Defaul Pool.

Not having my SDK docs handy Managed means if the device is lost DirectX will manange recreation across a reset of the device. Change them both to Managed.

Also and check creation succeeds

		If D3DDevice.CreateVertexBuffer(vert_array_size, D3DUSAGE_WRITEONLY, D3D_VERTEX_FORMAT, D3DPOOL_MANAGED, VertexBufferObj, Null) <>D3D_OK 
			Throw "Failed To Create VB"		
		End If		
				
		If D3DDevice.CreateIndexBuffer(tri_array_size, D3DUSAGE_WRITEONLY, D3D_INDEX_FORMAT, D3DPOOL_MANAGED, IndexBufferObj, Null) 
			<>D3D_OK 
			Throw "Failed To Create Index Buffer"		
		End If	

Next

Your method UpdateVBO.

I dont understand the flags with and or stuff but have to assume there is some purpose for that inside your implemenation.

I am concerned that you are writting to a buffer even if lock fails. So restructure this like so..

Dont hold two locks at same time.

			Local VertexBufferStart:Byte Ptr
			Local IndexBufferStart:Byte Ptr
		
			If VertexBufferObj.Lock(0, no_verts * VERTEXSIZE, VertexBufferStart, D3DLOCK_NOSYSLOCK) =D3D_OK
				MemCopy(VertexBufferStart, verts, no_verts * VERTEXSIZE) 
				VertexBufferObj.Unlock() 			
			End If
			
			If IndexBufferObj.Lock(0, no_tris * 3 * INDEXSIZE, IndexBufferStart, D3DLOCK_NOSYSLOCK) =D3D_OK 
				MemCopy(IndexBufferStart, Byte Ptr(tris), no_tris * 3 * INDEXSIZE) 
				IndexBufferObj.Unlock() 
			End If

FYI this was the biggest problem I had with Nvidia and ATI different cards and drivers caused way strange behavior. Originally in version 1 I held the locks open and pumped in tri's until full then unlocked and rendered. I forget which but one vendor always either crashed outright or failed to render if the lock was held across a windows message pump and due to structure of Max2d only way to fix was to create a memory buffer and lock fill unlock render. So I wound up creating my own system memory triangle buffer. Took the performance hit but got stablitiy.

Thinking about it now I know why your getting working results with a SOFTWARE_VERTEX_PROCESSING pipeline. The vertex buffers are kept in system memory until rendering so any kind of funky memory behavior with you locking unlocking with the types of Buffers your creating are being hidden since your always dealing with system memory. But with Hardware Vertex Processing your actually messing with GPU memory directly hence the strange behavior.

Hope this helps. Your questions have actually make me look at Max for first time in long (well since the reflection bug in 1.26/8???) caused a problem for someone using the Max2dDx9 Driver.

I had actually at one time started writing a Max3dDriver Model similar to what you guys are doing but some frustrations with the limitations of Max as language(Lack of system level thread-safety and awful debug capabilities having to expand all 3d math inline to avoid function call overhead) have had me table it to see if BRL tries to address this limitiations.

I will be more than willing to try to help you guys anyway I can. If I can get my old machine up and running I'll see if I can get can my Vertex/Index Buffer Objects available to you guys so you can just deal with filling them and rendering them. I had most of these nuainces pretty well under control and they plugged right into the Dx9Driver so it managed there state creation and destruction. Right now my full time job is killing me timewise not leaving much time for fun.

Doug