Hi ive run into a problem, ive got more than 65k indexed vertices. to speed thing up I use one draw call for all objects with the same render state wich meant I had to use indexed vertices for drawing textured surfaces. I also found its a lot quicker to put all the objects into the vertex buffer wether they are currently visible or not than to re create the vertex buffer each frame, but now I have too many vertices to fit ! is there a way to specify a bigger starting offset than for DrawIndexedPrimitives ? obvious alternative is to break up the buffer but just wondered if there was another way round this ? thanks ps ah its ok i just changed the index buffer from short to int. I just folowed the sample and hadnt realise it could be either. [Edited by - UnrealSolo on March 5, 2008 9:29:32 AM]

Quote:Original post by UnrealSolo
Hi
ive run into a problem, ive got more than 65k indexed vertices.

to speed thing up I use one draw call for all objects with the same render state wich meant I had to use indexed vertices for drawing textured surfaces.

I also found its a lot quicker to put all the objects into the vertex buffer wether they are currently visible or not than to re create the vertex buffer each frame, but now I have too many vertices to fit !

You can use a dynamic index buffer, and lock and fill that each frame if you wish. Although that may be what you're doing now.

Quote:Original post by UnrealSolo
is there a way to specify a bigger starting offset than for DrawIndexedPrimitives ?

obvious alternative is to break up the buffer but just wondered if there was another way round this ?

You can either use a 32-bit index buffer, but then the data will be twice the size. Also, not all cards support 32-bit index buffers, and even if they do, it doesn't nessecarily mean that you can reference 2^32-1 vertices, most cards will only do up to 2^24-1 or less.

Another alternative is to use the BaseVertexIndex parameter to DrawIndexedPrimitive to offset into the vertex buffer. See the SDK documentation for an example of this.

ah thanks, after changing it to 32 bit i read about the limitaion with some cards, I also did quite a bit nmore reading.

your suggestion of the vertex base works, I just changed it back to shorts lol.

I just have to start my indexes at zero for the start of each primitive data, presumably I wont have indices over 65k for 1 single texture type, althoug ive put in a catch for this, the biggest map I have seems to be about 200k vertexes.

I didnt fully understand the numbers in the indexed primitive call, I played about before but couldnt get it to work unless I stuck to the sample.

I think I understand it now, but as for dynamic buffers ive not got into that yet, its probably better, but this is only an editor not a game, so a fram rate of 20fps is quite ok, wich is what I get now for my biggest maps, on an amd65/3200 with ati 9800 pro.

im using xna atm but this is dificult to integrate into forms, and I wil need a 3d view and some 2d views too like orthogonal projection, so I will probably switch to slimdx, so I dont want to modify it to much atm if its all going to change, but it works ok for now.

it would be nice if it let me pass it all the objects I use and to let me modify them, the xna content pipleine takes care of this but needs the models premade before run time wich for an editor is a bit of a limitation !

I seem to end up spending so much time with the graphics i dont seem to get much further with the editing features and especialy the user interface.

Im also having problems getting it to work on a machine with vmware, aparently vmware doesnt support pixel shaders !

Quote:Original post by UnrealSolo
Im also having problems getting it to work on a machine with vmware, aparently vmware doesnt support pixel shaders !

What shader version? The 9800 only supports v2.0, I wouldn't have thought using VMWare would make much of a difference...

http://www.vmware.com/support/ws55/doc/ws_vidsound_d3d_audience.html
says :-
Not all aspects of 3-D acceleration are enabled. The following 3-D features are not accelerated:

Pixel and vertex shaders
Multiple vertex streams
Hardware bump-mapping, environment mapping
Projected textures
Textures with one, three, or four dimensions