Odd problem...

It would help a bit if there was a reference image (ie how it should look like) ... but anyhow I'll try.

The sprite itself seems to look different in the 2 images: is it just a textured quad?

What is the background composed of? Is there any geometry or just a texture? If it's a texture it's possible there is a mistake in the texture loading code (check the pixel unpack alignment).

I presume that that "mess" supposed to be a background of some sort? A correct screenshot of what it should look like would have helped a bit. :)

If it is a background, I'd say your texture upload is failing somehow. Check your glTexImage2D calls to see if an error is being returned by glGetError. What are your texture sizes? Are they tiles, or is it just one big polygon? How is it encapsulated into a display list?

I'll need a little more information before I can help any more.

The sprite is a textured quad, yeah. One of the two images is badly compressed, and the sprite's facing away from the camera too, which would explain the difference.



Here's some rendering pseudocode to illustrate how the scene is built.

- Clear the depth buffer and color buffer.
- Render the terrain, which is cut up into various sectors, each a display list (nothing too complicated; loosely, you could say each "hill" is a sector.)
- Render the scenary objects (in this case, the pillars). Again, display lists.
- Render the background (clouds), currently immediate-mode billboarded quads.
- Render the sprite, same method as the background.
- Overlay the minimap in glOrtho; the map is currently in immediate mode and constrained to the window via a scissors test.
- Write text, still in glOrtho mode, in the upper-left corner.
- Swap the buffers.

Originally I figured it might be a problem with the display lists not being supported, but...

1- The background isn't a display list and it doesn't get rendered.
2- Display lists failing on 3 different PCs with different specs and cards? Unlikely.
3- One of my betatesters gets the game working fine when in full-screen mode, but not windowed. It's not like her card would suddently evolve a mechanism to support DLs out of the blue.

The most frustrating thing is that I can't debug this at all. It works absolutely fine on my PC. And it's not as though anything complicated takes place while rendering the scene, I'm not even using VBOs at the moment. I'm basically working in the dark, occasionally sending something to my betatesters to see if things work.. :/

Edit: The textures are all 128x128, except for the BG which is 256x256. This includes the spriteset and the window in the corner, which are all defined, loaded, and used in the exact same manner.

Quote:

Original post by RuneLancer http://img108.imageshack.us/my.php?image=image14iy.gif

This definately looks like you are rendering on top of a video buffer that hasn't been drawn to or cleared, since the bootup of your computer. However you said that you clear your color buffer every frame, so that shouldn't happen.

Are grabbing the video buffer at any point in your game to use as a texture ?
In the second image it looks like all of your ortho stuff is drawn, but none of your 3D stuff is. Are you sure you are clearing the color AND the depth buffer?
Try turning depth testing off.

Is your character animated? if so are there any artifacts left over the screen from previous animation frames?

This really looks like a driver issue.

What really gets me is this...

The sprite isn't drawn in ortho. It's actually drawn the exact same way the BG is - billboarded polygonal 3D non-ortho sprite. There's nothing setting the two apart other than their sizes (and the fact you move the sprite around - not the BG.)

I've submitted my betatesters a version without textures, one fully in immediate mode, and one without illumination (who knows...) Maybe that'll help figure out what's causing the problem.

But I have no idea why the BG would get scrapped but not the sprite. They're drawn the exact same way. :/

(Originally, it really did seem like a color buffer not being cleared issue, but I made sure otherwise and the problem persisted.)

Hmm, that's pretty bizarre. Even if the textures for your scene didn't get uploaded properly, you should still see the geometry, but just with garbage textures.

I would suggest taking a look at GLIntercept and see if any GL functions are flagging an error. If you are using certain extentions, you can get an extention list of your betatesters and try it on your own system to see if that might trigger the same problem.

Sorry, I don't have any more ideas... good luck though!

Try taking out the rendering of any of your 3D stuff, and just leave the ortho rendering. Clear your color buffer to a noticable color, like green or red. Then give it to your betta testers. This will allow you to test if the buffer is even being cleared correctly on the machines of your betta testers.

Try to eliminate possiblilites from the bottom up. If the color buffer isn't even being cleared correctly than its pointless to tweak other rendering.

A thought..

One of my betatesters tried the different versions I produced and reported running the untextured version just fine, but not the other two.

Some code has changed in the way textures are managed, though the OpenGL-specifics haven't, since the last version. To boot, the outer walls and the pillars didn't show up in his screenshots, both of which share the same texture.

My question is this: isn't the poly supposed to end up white and untextured, or can this vary from card to card to the point where it would simply not render polygons with inexistant textures? Or better yet, could attempting to access a texture that doesn't exist cause junk to be returned (one of my betatesters reported being able to recreate the junk he was getting - the one with the white background in the screenshots) I was under the impression if it failed to grab a texture it would just render the geometry untextured but if this isn't consistent across different cards, I just might have my answer...