not sure if this is a bug or not (and if so, if it is filed as such) or if it is made intentionally like this, but we notice, at least in Cocos2d-x v3.2, that TransitionCrossFade seems to use nearest filtering when executing the transtion between the scenes. Is this a bug or is it made like this intentionally?
EDIT: I noticed I was unclear. If you look at the BOXIT2 logo for example, you can see that during the transition, it looks like GL_NEAREST filtering is used. All textures in both scenes are set to use GL_LINEAR. Right away the transition is finished, the BOXIT2 logo appears as it should.
Before crossfade:
<img src="/uploads/default/6875/d028ef0f9f1b25cf.png" width
i believe, thats the work of cross-fading
first dissolving the current scene and shows the next scene during the transition
what i could guess is
your first scene consists a sprite which is digiment as you’ve stated
when scene transition goes on it dissolved the current scene to next scene
if you don’t want to see the logo on the next scene… i believe you should use non-alpha transition.
I dont know actually, but i will learn it from here too…
but i guess that’s the case
thank you for replying. I think you misunderstand this. This is not an issue with alpha I am talking about, obvisouly this is a fade between two scenes so there must be some bledning involved. I am talking about filtering, not blending All textures used in both scenes are set to use GL_LINEAR filtering, however, during the transtion it looks like, at least for the next scene that it is faded to, that GL_NEAREST is used, you can see the difference very clearly in the BOXIT2 logo.
CCRenderTexture.cpp calls _texture->setAliasTexParameters(); which turns off mips and sets sampling to GL_NEAREST
To do the cross-fade, the TransitionCrossFade renders each scene into a RenderTexture, then blends them. So normally-- if that texture is rendered at native resolution, you don’t need to filter, since it’s pixel exact. But maybe you run into a situation where non-pow2 textures aren’t supported, or … I don’t know, some slight scaling issue… whatever-- you don’t render that texture back at exactly its dimension. This is the scaling I’d expect to see.
Yeah, thanks Ajas, I noticed that RenderTexture calls _texture->setAliasTexParameters() in initTextureWithWidthAndHeight(int w, int h, Texture2D::PixelFormat format, GLuint depthStencilFormat)… Anyhow, thanks!
Right, but did you figure out why the aliasing issue?
Remember-- you have exactly the same number of texels as pixels, so you shouldn’t need to filter. So there is a bug in RenderTexture. There is some loss of precision in the UVs or render window, such that pixel centers don’t fall exactly on texel centers. I suggested maybe the rescaling due to non-pow2… but it’s just a guess. Maybe a texel-centricity issue – off by a half pixel everywhere. This bug should be fixable, but you’re the one with the re-pro
Nja, the texture is not the exact same size as the window size (resolution), i.e. not same number of texels as pixels. The design resolution is 854x480 with fixed width (cocos will change the height so the design resolution match the ratio of the window). The window size used here is 1024x768, so the design resolution will end up being 854x641 (ratio is 1024/768 = ~1.33333333) and upscaling will occur from frustum view to screen view. Since RenderTexure is used by the transition effect and RenderTexture sets GL_NEAR as filtering, the issue occurs. I set GL_LINEAR on some of the texture atlases containing textures like logo, splash, splash logo since the game supports all resolutions from qvga (320x240 and related resolutions) up to wqxga (2560x1600) and even some above. We use 3 different graphics sizes for this and upscaling will occur in many situations and hence GL_LINEAR is needed to avoid the upscaling artifacts.
All textures used in both scenes are set to use GL_LINEAR filtering, however, during the transtion it looks like, at least for the next scene that it is faded to, that GL_NEAREST is used, you can see the difference very clearly in the BOXIT2 logo.