Most images pure white on old hardware

SDL Development
#1

I’m close to releasing my game for Windows:

www.actionsoft.com/files/mmhd/MMInstal.exe

However, tested on my sister’s computer earlier tonight and it fails pretty bad. Almost all the graphics show up as pure white when run on her machine, except for the “ghoul hand” on the title screen and the game’s version number. I’m not sure why those two pieces draw correctly, and the rest doesn’t.

Curious if I should just write this off as “old hardware” issue, or if there are any suggestions what I might look into? The game uses OpenGL and SDL 1.3. My sister’s computer is fairly old (Intel Atom processor, 1.6 ghz, built-in Intel graphics chipset) and it supports OpenGL 1.4. Drivers are current from Intel.

Also, if anyone else can test the link above and post if it works or not for you, I’d be much grateful! Would be happy to contribute registration codes for Episode 1 (the first half of the game) in return. (Just email me directly at vern AT actionsoft dot com.)

-Vern

#2

A quick guess is that you may be using non-power-of-two texture sizes and the driver may not support these with full flexibility.

A few examples:
53x20 - not power of 2.
64x32 - power of 2.
320x240 - not power of 2.
512x256 - power of 2.

If this is the problem, and you wish to use these sizes you may have to scale up the images (or pad them with blank space) to make them hardware compatible, this does require adjusting texcoords if
you pad them.

Of course it could be something else.

I recommend making a macro like:
#define CHECKGLERROR do{int err = glGetError();if (err) printf("%s:%i: glGetError() = %i\n", FILE, LINE, err);}while(0)

You can then sprinkle calls to this macro all over the place, like after every gl call you suspect may be a problem, and see if it prints something about it.

Obviously you may need to use something other than printf to make it work on Windows, I just mention this an example.

A slight upgrade is to call your print print function that takes the err enum and prints a textual version instead (so you see GL_INVALID_OPERATION or similar instead of a number).

You may also be able to use an off-the-shelf OpenGL debugger.On 12/15/2011 01:07 AM, VernJensen wrote:

I’m close to releasing my game for Windows:

www.actionsoft.com/files/mmhd/MMInstal.exe http://www.actionsoft.com/files/mmhd/MMInstal.exe

However, tested on my sister’s computer earlier tonight and it fails pretty bad. Almost all the graphics show up as pure white when run on her machine, except for the “ghoul hand” on the title screen
and the game’s version number. I’m not sure why those two pieces draw correctly, and the rest doesn’t.

Curious if I should just write this off as “old hardware” issue, or if there are any suggestions what I might look into? The game uses OpenGL and SDL 1.3. My sister’s computer is fairly old (Intel
Atom processor, 1.6 ghz, built-in Intel graphics chipset) and it supports OpenGL 1.4. Drivers are current from Intel.

Also, if anyone else can test the link above and post if it works or not for you, I’d be much grateful! Would be happy to contribute registration codes for Episode 1 (the first half of the game) in
return. (Just email me directly at vern AT actionsoft dot com.)

-Vern

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

#3

Huh, 64x32 wouldn’t be power of 2? What would it have to be padded to? 64x64? So you’re saying the height has to match the width on these older cards?

-Vern

Forest Hale wrote:> A quick guess is that you may be using non-power-of-two texture sizes and the driver may not support these with full flexibility.

A few examples:
53x20 - not power of 2.
64x32 - power of 2.
320x240 - not power of 2.
512x256 - power of 2.

If this is the problem, and you wish to use these sizes you may have to scale up the images (or pad them with blank space) to make them hardware compatible, this does require adjusting texcoords if
you pad them.

Of course it could be something else.

I recommend making a macro like:
#define CHECKGLERROR do{int err = glGetError();if (err) printf("%s:%i: glGetError() = %i\n", FILE, LINE, err);}while(0)

You can then sprinkle calls to this macro all over the place, like after every gl call you suspect may be a problem, and see if it prints something about it.

Obviously you may need to use something other than printf to make it work on Windows, I just mention this an example.

A slight upgrade is to call your print print function that takes the err enum and prints a textual version instead (so you see GL_INVALID_OPERATION or similar instead of a number).

You may also be able to use an off-the-shelf OpenGL debugger.

On 12/15/2011 01:07 AM, VernJensen wrote:

I’m close to releasing my game for Windows:

www.actionsoft.com/files/mmhd/MMInstal.exe http://www.actionsoft.com/files/mmhd/MMInstal.exe

However, tested on my sister’s computer earlier tonight and it fails pretty bad. Almost all the graphics show up as pure white when run on her machine, except for the “ghoul hand” on the title screen
and the game’s version number. I’m not sure why those two pieces draw correctly, and the rest doesn’t.

Curious if I should just write this off as “old hardware” issue, or if there are any suggestions what I might look into? The game uses OpenGL and SDL 1.3. My sister’s computer is fairly old (Intel
Atom processor, 1.6 ghz, built-in Intel graphics chipset) and it supports OpenGL 1.4. Drivers are current from Intel.

Also, if anyone else can test the link above and post if it works or not for you, I’d be much grateful! Would be happy to contribute registration codes for Episode 1 (the first half of the game) in
return. (Just email me directly at vern AT actionsoft dot com.)

-Vern

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

#4

**
Huh, 64x32 wouldn’t be power of 2? What would it have to be padded to?
64x64? So you’re saying the height has to match the width on these older
cards?

-Vern

You misread it: he wrote - "64x32 - power of 2"On Thu, Dec 15, 2011 at 12:20 PM, VernJensen wrote:

Forest Hale wrote:

A quick guess is that you may be using non-power-of-two texture sizes
and the driver may not support these with full flexibility.

A few examples:
53x20 - not power of 2.
64x32 - power of 2.
320x240 - not power of 2.
512x256 - power of 2.

If this is the problem, and you wish to use these sizes you may have to
scale up the images (or pad them with blank space) to make them hardware
compatible, this does require adjusting texcoords if
you pad them.

Of course it could be something else.

I recommend making a macro like:
#define CHECKGLERROR do{int err = glGetError();if (err) printf("%s:%i:
glGetError() = %i\n", FILE, LINE, err);}while(0)

You can then sprinkle calls to this macro all over the place, like after
every gl call you suspect may be a problem, and see if it prints something
about it.

Obviously you may need to use something other than printf to make it work
on Windows, I just mention this an example.

A slight upgrade is to call your print print function that takes the err
enum and prints a textual version instead (so you see GL_INVALID_OPERATION
or similar instead of a number).

You may also be able to use an off-the-shelf OpenGL debugger.

On 12/15/2011 01:07 AM, VernJensen wrote:

Quote:

I’m close to releasing my game for Windows:

www.actionsoft.com/files/mmhd/MMInstal.exe **

However, tested on my sister’s computer earlier tonight and it fails
pretty bad. Almost all the graphics show up as pure white when run on her
machine, except for the “ghoul hand” on the title screen
and the game’s version number. I’m not sure why those two pieces draw
correctly, and the rest doesn’t.

Curious if I should just write this off as “old hardware” issue, or if
there are any suggestions what I might look into? The game uses OpenGL and
SDL 1.3. My sister’s computer is fairly old (Intel
Atom processor, 1.6 ghz, built-in Intel graphics chipset) and it supports
OpenGL 1.4. Drivers are current from Intel.

Also, if anyone else can test the link above and post if it works or not
for you, I’d be much grateful! Would be happy to contribute registration
codes for Episode 1 (the first half of the game) in
return. (Just email me directly at vern AT actionsoft dot com.)

-Vern

SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
LordHavoc
Author of DarkPlaces Quake1 engine -
http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged
demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

#5

Managed to duplicate the problem on my own system by using GL_Texture_2D as the texture extension instead of GL_TEXTURE_RECTANGLE_EXT.

Then discovered that I need to call:

glTexParameteri(caps->extension, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameteri(caps->extension, GL_TEXTURE_MIN_FILTER, GL_LINEAR);

right before every object that is drawn, rather than once per “animation cycle”. I could get away with once per cycle with RECTANGLE_EXT, but not with TEXTURE_2D.

And now it works. :slight_smile:

#6

Managed to duplicate the problem on my own system by using
GL_Texture_2D as the texture extension instead of
GL_TEXTURE_RECTANGLE_EXT.

Then discovered that I need to call:

glTexParameteri(caps->extension, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameteri(caps->extension, GL_TEXTURE_MIN_FILTER, GL_LINEAR);

right before every object that is drawn, rather than once per
"animation cycle". I could get away with once per cycle with
RECTANGLE_EXT, but not with TEXTURE_2D.

Vern,

glTexParameteri(…) sets the property on the currently bound texture
object. It is sufficient to do glTexParameteri() once per texture
object. You might want to make sure you do that for each texture object
as it is created instead of once per animation cycle.

PatrickOn 12/16/11 05:32, VernJensen wrote:

And now it works. Smile

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

#7

This means the error was that your textures used a mipmapping filter (GL_LINEAR_MIPMAP_LINEAR most likely) as the default, but had no mipmaps (thus an incomplete texture).

These are texture properties and can be safely set after the glTexImage2D call.On 12/15/2011 03:32 PM, VernJensen wrote:

Managed to duplicate the problem on my own system by using GL_Texture_2D as the texture extension instead of GL_TEXTURE_RECTANGLE_EXT.

Then discovered that I need to call:

glTexParameteri(caps->extension, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameteri(caps->extension, GL_TEXTURE_MIN_FILTER, GL_LINEAR);

right before every object that is drawn, rather than once per “animation cycle”. I could get away with once per cycle with RECTANGLE_EXT, but not with TEXTURE_2D.

And now it works. Smile

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier