Texture Limitations

If you want to draw a 640x480 background, and limit your textures to 256x256 and below, why don''t you use:

(256+256+128 - 3 textures)x(256+128+64+32 - 4 textures)

See what I mean?



- Goblineye Entertainment
The road to success is always under construction

Well, you could go to every vid card manufacturer in the world

I''m going to try and throw some workarounds at you.

To get by the 256x256 problem, you can use multiple 256x256 textures on multiple polys to make up a background (clumsy)
You can stretch a texture across a large poly, and hopefully it won''t look to shagged out because you''ve done your mipmapping well.

-Mezz

Okay; this makes sense, but won''t the overhead for drawing 12 (4x3) textures instead of 1 large one degrade the performance far below DirectDraw (DX7) performance?

Also, if I use my own "multiple-textures-surface" routines (dividing all textures into more smaller ones), I can no longer use the DX8 routines for creating/loading the textures, such as "CreateTextureFromFile" etc...? (Or at least split up the artwork into smaller files...?)

So, if I have a bitmap of 65x65, I have to use 4 blocks of 64x64:
That''s not very efficiënt...?

:-) I know it would be no problem to simply use 64x64 instead, but this is a theoretical case

Greetings, and thanx for the replies,

CondorWitte

You may be pleased to discover my next tutorial will cover this. You basically need to create a surface without a texture, and then use CopyRects to copy it to the backbuffer. The reason I do it this way is:
a) I don''t need color keying, so CopyRects will suit me
b) I don''t need to break up big images into smaller ones.

I will be using CopyRects exclusively for backgrounds.

---

Please state the nature of the debugging emergency.

sharewaregames.20m.com

Thanx!

That''s a great tip. Although no stretch,color key or alpha blend is supported, this is probably a fine way to put the background in place.

I assume no interpolation will be done at all (no stretch and no subpixel transformations)...?

Greetings,

CondorWitte

I''d like to see hardware limitations on textures go away... its about time I think. Of course I have no idea why there''s a limit in the first place, and it''s reasonable to assume that because it still exists that its not a trivial problem (or the manufacturers are incredibly lazy). Anyways, along with all the many extras that really never get used on cards I''d like to see something that would really help out being implemented...

------------
- outRider -

Yes, there is a very good reason why the 256x256 limit has been imposed for so long. Remember how everyone says not to change textures often? That''s because the card has to copy the texture from its normal video RAM to a special very-very-very high speed (read EXPENSIVE $$$) chunk of memory devoted solely to the texture.



~BenDilts( void );

The power-of-2 allows for a serious performance boost in texture manipulation algorithms. When you know ahead of time that the dimensions fall on an even power of 2 you can write dedicated code to thoses sizes that are orders of magnitude more efficent than a generic algorithm. In theory it could be done for powers of 3, 5, 7, 11, 13, etc... and some slightly slower code could do the combinations. But it would be a lot of work, and require additional hardware for each prime order. FFT's work in this fashion. And you cover any surface using a sums of powers of 2, and when would ever ever want to have a really fast texture manipulation on a 243x243 texture? Powers of 10 would be kinda nice though...

Maybe you could make a 'virtual' texture surface the size you want and hide the ugly implementation inside a classs...

There's no good reason a texture is limited to 256x256, other than it need to stop some where. Its like there's no good reason that processors were once limited to 100MHz. Faster/bigger capibilities will keep coming out.
There's not much purpose to a 1024x1024 texture, because that's larger than the screen resolution that most people play at. As people want better resolutions, that texture sizes will get bigger too. And of course, all those textures eat RAM.

With the exception of the background, you will probably never need a texture larger than 256x256.


...
Is there built-in functions with Dx to let you wrap a single texture across multiple polygons? If you wanted to do that, a big texture would make sense.

...
Oh yeah, I almost forget your question
You can get device dependant information using the GetCaps function od DD & D3D. I imagine that texture limits had to be one of the elements of the D3D GetCaps...

Edited by - Magmai Kai Holmlor on November 25, 2000 1:36:26 PM