|
EACam
Warrior
154 Posts |
 Posted - May 14 2004 : 12:26:17 PM
|
Alrighty...i've heard a lot about this, but never a solid statement answering this question:
Which is better: using lots of small textures and switching textures often during run-time, or using few larger textures holding multiple tiles in them and switching less but having to use the large textures and texture coordinates?
Lots of smaller textures is obviously easier (except in the case of animations)...and I've heard people say "Don't using large textures!" and others say "Don't switch textures often!"
What's the deal? |
|
|
VBBR
Moderator
Brazil
617 Posts |
Posted - May 14 2004 : 12:38:55 PM
|
Having multiple textures per file has the advantage that you can have non-square textures. Also I think loading a big texture is faster than loading a lot of small textures that summed up have the same size.
One drawback is that a lot of video cards doesn't support textures larger than 256x256 and some doesn't support even textures larger than 128x128.
|
Whatever. Who knows... |
 |
|
|
EACam
Warrior
154 Posts |
Posted - May 14 2004 : 3:00:14 PM
|
Thanks. I'll go with with 256x256 grouped tile files...unless...
128x128? Really that small? Is it worth designing a game to have compatability with that type of card (considering it must be ancient)? I've heard 256 mostly, but a lot of people go for 512, right? |
|
|
|
Peter
Administrator
Canada
67 Posts |
Posted - May 14 2004 : 3:05:12 PM
|
| Basically, each texture calls in D3D are relatively slow, so the fewer you have of them the faster your game will run. |
Talos Studios - VoodooVB - VB Gamer
|
|
|
|
VBBR
Moderator
Brazil
617 Posts |
Posted - May 14 2004 : 4:11:05 PM
|
| I don't know... ask Eric, I think he knows a lot about old cards like the Voodoo series. |
Whatever. Who knows... |
|
|
|
EACam
Warrior
154 Posts |
Posted - May 14 2004 : 4:13:59 PM
|
ok.
Eric? |
|
|
|
masterbooda
Swordmaster
277 Posts |
Posted - May 14 2004 : 5:06:35 PM
|
What I have done is load 256x256 textures and then create smaller say 16x16 textures and blit from the larger into the smaller then destroy the larger one... I do all this at the begining...
I have noticed when the texture coordinates are 0 and 1, instead of calculated texture coordinates, it runs a little faster...
Also this gets rid of the artifacts on the edges... which can be pretty annoying...
Also when doing animation you just have to change the texture instead of recalculating the texture coordinates each time... which saves some process time..
This process is time consuming, yes I know, but you only have to do it once... and the memory used is the same, once you destroy the larger texture..
DaBooda out...
|
DaBooda Team is back: http://dabooda.789mb.com/ |
|
|
|
Eric Coleman
Gladiator
USA
811 Posts |
Posted - May 14 2004 : 5:35:37 PM
|
I would suggest using a large texture, this will allow you to batch together anything that uses tiles from that texture into a single draw primitive call. DirectX operates faster when you batch many primitives together.
You might want to consider doing the opposite of what masterbooda suggested. Instead of having a large texture and creating small textures, you could enumerate the video card to find its largest texture size, generally 256x256 will be the fastest even if the card supports larger texture sizes, and then assemble large textures with all of the tiles used for that map. |
|
|
|
EACam
Warrior
154 Posts |
Posted - May 14 2004 : 7:28:59 PM
|
Hmmm... interesting. I think i'll do that...only one problem:
How? All I know how to do is load with the D3DX.LoadTextureFromFile and LoadTextureFromFileEx...i've never done it any other way. |
Edited by - EACam on May 14 2004 7:29:29 PM |
|
|
|
masterbooda
Swordmaster
277 Posts |
Posted - May 14 2004 : 10:04:50 PM
|
yeah why listen to a squire...........har har har..........
Actually for maps, erics suggestion is best, but for sprites... I found that by doing my method works best... because its always changing...
Actually its up to programmer's preference... but keeping the largest texture to 256x256 is a must... regardless...I am a blithering idiot........ weeeeeeeeeeee
DaBooda out... |
DaBooda Team is back: http://dabooda.789mb.com/ |
|
|
|
Almar
Moderator
Netherlands
192 Posts |
Posted - May 15 2004 : 02:37:26 AM
|
Old picture I made for YALG. I can simply make huge batches of vertices and render them instantly. Animations are just done by movign the tu coordinates to the right, or the .tv to the bottom. It's that easy. This way is absolutely the way to go.
1x DrawPrimitive vs 100x with 100 textures is so much faster. |
|
|
|
masterbooda
Swordmaster
277 Posts |
Posted - May 15 2004 : 05:52:13 AM
|
But aren't you making a call to set the texture with every render pass anyways...... I mean are you really saving any time......... Is there a way around this... If so please explain...... I really would like to know....
Because for a large game..... you are going to have more than one texture.... is there a way to say which primitives use what texture initially ... instead of setting the texture with the
Direct3DDevice.SetTexture
During every render...... and if you are just setting texture coordinates....... you are going to be reseting those with every pass too.... with animations...... I mean it works well with no animation... but that would be a pretty boring sprite...
Maybe texture pooling........please give examples.....
DaBooda out...... |
DaBooda Team is back: http://dabooda.789mb.com/ |
|
|
|
EACam
Warrior
154 Posts |
Posted - May 15 2004 : 09:00:40 AM
|
Yeah, I'm a little confused as well...what exactly are you doing Almar?
Just for your information, my game could have over 350 different tiles rendering at all times...considering i've got the map, but then there's the grass and stuff that goes on top of the dirt (actually, there'll be at least 3 layers for every tile), so that's another render, and then i've got sprites...talk about massive. |
|
|
|
VBBR
Moderator
Brazil
617 Posts |
Posted - May 15 2004 : 09:30:38 AM
|
| I think the best way to discover it is trial. Try, try, and try until you find the way it works faster in your case. |
Whatever. Who knows... |
|
|
|
Eric Coleman
Gladiator
USA
811 Posts |
Posted - May 15 2004 : 7:00:45 PM
|
VBBR is right, just create some test programs, and then use whatever method you're comfortable with.
If you batch your textures together, then there will be fewer texture changes. In reality, changing textures is hardly the slowest part of any game.
In Almars case, if he were to keep his tiles seperate, then that would be 64 SetTexture calls, and 64 DrawPrimitive calls. By batching them togehter, instead of 128 function calls, he can make just one SetTexture and one DrawPrimitive, which is faster. |
|
|
|
masterbooda
Swordmaster
277 Posts |
Posted - May 15 2004 : 10:57:29 PM
|
And there you have it........ it is up to you and what the game really calls for......
And I'm not writing this to get the last word...... nope not booda...... not me
DaBooda out......
P.S. Last Word!!! |
DaBooda Team is back: http://dabooda.789mb.com/ |
|
|
DX optimization
