New problem.. This is getting bad =/

[terence]

I am not sure what your application is ..and I don't really like nit-picking..not all cards support this function which makes chunking the only viable way to ensure interoperability over a wide variety of cards.

I look more in this as NOT a quick hack, but as a long term solution that works over both OpenGL and DirectX. Essentially this should be a different interface and possible different data structure then the Texutre pointer to ensure best speed allowing the user of the API to control when to use it. Not really in a position to be helpful yet, so I will shut up.

[hybrid]

I think the solution of making a larger texture and using subtextures with the correct size is pretty smart, it just needs some proper care taking for all methods working with textures to honor the correct size, i.e. using the correct texture coordinates for the right and bottom border.
However, NPOT textures should also be supported, a texture creation flag sounds logical and would keep the default Irrlicht behavior as much as possible.

[terence]

Sorry.. I know I said I should shut up...

Could we move this into a feature or alternate thread. I am interested on implementing a long term solution to this and I am decent enough programmer to be able to do so(a crappy 3D person though;))...(or as we like to say..still learning)...

I agree that supporting NPOT texture are required. They are more applicable for 2D games IMHO than 3D games required large texture surfaces mostly to blit the entire screen..

It would be easier enough(if I had time) to rewrite both drivers for OpenGl and DirectX to support it ONLY for 2D systems. But since I am kinda a development schedule, I may opt to just use the PopCap framework for my current title. My basic concern with all this is that I don't know what else I have to do to get the engine in shape to support a 2D game title plus the cross platform and graphics card compatibility is quite important to me..

I ramble...Sorry about hijacking this thread

[Yotunii]

This does actually seem like a decent solution to the problem. I don't see why chunking is better than simply adding some transparent extra at the end of the texture, tho? A flag so you can choose between adding the transparent stuff, or resize it should be sufficient. I can supply a complete texture loading function that adds transparent data to the buttom right side of images, if you feel like it.

[hybrid]

There would be also the necessity of a D3D8/9 solution. I think that ImageSize and TextureSize/OriginalSize should be enough to get the right texture coords, but it might be hard to create the correct values automatically in all situations

[Spintz]

From DirectX SDK Documentation on D3DCAPS9.

Not sure about DirectX8. But if DirectX8 doesn't support them at all, then just force them to be power of 2.

D3DPTEXTURECAPS_POW2
If D3DPTEXTURECAPS_NONPOW2CONDITIONAL is not set, all textures must have widths and heights specified as powers of two. This requirement does not apply to either cube textures or volume textures.

If D3DPTEXTURECAPS_NONPOW2CONDITIONAL is also set, conditionally supports the use of 2D textures with dimensions that are not powers of two. See D3DPTEXTURECAPS_NONPOW2CONDITIONAL description.

If this flag is not set, and D3DPTEXTURECAPS_NONPOW2CONDITIONAL is also not set, then unconditional support is provided for 2D textures with dimensions that are not powers of two.

D3DPTEXTURECAPS_NONPOW2CONDITIONAL
D3DPTEXTURECAPS_POW2 is also set, conditionally supports the use of 2D textures with dimensions that are not powers of two. A device that exposes this capability can use such a texture if all of the following requirements are met.

The texture addressing mode for the texture stage is set to D3DTADDRESS_CLAMP.
Texture wrapping for the texture stage is disabled (D3DRS_WRAP n set to 0).
Mipmapping is not in use (use magnification filter only).
Texture formats must not be D3DFMT_DXT1 through D3DFMT_DXT5.
If this flag is not set, and D3DPTEXTURECAPS_POW2 is also not set, then unconditional support is provided for 2D textures with dimensions that are not powers of two.

A texture that is not a power of two cannot be set at a stage that will be read based on a shader computation (such as the bem - ps and texm3x3 - ps instructions in pixel shaders versions 1_0 to 1_3). For example, these textures can be used to store bumps that will be fed into texture reads, but not the environment maps that are used in texbem - ps, texbeml - ps, and texm3x3spec - ps. This means that a texture with dimensions that are not powers of two cannot be addressed or sampled using texture coordinates computed within the shader. This type of operation is known as a dependent read and cannot be performed on these types of textures.

[hybrid]

Thanks for the info! however, the restrictions seem too strong to make this really useful in all situations. Missing mipmap support may indicate to use these textures only for 2d images? Similar to ARB_rectangle_textures, but ARB_non_power_of_two is definitely more powerful and more useful. Let's see if there's a chance to get this working all the same across platforms

[Spintz]

good luck with it if you have any questions, i'll try to help out, i'm focusing on other things right now and NPOT textures aren't important at all to me