I want to use this method:

HRESULT GetBackBuffer(          UINT iSwapChain,
    UINT BackBuffer,
    D3DBACKBUFFER_TYPE Type,
    IDirect3DSurface9 **ppBackBuffer
);

Parameters iSwapChain [in] An unsigned integer specifying the swap chain. BackBuffer [in] Index of the back buffer object to return. Back buffers are numbered from 0 to the total number of back buffers - 1. A value of 0 returns the first back buffer, not the front buffer. The front buffer is not accessible through this method. Type [in] Stereo view is not supported in Microsoft® DirectX® 9.0, so the only valid value for this parameter is D3DBACKBUFFER_TYPE_MONO. ppBackBuffer [out, retval] Address of a pointer to an IDirect3DSurface9 interface, representing the returned back buffer surface. I just wanted to ask what does the UINT iSwapChain is for? and what value should I put in it? Thanks in advance. EDIT: Long lines and [code] tags break the forum layout. Corrected. [Edited by - jollyjeffers on May 20, 2006 1:24:52 PM]

Did you try 0? I'd guess you only have one swap chain, and that the index is zero based.

So, when is it possible to have more then one swap chain for a single device?

I have another question.
I am using DrawPerimitive to draw retangles with textures as sprites.
I also want to enable "free hand" pixel drawing. i.e. locking the back buffer and assigning values to the memory via the pointer.
The question is, when should I lock and draw?
It might be problematic due to that the cards draws the perimitive I sent with draw perimitive with its own "thread".
However, drawing into the back buffer needs to be done with the applicaition thread?
So how can I work this thing out?

Thanks in advance

Quote:Original post by The C modest god
So, when is it possible to have more then one swap chain for a single device?

See IDirect3DDevice9::CreateAdditionalSwapChain(), IDirect3DDevice9::GetNumberOfSwapChains() and the documentation 'Presenting Multiple Views in Windowed Mode' [smile]

Quote:Original post by The C modest god
I also want to enable "free hand" pixel drawing. i.e. locking the back buffer and assigning values to the memory via the pointer.
The question is, when should I lock and draw?

As little and as rarely as possible. Batch together multiple edits and submit them in one go, once per frame. Don't lock-write-unlock for every single pixel!

Also, consider using render targets and a bounded buffer approach, that way you should be able to maximize concurrency between the GPU/CPU.

hth
Jack

Quote:Original post by jollyjeffers

Quote:Original post by The C modest god
So, when is it possible to have more then one swap chain for a single device?

See IDirect3DDevice9::CreateAdditionalSwapChain(), IDirect3DDevice9::GetNumberOfSwapChains() and the documentation 'Presenting Multiple Views in Windowed Mode' [smile]

Quote:Original post by The C modest god
I also want to enable "free hand" pixel drawing. i.e. locking the back buffer and assigning values to the memory via the pointer.
The question is, when should I lock and draw?

As little and as rarely as possible. Batch together multiple edits and submit them in one go, once per frame. Don't lock-write-unlock for every single pixel!

Also, consider using render targets and a bounded buffer approach, that way you should be able to maximize concurrency between the GPU/CPU.

hth
Jack

So what you are saying is that instead of locking the back buffer I should use a texture. Lock the texture, draw into it and draw a sprite perimitive with that texture?
Or in other words if I lock a texture on the cards video memory, the card will continue to draw previous perimitive while the texture is locked and the main application manipulates the texture's memory?

[Edited by - The C modest god on May 20, 2006 2:08:58 PM]

Quote:Original post by The C modest god
So what you are saying is that instead of locking the back buffer I should use a texture. Lock the texture, draw into it and draw a sprite perimitive with that texture?

Sort of. If you have a single texture then you have little advantage. Having multiple textures allows you to cycle them (look up "bounded buffer" or "ring buffer") such that you can be locking/manipulating a texture that isn't being directly used for rendering...

Quote:Original post by The C modest god
Or in other words if I lock a texture on the cards video memory, the card will continue to draw previous perimitive while the texture is locked and the main application manipulates the texture's memory?

The GPU cannot use the resource whilst it is locked, so no.

EDIT: there are cases where it can... but you have to get the setup just-right - a trivial implementation will stall. [smile]

Have a look at one of my recent journal entries, its a piece I'm putting together for the forum's FAQ.

hth
Jack