Once again...256x256 texture question
Author
I know this has been discussed a billion times but here goes.
I am using the ID3DXSprite interface. All is well.
Normally, I try to keep all of my tiles for the current level into one 256x256 texture. I try to do the same for sprites.
I can probably get away with that with maybe 80% of my game. But, the main character sprite could literally have 200-300 frames. The sprite size is 64x64 so that only give me 16 frames on a 256x256 texture.
I know how to check maximum texture size for the video card (mine actually supports 2048x2048).
Here are my questions:
1) If I check the max texture size, and say it's some weird card that only allows 512x512 and my main sprite is on a 1024x1024 texture. What do I do? I know how to texture switch but that seems to be very annoying and slow. Also, I don't want to simply "mirror" the sprite for running left/right.
2) If I load a texture that is larger than the supported size, what will DX do? Will it truncate it or will it switch to some software-buffering?
3) what would you say is a safe low-end maximum texture size?
4) Assuming a card can handle a texture size of 2048x2048 and my sprites are 64x64 in size. If I draw a sprite from a 256x256 texture, will it draw faster than a sprite from a 2048x2048 texture on the same card? Or does it not matter since the card can go to 2048x2048
Thanks and sorry for all of the questions!
-cb
If you don't want to texture switch, why not load a re-sampled image at the maximum resolution. Simply take your 1024x1024 texture, and re-size it. The quality will be worse, but your speed will be the same.
Otherwise, you will have to switch textures.
As for what happens? Try and load a 4096x4096 texture on your card. See what happens.
Personally I think you can assume 1024x1024 as a safe minimum. If the card cannot support that, it should not be running your app.
Otherwise, you will have to switch textures.
As for what happens? Try and load a 4096x4096 texture on your card. See what happens.
Personally I think you can assume 1024x1024 as a safe minimum. If the card cannot support that, it should not be running your app.
I think the bandwidth requirements of pushing 2048x2048 textures through the pixel pipeline would be painful on most cards. as ataru says you could probably get away with 1024x1024, it really depends on your cards memory bus.
As for what happens it depends on how you're loading the texture, if you create a texture using CreateTexture of larger than the device max it will return an HRESULT of E_FAIL or D3DERR_INVALID_PARAM.
If you use D3DXCreateTextureFromFile my guess is it will resize it to the nearest available. if you use the Ex version of it and force a texture size it will probably fail too.
you might want to consider layered animation techniques or compositing to reduce the number of frames required. I cant really picture that you'd need 300 frames for a character. unless you have VERY smooth animation.
For instance LAYERS:
HAND
GUN
BODY
move the anchor point of hand and gun when your body is running, this saves you all the frames for:
Running without gun
Running with gun
Walking without gun
Standing (doodling?) with/wihout gun etc.
As for what happens it depends on how you're loading the texture, if you create a texture using CreateTexture of larger than the device max it will return an HRESULT of E_FAIL or D3DERR_INVALID_PARAM.
If you use D3DXCreateTextureFromFile my guess is it will resize it to the nearest available. if you use the Ex version of it and force a texture size it will probably fail too.
you might want to consider layered animation techniques or compositing to reduce the number of frames required. I cant really picture that you'd need 300 frames for a character. unless you have VERY smooth animation.
For instance LAYERS:
HAND
GUN
BODY
move the anchor point of hand and gun when your body is running, this saves you all the frames for:
Running without gun
Running with gun
Walking without gun
Standing (doodling?) with/wihout gun etc.
Author
Thanks guys. I will try different things to see what happens.
My game isn't going to be sold to the masses so I don't have to worry about low-end support...lol
In Metroid:Zero Mission, you have something like:
run left normal: 5 frames
run left point diaginal up: 5 frames
run left point straight up: 5 frames
run left point diaginal down: 5 frames
morph ball left: 3 frames
stand left normal: 4 frames
stand left point diaginal up: 4 frames
stand left point straight up: 4 frames
stand left point diaginal down: 4 frames
crouch left normal: 3 frames
crouch left point diaginal up: 3 frames
crouch left point straight up: 3 frames
crouch left point diaginal down: 3 frames
hang left normal: 3 frames
hang left point diaginal up: 3 frames
hang left point straight up: 3 frames
hang left point diaginal down: 3 frames
spin jump left: 4 frames
That's about 67 frames. And that doesn't count things like dangling from a track, damage sprites, speed booster sprites, etc. PLUS, that is only the LEFT. Multiply that by two for the right and you have 134 sprites that don't count the stuff I mentioned above. Some people just mirror left/right sprites but I don't like that. It was OK for the original Metroid. But today, it looks silly when the gun is on the left arm then switches to the right arm..lol
So, 300 sprites is not that far off. The entire MZM hero (Samus Aran) could probably squeeze into 240 sprites that must be loaded all the time and you could load the non-common sprites when you need them (like the death sprites and elevator sprites). Also, there were sprites for when you switched from left and right.
I really don't like building a sprite from several smaller sprites (unless it is a boss). Too complicated for me.
My game isn't going to be sold to the masses so I don't have to worry about low-end support...lol
Quote:
I cant really picture that you'd need 300 frames for a character. unless you have VERY smooth animation.
In Metroid:Zero Mission, you have something like:
run left normal: 5 frames
run left point diaginal up: 5 frames
run left point straight up: 5 frames
run left point diaginal down: 5 frames
morph ball left: 3 frames
stand left normal: 4 frames
stand left point diaginal up: 4 frames
stand left point straight up: 4 frames
stand left point diaginal down: 4 frames
crouch left normal: 3 frames
crouch left point diaginal up: 3 frames
crouch left point straight up: 3 frames
crouch left point diaginal down: 3 frames
hang left normal: 3 frames
hang left point diaginal up: 3 frames
hang left point straight up: 3 frames
hang left point diaginal down: 3 frames
spin jump left: 4 frames
That's about 67 frames. And that doesn't count things like dangling from a track, damage sprites, speed booster sprites, etc. PLUS, that is only the LEFT. Multiply that by two for the right and you have 134 sprites that don't count the stuff I mentioned above. Some people just mirror left/right sprites but I don't like that. It was OK for the original Metroid. But today, it looks silly when the gun is on the left arm then switches to the right arm..lol
So, 300 sprites is not that far off. The entire MZM hero (Samus Aran) could probably squeeze into 240 sprites that must be loaded all the time and you could load the non-common sprites when you need them (like the death sprites and elevator sprites). Also, there were sprites for when you switched from left and right.
I really don't like building a sprite from several smaller sprites (unless it is a boss). Too complicated for me.
Quote:run left normal: 5 frames
run left point diaginal up: 5 frames
run left point straight up: 5 frames
run left point diaginal down: 5 frames
morph ball left: 3 frames
stand left normal: 4 frames
stand left point diaginal up: 4 frames
stand left point straight up: 4 frames
stand left point diaginal down: 4 frames
crouch left normal: 3 frames
crouch left point diaginal up: 3 frames
crouch left point straight up: 3 frames
crouch left point diaginal down: 3 frames
hang left normal: 3 frames
hang left point diaginal up: 3 frames
hang left point straight up: 3 frames
hang left point diaginal down: 3 frames
spin jump left: 4 frames
imo you are wasting frames on left and right, just mirror them. Also point up and point down with compositing can be reduced to half the number of frames. run and stand can be reduced to half similarly by animating only the base layer and anchoring top layers. There is a very nice write up on real-time 2d sprite animation I read not long ago, maybe you can google for it--I looked but couldnt find it in my saves.
Anyway I seriously doubt anyone here who has done 2D anim will agree with separate spritesets for left and right...
Author
Quote:Anyway I seriously doubt anyone here who has done 2D anim will agree with separate spritesets for left and right...
I would and have. With today's computer, I just think it is silly to just mirror. If I am running left with a gun in my left hand, then I turn and start running right, the gun is in my right hand? I think not.
cb
1024x1024, his is a big texture. I have a spare computer here that has a max size of 256x256. I tend to keep my textures at or below 256x256, because most cards will support it. This is considered a 'safe' size.
As far as speed goes, you should look at the surface area that you will be drawing on the screen rather than the texture you are loading. Drawing a sprite that is 50x50 on the screen should draw at the same speed from a 64x64 texture or from a 128x128 texture. But, a big texture like 1024x1024 or 2048x2048 may affect speed on slow machines (if the texture even loads).
A solution may be to load texture / draw primitive for each frame of animation of your main character. This is not as big a performance hit as people think. D3DXSprite does this, and then some, anyway.
Creating your own sprite class may not be a bad idea. Batching could be adding and many other optimizations ...
As far as speed goes, you should look at the surface area that you will be drawing on the screen rather than the texture you are loading. Drawing a sprite that is 50x50 on the screen should draw at the same speed from a 64x64 texture or from a 128x128 texture. But, a big texture like 1024x1024 or 2048x2048 may affect speed on slow machines (if the texture even loads).
A solution may be to load texture / draw primitive for each frame of animation of your main character. This is not as big a performance hit as people think. D3DXSprite does this, and then some, anyway.
Creating your own sprite class may not be a bad idea. Batching could be adding and many other optimizations ...
Author
Quote:Creating your own sprite class may not be a bad idea.
Already done. In fact, my engine is pretty kick-ass. Map class, sprite class, dinput, etc.
I really want to stick to the 256x256 but I just don't see how I can do it with my main character. Plus, I have some boss characters that can be very large.
I will just have to experiment.
cb
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
