I'm writing code in XNA 4.0, and part of my game entails drawing a textured grid of cubes. It is working, but the problem is the memory usage is growing way too rapidly. Each cube has 8 points, and each point is a VertexPositionTexture. A 16x9 grid takes 50MB memory, and that is just the grid and lines, no textures or anything else. Doubling the grid to 32x18 makes the memory jump to 150MB....I don't understand what is taking up so much room. I draw the grid using DrawUserIndexedPrimitives. The cubes can move around and be different sizes so I can't consolidate them to one set of vertices. What is the proper way to render a few thousand vertices without using so much memory?

These are all the members for my Cube class so far:

GraphicsDevice graphicsDevice; // for drawing this cube
Tileset tileset; // reference to parent object
VertexPositionTexture[] pointList; // the list of 8 vertices
BasicEffect basicEffect; // effect to draw using a shader
Vector3 localTranslation; // just 3 floats
VertexBuffer vertexBuffer; // for sending the vertices to the GPU

There are also a few functions that allocate memory for the pointList...but nothing out of the ordinary...

  • 2
    \$\begingroup\$ Gah! Nevermind. It is the BasicEffect that is using up all the memory. I am instantiating it for each Cube, should have just have a reference to a single effect. After doing this my memory drops to 15MB...this is more like it. \$\endgroup\$
    – Mossen
    Commented Aug 6, 2011 at 5:44
  • 2
    \$\begingroup\$ @Johnathan Hobbs, The question is perfectly fine. He posted the code to the cube class. He said he is spawning lots of the cubes. Before I read his answer I was going to say that he should not create any shared objects or textures, only reference them. \$\endgroup\$ Commented Aug 6, 2011 at 6:36
  • 1
    \$\begingroup\$ @AttackingHobo: You're right; I didn't read his comment fully. \$\endgroup\$ Commented Aug 6, 2011 at 7:21
  • 1
    \$\begingroup\$ @Mossen you should post that as an answer. Answering your own question is fine. \$\endgroup\$ Commented Aug 6, 2011 at 8:52
  • \$\begingroup\$ You could do even better. Just because the cubes are moving around and scaled is no reason to duplicate their geometry. Each cube just needs to be a location and a scale. Instancing can take care of the rest. \$\endgroup\$
    – Blecki
    Commented Aug 6, 2011 at 23:11

2 Answers 2


Love all these minecraft inspired games! What an awesome project to get a kickstart into development. Glad you managed to track down the problem yourself as well!

Another optimization you might want to consider down the line: as many cubes form larger surfaces, instead of storing 100 cubes as a 10x10, store it as one big cube. This way you just need 8 vertices instead of 800. If one needs to be removed make a 9x10 block, then a row of 9 individual blocks (or even a 9x1 size block for bonus points). Remember just because something 'looks' like a million blocks, doesn't mean you need a million blocks. There is no such thing as cheating in computer science, only innovation.


There's a few things that come to my mind.

First of all, the SpriteBatch object is quite large. Is it nescessary to instantiate it for every cube?

The same could be said about the VertexBuffer. If the cubes are similar, you can re-use the vertex buffer.

As for the effect, again, if the cubes are similar, re-use it.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .