Debate Texture, what's fastest?
Author
Well, I'm debating wether or not having 1 2048x2048 texture containing all my tiles, or having more small textures. I'm using my own "tile class" that work more or less like the D3DSprite helper library and it all is for my 2d game engine.
As I can see it, I have three options.(please comment my thought's).
Have 1 large texture with them all, and use source recs to extract them(using isometric tiles(128x64 base, but can be any size really).
Pro; No texture swapping
Cons; A bigger initail loadingtime? How old cards support these mega textures 2048x2048?
Have a few 512x512 textures, and make some algothrim to blit all partextures from each texture to minimize textureswapping.
pros; Little textureswapping, higher hardware compatibility?
cons; textureswapping, and will require some parser so I can blit them in the texture order not tile order(to minimize texture swapping).
induvidual textures.
pros: really simple?
cons: Extensive texture swapping, and much other stuff.
I'd be glad if someone helped me out, and filled in all the blanks.
I'd add another con to your first option: You might want to add more tiles later on, but even 2048x2048 might not be large enough, so you'll either need to move up to 4096, or have multiple textures.
Personally, I'd keep the system flexible. Be able to use any number and any size of textures. You'll be able to scale down if you need to support older cards, and scale up if you want to minimize texture switches. And you'll never get screwed even if you need 4 separate 4096x4096 textures for a hugely graphical project.
Personally, I'd keep the system flexible. Be able to use any number and any size of textures. You'll be able to scale down if you need to support older cards, and scale up if you want to minimize texture switches. And you'll never get screwed even if you need 4 separate 4096x4096 textures for a hugely graphical project.
I would advise against using ultra-large textures. First of all, they're so large that they can't make efficient use of the GPU's texture cache. Sending over textures in small pieces is also more effecient on the system bus. And besides, modern GPU's can blit many little textures just as fast as one large texture.
Quote:Original post by godmodder
I would advise against using ultra-large textures. First of all, they're so large that they can't make efficient use of the GPU's texture cache. Sending over textures in small pieces is also more effecient on the system bus. And besides, modern GPU's can blit many little textures just as fast as one large texture.
Actually, that's not completely true. They CAN make efficent use of the GPUs texture caches. It's called a texture atlas what the OP is using and there is a reason they were developed (they're not even that old). What does the system bus have to do with anything? You load this texture once, who cares if it takes 2 seconds, it's a one time hit. The GPU accesses the sub-textures by texture coordinates, it's kinda clueless that it's a massive texture.
The major downfall is some older cards don't have enough memory at times. You can, to avoid running into issues later use several smaller, 512x512 textures. That way if you want to add new tiles without having to modify older ones you can just load another one. It also gives you flexiblity to work on older hardware, swapping out textures you don't need for ones you do (if you can organize them like that depending on the level, etc).
Author
Thanks a-lot, but the thing with 512x512 texture is.
Right now I'm looping kind of like.
for (int x;x < 16;x++)
for (int y;y < 25;y++)
texture(TileNumber[x][y]).render();
But that's just for testing(I have 1 class for each texture), and the mapeditor adds that number to a tile.
But if I am to change to this new system, I'd have either to do the same loop, and save both the texture number, and the partial-texture-number (the actual tile) within that texture.
And a bunch of other stuff. But 2048 would probably fit all the tiles for each "real" and 4096 would defenetly. But how's the compatibility for this? I don't want a 2d game requering the latest 7900ultra ;).
And since my little game concist of realms with uniqe tilesets, I could easily swap the large textures during a loading screen.
EDIT:
Checked the compatibility, and 2048 is the maximum texture size for a radeon x850(my card). And it's also the max for radeon 7000. So 2048 it is. And I might make smart. Worst case senareo I'd need 2 of them. And it would be a much simpler parser than for 2 than 50 textures.
Right now I'm looping kind of like.
for (int x;x < 16;x++)
for (int y;y < 25;y++)
texture(TileNumber[x][y]).render();
But that's just for testing(I have 1 class for each texture), and the mapeditor adds that number to a tile.
But if I am to change to this new system, I'd have either to do the same loop, and save both the texture number, and the partial-texture-number (the actual tile) within that texture.
And a bunch of other stuff. But 2048 would probably fit all the tiles for each "real" and 4096 would defenetly. But how's the compatibility for this? I don't want a 2d game requering the latest 7900ultra ;).
And since my little game concist of realms with uniqe tilesets, I could easily swap the large textures during a loading screen.
EDIT:
Checked the compatibility, and 2048 is the maximum texture size for a radeon x850(my card). And it's also the max for radeon 7000. So 2048 it is. And I might make smart. Worst case senareo I'd need 2 of them. And it would be a much simpler parser than for 2 than 50 textures.
I'd say that you'll end up in trouble eventually with this scheme. At somepoint you'll need a system to organize your objects to be rendered at some order (ie. ordering the objects by their texture etc). So, it doesn't matter if you have 2 or 50 textures. Beside, maintaining this one big texture is difficult. Not to mention the problem of adjacent tiles bleeding color to each other. And finally your artist will be hitting his/her head to the wall.
It may seem a bit inefficient to process your tilemap "tile by tile", so I'd suggest to create sort of bigger tiles like 8x8 or 16x16, and inside these blocks you can prearrange the tiles in the most efficient manner. This way have a precreated mesh ready to be rendered. This doesn't limit your system anyway.
If you draw your screen tile by tile, you will get huge performance loss from the drawing calls and keeping things in one texture won't save a lot.
Cheers
It may seem a bit inefficient to process your tilemap "tile by tile", so I'd suggest to create sort of bigger tiles like 8x8 or 16x16, and inside these blocks you can prearrange the tiles in the most efficient manner. This way have a precreated mesh ready to be rendered. This doesn't limit your system anyway.
If you draw your screen tile by tile, you will get huge performance loss from the drawing calls and keeping things in one texture won't save a lot.
Cheers
Thanks Well, I'm not using meshes for my game, it's 2d with quads. So should "bleeding" really be a problem if I make the texel conversion and everything 100% right?(Setting up source descs and such). Always though these were 100% accurate.
And as far as maging goes. 2 2048x2048 textures in PNG format can maximumly take a 10mb each of video memoryspace. And I'm aiming for a 64mb minimum 128 recomended, so that shouldn't really be and issue to preload it all and never release anything(unless I'd change zone or something). A last, but "space" ineffeciant method is to save all tiles used on the specific map in one file. But since I'm using pretty big mapps all tiles might end up being used on one anyway--. Am I totally wrong here?
And as far as maging goes. 2 2048x2048 textures in PNG format can maximumly take a 10mb each of video memoryspace. And I'm aiming for a 64mb minimum 128 recomended, so that shouldn't really be and issue to preload it all and never release anything(unless I'd change zone or something). A last, but "space" ineffeciant method is to save all tiles used on the specific map in one file. But since I'm using pretty big mapps all tiles might end up being used on one anyway--. Am I totally wrong here?
Quote:Original post by Demus79
If you draw your screen tile by tile, you will get huge performance loss from the drawing calls and keeping things in one texture won't save a lot.
Could you explain? What are the alternatives to drawing tile by tile?
Author
I'm using a batched method. So it isn't really "tile by tile". 1 drawprimitive call for all my tiles.
@ELFanatic: There's a great turoial on it, though I used it, I modified it heavily,and made it suit my needs.
http://www.gamedev.net/reference/programming/features/2d3dquads/page4.asp
@ELFanatic: There's a great turoial on it, though I used it, I modified it heavily,and made it suit my needs.
http://www.gamedev.net/reference/programming/features/2d3dquads/page4.asp
Quote:Original post by Anonymous Poster
Thanks Well, I'm not using meshes for my game, it's 2d with quads. So should "bleeding" really be a problem if I make the texel conversion and everything 100% right?(Setting up source descs and such). Always though these were 100% accurate.
And as far as maging goes. 2 2048x2048 textures in PNG format can maximumly take a 10mb each of video memoryspace. And I'm aiming for a 64mb minimum 128 recomended, so that shouldn't really be and issue to preload it all and never release anything(unless I'd change zone or something). A last, but "space" ineffeciant method is to save all tiles used on the specific map in one file. But since I'm using pretty big mapps all tiles might end up being used on one anyway--. Am I totally wrong here?
Actually you cannot use the PNG size for anything. That's compressed and on card it will not be. On card it will be 2048x2048x16/32 = 6,7108,864/134,217,728 bytes
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
