Tag Info

You have to consider that GPUs when fetching the data for feeding into the vertex shaders requires a lot of small calls because they can only cache a few triangles at the same time, and fetching data from the VRAM is a very slow operation. So I suppose that if you use half the bytes for the indices, the GPU will be able to fetch twice the indices for the ...

Yes. VertexPositionTexture is a 20 byte structure. With over 2 million of them, they take up around 43MB of memory. Which gets copied around a bit on the CPU, and then transferred to the GPU. Each frame! There are almost certainly going to be other optimisations you can pursue. I see, in the comments, merging adjacent faces is suggested. I think Minecraft ...

UVIndex represents a series of indices that index into the UV array. However, OpenGL (and D3D) do not allow you to use multiple indices. Each attribute cannot have its own index; the index represents all attributes. Therefore, you need to massage your data a bit, so that everything comes from a single index list. To put it another way, you cannot take an ...

While memory and CPU speeds have improved over the years, games are still often pushing the limits of hardware and software. If you're loading 100 such models, that's a savings of 4 megabytes of memory saved. In certain situations, it's worth it to save as much memory as possible. That might be enough for you to load another model, or enough to cram in a ...

It's not just about memory; some hardware just flat-out cannot support 32-bit indexes and must run the vertex pipeline in software if you use them. It's getting rarer, but you can still get the occasional nasty surprise when you come across one. 16-bit indexes can also run faster in general, which can be important if you're under performance pressure, but ...

This means that I can only store 2^16 = 65536 vertices. No it doesn't. It means that you can only use 16-bit indices (assuming it even means that, as I'm fairly sure D3D9 allows 32-bit indices. That's what the INDEX32 index buffer format means, right?). Which means that a single draw call can only access a 16-bit range of indices. But you are not ...

This is a fairly clear case of premature optimization. You have no performance data saying that there will be any need for optimization. Simply make one vertex buffer per separate object that the user wants to edit, by the time your seeing performance problems you can start profiling your code for the bottlenecks. In particular, swapping vertice buffers is ...

It's not a buffer problem - it's a "your code" problem. First of all, user primitives are slow. They're not horribly slow, but they are slower than using pure vertex buffers. (For info: user primitives are emulated behind-the-scenes with a dynamic vertex buffer, so you're not only redundantly transmitting a large amount of data to the GPU each frame, but ...

There is no need to initialize a constant buffer with default values, simply ensure you have created it initially by calling CreateBuffer() on the d3d device. You then have to call Map() before you can copy any data into that buffer, and then Unmap() to return control of it to the GPU. It is good practice to initialize object members to default values on ...

First of all, 32-bit index support is ubiquitous on modern hardware, and has been for quite some time. If you only support 16-bit then you're long overdue an upgrade. OK, so once upon a time there was a class of hardware that only supported 16-bit. This wasn't a problem back then because there are other options available. One of them would have involved ...

In DirectX there is a method: ID3D11DeviceContext::DrawIndexed(UINT IndexCount,UINT StartIndexLocation, INT BaseVertexLocation); Which allows you to specify where in the buffer to start drawing and how many to draw. If there is anything similar in XNA, wouldn't it be as simple as splitting it into several draw calls, without having to split the buffer? ...

Before doing each draw call you need to bind the buffers appropriate to that draw. So you'd first set the vertex/index buffers for triangles to the GraphicsDevice, then do the DrawIndexedPrimitives call(s) for the triangles; then set the buffers for the lines and draw the lines. You'd only have one vertex buffer set at a time, so you'd only use a ...

The TexCoord array is just an array that stores all the possible values of your texture coordinates, so you can't directly access it. You have to index it via TexCoordIndices, much like Indices does it for the positions of the vertices. And I would check for the negative values that you have in Indices, I'm pretty sure they represent backward-facing ...