Texture Question

I use a radeon graphics card, and in the docs for the card it suggests not using power of 2 textures.
Because it is a waste of video memory. Radeon says there hardware can render non power of 2
Textures at about the same rate as power of 2.
My question is: Does Blitz3D allow for non power of 2 textures.
If I use "CreateTexture" and make a 540x540 texture, will it be changed by blitz, or left the same?
Blitz docs just warn about checking the hardware supports the odd texture sizes.
It doesn't say if anything will be changed, by Blitz internally.
The reason I ask is: I want the pixel count to match my Mesh tile size, on an even boundary.
I need this to tile a larger texture with smaller ones, and have the UV numbers line up nicely.

What's the point if only people with Radeon cards will be able to use your code properly? AFAIK it will only be resized if your videocard can't handle it, but I see no point since it throws your videomemory calculations out of whack and it results in blurry textures on other cards.

I don't think Radeon is the only graphics card that allows this. I would think this is important enough so all modern cards will support it.
I own a Radeon and this is my program.
I am not trying to write programs to sell to other users.
And the main point is, wether Blitz can do it, or not.
This is a Blitz's capabilities question, and is good for all programmers to know.

use the texturewidth and textureheight commands to check
your loaded texture. If anything converts it to power of 2 from a non power of 2 it would be the drivers. I know the old voodoo cards would convert larger textures to 256x256 and odd sized textures to power of 2

the reason it wastes memory is because most memory is based on power of 2 addressing. If all of your textures are power of 2 then they squeeze into memory easier. I would suspect that a 540x540 texture would take up 640x640 memory on some cards ... just a guess... so you end up with the rest as waste.

Thanks for the info on Texturewidth,Textureheight.
I did a check with createtexture I made different sized textures.
I applied them to a square mesh tile.
The odd texture sizes only cover part of the mesh.
A 384 is treated like 3/4 of a 512 texture and only covers part of the mesh.
Also the same thing for a 768. It was treated like a 3/4 1024 texture.
So unless I can set something else I don't know about.
Blitz, Directx, or my hardware, changes the textures to an even 2's boundary.

sorry for bustin in on this thread :)
But does anyone know wether a 16x1024 or a 32x2048 texture would be accepted by a majority of GFX-cards?
It works nicely on the machines I tested it on but on other configurations?

I think there's a ratio of like 8:1 or 1:8

You might think that. All the reading I've done on the subject suggests otherwise. Course a lot of people write a lot of rubbish, so it's possible.




Ok, if you're never going to want other people to see what you've done, go for whatever your card can do.




Hardware is still favourite in my book, though it could be DirectX. I've seen plenty of C++ programmers saying the same thing on programming forums, so I'm pretty sure it's not Blitz.




I'm almost certain it won't work on onboard chipsets, including some of the more recent semi-gaming-usable ones. When you say you tested it, do you mean it didn't crash or that TextureWidth() and TextureHeight() returned the same values you fed? Probably gonna be fine on modern AGP videocards anyway, just not old cards and onboard stuff. They tend to stick to that 1:8 / 8:1 ratio Ross mentioned.

I decided to go with the 512x512 textures. And just use the area I need.
Even though it wastes 300k of mem for each texture.


Has anyone experimented with perlin noise in blitz?
I thought it would make a good means of creating textures, on the fly.
Maybe a rock texture for mountain sides.
I know the formula is out there and just needs to be converted to blitz format.

If anyone has another formula for making a rock texture on the fly, let me know.

I think SSwift wrote a Perlin Noise Generator. Should be in the code archives.