multiple vertex buffers

Couldn''t you just use a single quad, and use IDirect3DDevice8::SetTexture to specify which texture to draw? Or use ID3DXSprite? So long as you don''t need to change texture coordinates for each different tile (which you probably wouldn''t have to do), either should work just fine.

Unless I''m missing what you''re trying to do

Tom

OK, lets go like this:

why not have everything in ONE VB?

One VB for all tiles, then:
(a) set texture
(b) render all tiles of the texture
(c) switch texture
(d) continue at b.

YOu can render parts of a VB :-)

This way you avoid switching the VB, which imho is a more expensive operation than switching the texture.

Regards

Thomas Tomiczek
THONA Consulting Ltd.
(Microsoft MVP C#/.NET)

quote:

---

Original post by thona
OK, lets go like this:

why not have everything in ONE VB?

One VB for all tiles, then:
(a) set texture
(b) render all tiles of the texture
(c) switch texture
(d) continue at b.

YOu can render parts of a VB :-)

This way you avoid switching the VB, which imho is a more expensive operation than switching the texture.

---

Don''t know about that. Locking and unlocking it is expensive, as you have to transfer it to the card again. But if you defined 10 and just swicth the stream source, it should not be expensive.

Ok, time to dip my unqualified finger in the pot.

I think I have the same issue as Chaucer - and here is one way I intend to try dealing with it...

My (2d - d3d based) game will have onscreen a plane, (one object)
several clouds, (say 4 or five that the plane can fly beneath at any one time) a score/data board, and a background.

So if I create one VB with one quad and then:

set streamsource to the quadVB

scale and translate quadVB to the window size and location;
set texture to b/ground
drawPrimitive(quadVB)
scale and translate quadVB back to the original size and loc;


scale and translate quadVB to the plane size and location;
set texture to the plane
drawPrimitive(quadVB)
scale and translate quadVB back to the original size and loc;

for (i = 0 -> i == numclouds){
scale and translate quadVB to the cloud[ i ] size and location;
set texture to cloud
drawPrimitive(quadVB)
scale and translate quadVB back to the original size and loc;
}

deal with the score board and it's contenets similarly.

I am pretty sure this is what krumms meant in the first reply, but just wondering if it is right/practical/correct?

EDIT who would have thought [ i ] without the spaces meant something ...

[edited by - thehermit on September 27, 2002 7:08:29 PM]

Using a quad in a VB could work but one vertex buffer for evrything could work as well. Locking is only done when you first put data in and not when rendering so if you only draw parts of the whole VB and switch textures in between there is no locking/unlocking neccessary.

I also came up with the same question a few weeks ago.

I figured I wanted to render a large cube (for my skybox) with the viewpoint being on the inside and my background textures rendered on the inside surfaces of the cube.

That left me with the question of how to use one vertex buffer for my cube but set a different texture to each of the six faces. It seemed like I was going to have to have a different vertex buffer for each of the 6 faces because I didn''t know of a way to identify the textures with their corresponding faces and render all at once.

Of course, I could put all the vertices in a vertex buffer and only call drawprimitive() on 4 of them at a time while changing textures before each quad. But, then I would either have to change texture coordinates for each set of 4 vertices or create multiple vertices for each actual corner.

Is that pretty much how this sort of thing is handled? It doesn''t look like there is any mechanism for making one call to drawprimitive() and have different textures go to different quads within the set of primitives being drawn. OGL does something like that with drawlists doesn''t it? Does DX have anything comparable?

quote:

---

OGL does something like that with drawlists doesn''t it? Does DX have anything comparable?

---

Retained Mode 80)

It depends on how big your tiles are - can you fit all of them into one texture?
If you can, then you can set the texture once, and use the uv texture coordinate to determine which portion of the tiles-texture to display (kinda like sprite, where you have one bitmap with different frames of the animation).

Use VBs to describe the geometry that you are tiling - store the coordinates (and uv mapping) of your tile-grid in a VB.

If you can''t fit all the tiles into one texture, then you can investigate two techniques for rendering. You can either minimize the texture switching overhead, or minimize the looping overhead. It is hard to tell which method will be faster - the cross-over point is the intersection of a steep linear line and a swallow quadratic one (assuming there are considerablely more tiles visible than there are tile-types).

Either set the texture prior to rendering each visible tile (steep linear) - or, set a texture tile and loop through all the visible tiles rendering all of them that are of that tile type. Loop through all the visible tiles for all the types of tiles.


The first method (one texture) will be massively faster. The second method depends on the number of visible tiles, and the thriid method will only be faster if you have a small number of tile types (and/or can cull the tile-type-space effectively).