I've come across some information of something called Rectangle Packing, meaning to put all my (small) textures in one big texture. This to avoid texture switches. To perform this action I will have to modify my vertices every renderphase and set the correct vertexcoordinates to get the right subgraphic on each quad. Will this be a performance loss (to iterate through each vertex and modify its properties) or a performance gain (I don't have to switch texture and I can draw all primitives in one call). In my current design, I do a lot of texture switches but my vertexbuffer doesn't require any modification, just a world translation to move the vertices. Which method is better? Is there an advantage in keeping the vertices untouched or are they resent through the pipeline anyway? I would appreciate some opinions regarding this issue. 2D tile platform game, current design Textures My tiles are allocated in an array were each tile is a texture, the tiles are quite small (~32x32) in size. Vertices I've allocated a "vertexgrid", enough vertices in a vertexbuffer to fill up a grid-like structure which can cover the total screensize. Four vertices per tile multiplied by the number of tiles that can fit on the screen. Each vertex position and vertexcoordinates are determined, I will never have to mess with these vertex properties again. Rendering In every render phase I check the camera position and translates the worldmatrix in steps of the tilesize to make sure my grid always is in the viewport. Last of all I render the correct tiletexture in the right vertexquad on the screen. This way I have a grid which moves along with my movements and I can render my tiles according to the current position. For each tile I render I have to set a new texture but my vertices can remain untouched.

Modifying the verts is much more expensive than switching textures. So definitely don't do that.

I've seen a lot of examples where people are drawing batches of vertices, meaning they create a loop, allocate maybe 1000 vertices and assign them, draw their primitives and restart the loop continuing with the next 1000 vertices until all vertices have been completed.

Is there a limit in vertexbuffer size? Why not allocate all the vertices from the beginning and send them all when drawing?

And also if I know for sure that my vertexbuffer will remain static, is there any limit to how big buffers I can make. Usually in a 2D game you can allocate all vertices that is needed for all the graphics, (you already know their sizes). It will be alot of vertices, but if static buffers is fast and there is no limit why not do it?