As you probably now - there is one entry among DeviceCaps called MaxVertexIndex. As the name implies, it is supposed to indicate the maximum possible INDEX of a vertex in a vertex buffer. Since in C++/C# we index arrays starting with 0, one can guess that maximum index being (x) means the maximal size is (x + 1).

Now, I am testing my MDX application on a a 945GM chipset, and MaxVertexIndex is 65534, so I guess that the maximal size is 65535, which seems perfectly ok, since this is all one can get from a 16-bit register (2^16 - 1). [edit: actually: MaxVertexIndex = 65535 and therefore maximal buffer size = 65536 would be all one can get from a 16-bit reg.]

I need to create a mesh out of vertex and index buffer, simple. Having loaded these two appropriately, I call mesh constructor. The thing is that when I try to construct the mesh specifying vertex number of 65535, the constructor throws the almighty "Error in the application"; specifying vertex number 65534 goes without any problems.

 The question is - why? I could just hard-code it to work, but the twisted logic is quite irritating and I cannot be guaranteed that some other chipset will demand vertex number of (MaxVertexIndex - 3) or so in the mesh ctor. How can one create anything usable on many machines :/.

 Any ideas? Is mesh constructor subject to some additional limitations apart  from the MaxVertexIndex or am I missing something?

 I cross-checked this issue using two different radeon-based machines; they both have MaxVertexIndex cap of 16777215 (2^24 - 1) and both perform exactly the same as 945GM laptop (i.e. create meshes with 65534 vertices max).

I do not set 32-bit registers usage in any way (I guess it is done globally somehow), so I am not surprised 16-bit ones are used by default. What makes me wonder is the fact, that 16-bit limits vertex count to 65534 and not 65535, no matter the device caps.

Is this a rule of sorts? I guess MaxVertexIndex meaning could be interpreted by different vendors in slightly different fashions, but it does not explain this "65534/65535 with 16-bit regs." thing.

 Please, help me solve this ;).

Difficult to come up with a hard and fast rule. I suppose you could shave 5% or 10% off the number for safety. It's a little hacky, but off by one errors and the like do seem common in drivers, depending on the vendor, card and how "seasoned" the drivers themselves are.

Also, when you create a mesh, make sure you specify 32 bit indices if you want to use values higher than 65535.

Ego:

I suppose you could shave 5% or 10% off the number for safety.

I thought of it, but as a last resort really.

jwatte:

treat the value as "MaxNumberOfVertices"

I can reproduce this problem easily, can you? (code below):

...and I mean the two cards with MaxVertexIndex = 2^24 - 1.

If I come up with anything worth mentioning, I will post it here.

By the bye, jwatte, how do you enable 32-bit indices on a per-mesh basis? Can this be done?

nietakt:

Hm, pity you cannot learn such things directly from Microsoft, this kind of guesswork makes me feel anxious.

If I come up with anything worth mentioning, I will post it here.

By the bye, jwatte, how do you enable 32-bit indices on a per-mesh basis? Can this be done?

Microsoft is not responsible for the design of video cards, which is where this number is set. It just gives you the option of 16 bit or 32 bit indices. The MaxVertexIndex number comes directly from the card/drivers.