4
\$\begingroup\$

I'm trying to figure out the best way of rendering my layered tiled maps with WebGL, and have come across this tutorial several times: https://blog.tojicode.com/2012/07/sprite-tile-maps-on-gpu.html

Someone even created a library for it here: https://github.com/englercj/gl-tiled

The gist of this "GPU abuse" seems to be generate a texture where each pixel as a lookup table into the tileset spritesheet. That is, the red component refers to the x coordinate and the green component refers to the y coordinate. Additionally, in the library, the blue component refers to the corresponding tileset to use.

This seems to accomplish exactly what I am attempting to do, but I am confused on two parts.

For one, the author describes this is a neat little trick and "GPU abuse". I feel as if the implication there is, "this is a fun little exercise, but don't actually use this for your game or any serious code."

Is this the case, or is this actually a potentially serious technique that I could use to power my map rendering?

Secondly, I'm somewhat confused why this is even necessary. I am still learning WebGL, so I might mess up a few terms here, but couldn't this same exact thing be accomplished in a more straight-forward manner? Why go through all these steps of creating a custom generated texture of your map, when you can just create a (static?) Vertex Buffer Object, load it with all your tiles, and then just render them?

I'm not really understanding what exactly this technique buys as that can't be accomplished in the same way by just creating a large buffer that just contains all our tile data, and then just rendering it like that. Isn't that conceptually simpler, arguably easier to implement, more straight-forward, and doesn't have weird restrictions like maximum tile count or width?

Basically, I'm having trouble understanding what advantages this has over traditional rendering where you just load up a buffer with tiles. If there are some advantages, should this technique be seriously used in a game?

\$\endgroup\$
5
  • \$\begingroup\$ It's not abuse. You are free to use the GPU however you want. \$\endgroup\$ – user253751 Mar 23 at 15:47
  • \$\begingroup\$ Also VBOs can't contain tiles, only vertex data. What would that vertex data look like? \$\endgroup\$ – user253751 Mar 23 at 15:47
  • 1
    \$\begingroup\$ You're correct about the gist, but left out one important element: it's only ever pushing 4 vertices through the GPU, instead of 4 for every single tile (as one might do in the "naïve" implementation). A single quad will generally render a lot faster than hundreds. The spritesheet itself is a similar trick -- by combining all the tile textures into one single texture, we can minimize the amount of work the GPU has to do, resulting in quicker renders and more frames per second. \$\endgroup\$ – A C Mar 24 at 3:25
  • \$\begingroup\$ @AC Isn't the GPU parallel? Why would rendering one quad be faster than 100? Wouldn't all 100 be rendered at the same time anyway? \$\endgroup\$ – Ryan Peschel Mar 24 at 20:18
  • \$\begingroup\$ One benefit of that technique is that it uses less memory. It only stores one vec3 per tile. With vertex data, you would need to store that data for each vertex (there are 4 vertices in each tile). I can't think of any problems with the technique (just the limitations that are mentioned in the article, such as the texture size limitation, but you could work around it anyways). \$\endgroup\$ – tuket Apr 19 at 20:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.