Re: Re: Tips for debugging D3D Textures & DirectSound?

Hi Adam,

You will need to add support for EXT_texture_rectangle and
NV_texture_rectangle, which are virtually identical to eachother
anyways.  (As is ARB_texture_rectangle which is intended to replace
both, although, again, functionally identical.)

This will require multiplying all texture coordinates by the width and
height of the texture before use.  Easiest would probably be to push a
matrix onto the texture stack.  You'll need to do a bit more work for
the vertex shaders, though.  (Add in the instructions to do the mul
before output.)

We haven't handled this yet ourselves.

Incidentally, when a card finally comes on the market that supports
ARB_texture_non_power_of_two this will no longer be necessary, since
cards exposing that extension will support those texture formats
natively.


Regards,
James

P.S. It's lists.transgaming.org, not .com  ;)

On Tue, 2004-10-05 at 08:19, Adam Luchjenbroers wrote:
> > It's probably more likely that the game is trying
> > to use non-power of two textures here.
> 
> In some cases, the textures are indeed not power of two, some are
multiples
> of powers of two (eg. 64x96, is this alright for OpenGL). All textures
that
> successfully load ARE powers of two (64,128,256,512). All texture
loading
> appears to go through the same code-path.
> 
> Observed image sizes of failing textures.
> 800x600
> 300x31
> 1024x768
> 64x96
> 
> If this is the case, how do we go about fixing this? I'm guessing this
will
> have been encountered before? Can we apply a fix used then or is this
an
> unresolved issue?
> 
> I beleive nVidia's OpenGL may have a proprietary extension for
non-power of
> two textures, what about other cards? Can we use this where it is
available?
> And what can we do where it isn't?
> 
> It might be possible (although CPU consuming) to resize the textures
on the
> fly or pad the extra space out with alpha, but will one of these two
> solutions not cause rendering issues? Will we have to alter the
texture
> alignment when they're rendered back down (in which case, the above
solution
> starts to reek of hack).
> 
> From a trace, +ddraw,+tid.
> 
> 0002:trace:ddraw:D3D_GL_update_texture_stage_states
> 0002:trace:ddraw:D3D_GL_update_texture_stage_states stage 0, state 0
> (TEXTUREMAP), value 0x553be948
> 0002:trace:ddraw:GL_PixelFormat_To_TextureFormat surface format
00000040, 32
> 0002:trace:ddraw:GL_PixelFormat_To_TextureFormat masks: 00ff0000,
0000ff00,
> 000000ff, 00000000
> 0002:trace:ddraw:GL_PrepTexture ID 2, fmt 80E1, ifmt 1907, type 1401
> 0002:trace:ddraw:GL_PrepTexture GL_Prep_Texture:610: glGetError
returns
> 00000000
> 0002:trace:ddraw:GL_load_texture_target GL_load_texture_target:424:
> glGetError returns 00000000
> 0002:trace:ddraw:GL_load_texture_target loading target 0de1, level 0,
> 800x600, ptr 0x5a1b0020
> 0002:err:ddraw:GL_load_texture_target glGetError returns 00000501 for
> D3D_GL_load_texture
>