Jump to content
  • Advertisement
Sign in to follow this  
BennettSteele

C++ Tile-Sheet Repeating (Repeat portion of sheet)

This topic is 2508 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

So im changing my game's environment from minecraft-blocks to something better, but i need to know how i can still use a tile sheet...

so if i have a block, lets say 1x1x1, then it would show this portion of the tile sheet:

0,0_______1,0
| |
| |
| |
0,1_______1,1

as lets say, a dirt tile. now if i were to stretch it out to 10x10x10, then it would repeat the dirt tile, but still use the portion of the tile sheet.

Share this post


Link to post
Share on other sites
Advertisement
No, you probably don't wan't to do that. Every time you bind a different texture it's a state change, and those are really expensive. Its best to keep them to a minimum where its reasonable. I forget the precise setting, but there is indeed a parameter that can be set which will repeat a texture based on the coordinates you give it, IIRC. You could also do this in a shader, or by simply simply building those 10x10x10 blocks out of the smaller ones -- Today's GPUs can handle tons and tons of geometry (especially if its instanced), so even though it might sound like a lot, its probably more efficient than constant state changes. Also, if you cull a 10x10x10-size block, you only need to render 271 1x1 cubes, worst-case.

Share this post


Link to post
Share on other sites
To be fair, either is near bordering on premature optimization, but yes its generally considered a best practice to minimize state changes -- particularly on WinXP and previous, because state change code in the driver was not in user-land, and making those kind of kernel-mode calls came with a lot of overhead, to the point that you could do maybe 3 thousand per frame at most -- things are better now, but its still a good idea because any time spent changing state is time *not* spend drawing. Taking for example a texture change, the GPU would flush and refill its texture caches, possibly reaching out to main memory to gather the data. Then, there might be more associated changes with the material -- lighting parameters, shaders (which might have to be JIT'd by the driver), etc.

Now, the end goal is to minimize state change, and there's a variety of ways to do that -- for example, in a minecraft-like game where most of the blocks are aligned on a grid, you can use geometry instancing, or you could simply take the approach of batching manually (run through the cubes per usual, but instead of rendering, place them in different buckets according to texture, then render the buckets one by one -- the more blocks captured per texture, the bigger the buckets are.)

I would strive to put each block type that is treated similarly (same lighting properties, shaders, etc) into a single texture, and then choose different sub-textures via coordinates+repeat, or a pixel shader.

Share this post


Link to post
Share on other sites
Unless supporting older hardware or different sizes per block texture is an issue, the magic feature would be called texture array. Tiling simply works, your texture coords are always 0 and 1, no textures bleeding into each other when filtering and using a simple index instead of fiddly texture coordinates. As an alternative you could simply use a 3D texture, the main difference being a float coordinate for the layer instead of an index.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!