Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


Move Camera vs Tiles - 2D Optimizations


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
2 replies to this topic

#1 renman29   Members   -  Reputation: 391

Like
0Likes
Like

Posted 02 September 2014 - 11:49 PM

Very interested to know if anyone is doing this optimization:

  I notice a lot of people are scrolling their tiles or drawing them all with spritebatch/quads or something similar which sets vertices every loop.

I'm wondering if anyone has any information or experience with drawing 2D (or layered 2D) like a 3D world and simply moving the camera (but in such a way that vertices do not need updating and are screen clipped by some normal gpu culling process).. I've searched around and I don't see anyone doing this which makes me wonder if I'm missing something?

  I'm thinking the advantage of this too is that different sections of the vertex list could be used each frame to animate vertex colors or add some stretch and squash animations without needing to employ shaders or update vertex data (save gpu power for other shader effects?)

  Of course memory tiles would still need to be scrolled in a corresponding way to keep track of properties for character interactions but that is inconsequential.smile.png



Sponsor:

#2 Kaptein   Prime Members   -  Reputation: 2180

Like
1Likes
Like

Posted 03 September 2014 - 12:19 AM

I create a mesh that covers the screen + 1 tile, then i update that single mesh with texcoords for every layer and draw. In a small-ish 2D game it's going to be fast enough. In a heavier enviroment I would just have meshes for each layer. Another alternative is to generate the entire map in blocks (linearized blocks, eg. a 128x128 map is rendered in 8x8 blocks), and render these submeshes as they appear on screen. These submeshes would be linear in memory which is good.  The most important thing is being able to linearize "something" and with 2D that isn't always so easy. Throw in some SSE if you really need to. I don't think I've come across a computer that didn't have SSE2 at least these days.

 

In my second example, say we have 3x3 blocks of meshes visible on screen. For each row, the 3x1 row would be completely linear in memory, just like a texture 2d array.

The GPU side of things is probably irrelevant as they are "only tiles"



#3 renman29   Members   -  Reputation: 391

Like
0Likes
Like

Posted 03 September 2014 - 12:52 AM

Ah yes - linearized map blocks work well for what I'm doing. :) The layering and effects are heavy for sure(sticking to 1 big texture-source if possible) and also I'm using per-vertex coloring to add extra colored static lighting to the map. I'm thinking I could also track certain animated non-tile-associated mesh parts and translate their world position. Thanks for the ideas biggrin.png






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS