Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I can't figure out why the black lines are appearing, but I can give you another way to render the landscape that could result in it looking correct (and, hopefully, give you a little speed boost).</p> <h2>Sprites</h2> <p>You will need a <a href="http://en.wikipedia.org/wiki/Texture_atlas" rel="nofollow noreferrer">texture atlas</a> (a.k.a. sprite sheet) for this to work. You could split your altas into multiple atlases and use multi-texturing.</p> <h2>Vertex Buffer</h2> <p>What I would do is scratch the SpriteBatch, you always know where your sprites are going to be - create a <code>VertexBuffer</code> at startup (possibly one per layer) and use it to draw the layers. Something like this (<em>this is a 2D buffer, it just 'looks' 3d like yours</em>):</p> <p><img src="https://i.stack.imgur.com/h4dXw.png" alt="Vertex Buffer Sample"></p> <p>The vertex definition would probably consist of:</p> <ul> <li>Position (<code>Vector2</code>)</li> <li>Texture Coordinate (<code>Vector2</code>)</li> <li>Color (<code>Vector4/Color</code>)</li> </ul> <p>Each time the landscape needs to be 'cycled' (more on this later) you would go through the map under the camera and update the texture co-ordinates and/or color in the <code>VertexBuffer</code>. Don't refresh the buffer each frame. I wouldn't send the texture co-ordinates to the GPU in <code>[0, 1]</code> range, rather <code>[0, Number of Sprites]</code> - calculate the <code>[0, 1]</code> in your vertex shader.</p> <p><em>Important:</em> Don't share vertices (i.e. use an <code>IndexBuffer</code>) because the vertices that are shared by more than two faces need to remain distinct (they have distinct texture co-ordinates) - build up the buffer as though <code>IndexBuffer</code>s didn't exist. Using an <code>IndexBuffer</code> is wasteful in this scenario, so just stick with a <code>VertexBuffer</code> alone.</p> <h2>Rendering</h2> <p>The world matrix you use will map <code>[0, 1]</code> to the size of the screen plus the size of a tile (i.e. a simple scale <code>x = Viewport.Width + 32</code> and <code>y = Viewport.Height + 32</code>). Your projection matrix would be an identity matrix.</p> <p>The view matrix is tricky. Imagine that your map is looking at a current block of the tiles (which it is) at <code>{0,0}</code>, what you need to do is figure out the offset (in pixels) from that where your camera is looking. So essentially it will be an offset matrix with <code>x = Camera.X - LeftTile.X * (Viewport.Width / NumTiles.X)</code> and similar for <code>y</code>.</p> <p>The matrices are the only tricky bit, once you have them set up it's a simple <code>DrawUserPrimitives()</code> call and you are done.</p> <p>Note that this only deals with your landscape, draw your other sprites as you are today.</p> <h2>Landscape Cycling</h2> <p>When the position of your camera changes, you basically need to determine if it's looking at a new block of tiles and update the <code>VertexBuffer</code>s appropriately (texture co-ordinates and color - leave the position alone, no need to recalculate it).</p> <h2>Alternatively</h2> <p>Another option is to render each layer to a <code>RenderTarget2D</code> and use your current transformation once against the entire layer. This would either resolve your problem, or, it would make the real reason very apparrant.</p> <p><em>Side note: I would provide sample code if it wasn't 00h40 here, this question deserves it. I'll see how much time I have tomorrow night.</em></p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload