EACam |
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? |
EACam |
Posted - May 17 2004 : 7:37:49 PM I could do that...but it'd be slow. Spose that's why there's a loading screen! Thanks. |
Eric Coleman |
Posted - May 16 2004 : 2:29:12 PM If you use DirectX, then you might run into some problems with incompatibilities when rendering to a texture. I might be mistaken, but I think that you can simply bitblt from a surface to a texture in directx 7, but then there may be some card compatibility problems.
The easiest way would be to create temporary bitmap files. In pseudo code it would be something like
Start DirectX and fine largest texture size supported by the video card. Resize Picturebox1 to that size For Each Tile Load Image into Picturebox2 BitBlt or Paintpicture to a location in PictureBox1 End Type Save PictureBox1 As temp.bmp Load temp.bmp into a Directx surface |
EACam |
Posted - May 16 2004 : 1:33:39 PM Great!
But still...HOW do I create a texture with code inserting lots of other little textures? |
masterbooda |
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!!! |
Eric Coleman |
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. |
VBBR |
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. |
EACam |
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. |
masterbooda |
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...... |
Almar |
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 |
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... |
EACam |
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. |
Eric Coleman |
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. |
masterbooda |
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...
|
EACam |
Posted - May 14 2004 : 4:13:59 PM ok.
Eric? |
VBBR |
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. |