Archived

This topic is now archived and is closed to further replies.

jRaskell

Some Questions building my 2D engine

Recommended Posts

Working on a 2D top down engine. My quads are all 1.0x1.0 units in size. My current plan is to build the base tilemap in world space and never perform any sort of transforms on that. Just move the camera and actives around the map. This seems preferable to me over translating all the base tiles in front of a stationary camera, but is there something I''m missing that would make the latter a better option? Filling my tilemap vertex buffer. I''m currently filling a temp local buffer with all my vertices data, then copying that into my D3DVertexBuffer. Is there a more efficient manner of filling in the vertex buffer directly? The only other option that was apparent to me was to offset into the vertex buffer through the Lock() for each tile, but this would require a lock/unlock for each tile (1000 tiles in a 100x100 map) and I have read that locks/unlocks are expensive, so this didn''t seem like a valid option. When rendering, I only need to set my streamsource to the tilemap buffer once? Then loop through and render all the quads, setting the appropriate texture for each tile before rendering that tile (DrawPrimitive indexed to that vertex location, set to render only 2 primitives) Currently, I''m just using tile distance from camera position to determine whether to render or not. So I''m really rendering a circle of tiles around the camera, as opposed to just rendering those within the rectangular viewport of the camera, but it''s a simple determination to make and avoids the problems involved with dealing with a rotated viewport. So far what I have is a hard coded 100x100 tilemap with a camera that can be rotated and moved around the map, using the methods I''ve outlined above. Next step is to put in framerate info so I can see what kind of performance I''m getting. I guess that alone would give me an idea of how valid my implementation is, but outside feedback is always useful (and was useful just getting my textured, transformed quads working).

Share this post


Link to post
Share on other sites
Sounds like a fun project!

Just a word on your question about Lock and Unlock operations. The D3D SDK samples actually recommend that you perform a separate Lock/Unlock for each set of, in this case, tiles, the reason being that if you choose your flags wisely the engine will actually render the tiles you''re finished with as you''re filling the next set. Check out the particle system demo in the SDK for an example of this in action. Basically by making sure that you Unlock with the D3DLOCK_NOOVERWRITE flag, you tell the API that you know you won''t be overwriting a vert that is currently being rendered this frame. That way the API doesn''t have to wait for the rendering to be finished to move on.

Of course you''ll only be doing this when the local buffer of tiles needs to be changed, which further reduces any possible performance costs by the Lock/Unlock operations.

A final note of advice on optimization. A lot of programmers make the mistake of obssesively optimizing their code as they go along, often times spending a ton of time agonizing over three lines of code in an obscure math function. My advice is to make it work, identify the bottlenecks, and remove them. If another part of your code is inefficent but only spends a millisecond hacking about, don''t worry about it. In programming your time is the most expensive resource of all.

Good luck!

Share this post


Link to post
Share on other sites