6 replies to this topic

[Stainless]

I am having a problem with sprite sheets on OpenGL ES 1

The client has created a whole load of sprite sheets, but when I render them scaled, I get texture overruns.

For example if the sprite is 100 by 100 pixels and I am displaying it 200 by 200, then the texture stage is picking up pixels from the source bitmap from -0.5 pixels to 100.5 pixels and averaging them onto the display.

So in several places I am getting little bits of other frames displayed.

Has anyone else come across this problem?

Also has anyone found an OpenGL setting to correct this?

Cheers guys, have to have this game finished by Monday and I am fast reaching the stage that I hate the game so much I'm tempted to just tell the client to redraw all the graphics.

Not very professional, but I've churned this one out in 2 weeks and I'm very tired.

[Stainless]

note, I have changed the filter mode to GL_NEAREST and this solves the problem, but it looks crap.

[rompa69]

This is extremely common, and due to linear filtering in magnification. To remedy the issue ensure there's a 2 pixel gap between each sprite. The artefact is caused by the hardware sampling 4 texels around your texture coordinates and it weighting the contibution according to how much a texel-sized area centered at your sample coordinates overlaps each of the 4 texels.
Another potential cause of this issue is the rasterization rules, and the primitive type you're rendering with. Typically, the hardware will not rasterize the right-most and bottom-most pixel in your primitive. If, for example, you used additive blending and the hardware DID rasterize the right-most and bottom-most pixels then when you rendered a triangle strip the triangle edges would get double-rasterized and with additive blending, they'd be added twice.
Fortunately most APIs have state(s) which control this behavior. For individual sprites, you might need to turn this on - allowing your bottom-right texture coordinate to be moved one pixel to the left and up, thus causing the hardware to (hopefully!) not sample outside your sprite bounds when linearly interpolating.

I hope this helps in some way, or at least explains to some degree the issues you're seeing.

[Reedbeta]

Is it possible to contract the sprite's vertices and UVs by half a texel to just crop off the unwanted blended area? That may produce unwanted sharp edges, though.

[Alienizer]

Do you use glChoosePixelFormatARB when creating your context? to use the max anti-alias on the hardware used? That's how I fixed mine when GL_NEAREST didn't work, and now it looks real good!

[Stainless]

Alienizer, on 02 June 2012 - 06:02 PM, said:

Do you use glChoosePixelFormatARB when creating your context?

Sadly, I don't have that extension.

Reedbeta, on 02 June 2012 - 05:27 PM, said:

Is it possible to contract the sprite's vertices and UVs by half a texel to just crop off the unwanted blended area? That may produce unwanted sharp edges, though.

I will have a look, it may work.

At the moment I am running GL_NEAREST as I have today to finish it ( and still have to put in DRM ) but I have warned the client he may have to redo the graphics.

[Mihail121]

Yes, rompa68 is right, use gaps between the individual sprites, most sprite packers offer you to do it automatically. Linear filtering is always a problem with scaling textures from spritesheets, try to use nearest as much as possible.