Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

glTexSubImage2D not updating texture as expected #4

Closed
diamond-msc opened this issue Jan 19, 2014 · 12 comments
Closed

glTexSubImage2D not updating texture as expected #4

diamond-msc opened this issue Jan 19, 2014 · 12 comments
Labels

Comments

@diamond-msc
Copy link

Calling glTexSubImage2D doesn't always add to the existing texture data.
With double buffering, e. g. calling from a cococ2d-x update, glTexSubImage2D appears to write to some kind of texture back buffer.
This texture back buffer is initially empty, and becomes visible on the next global buffer flip after the glTexSubImage2D call.

The result, when displayed, is an empty texture with only the subimage set. (Tested with CCTexture2D::drawAtPoint).

It should be the current texture plus the given subimage data.

@diamond-msc
Copy link
Author

The texture back buffer may be the cause for https://github.com/MSOpenTech/cocos2d-x/issues/28

@pwang08
Copy link

pwang08 commented Feb 13, 2014

The angle project is developed and maintained by google, I have read the reference of angle, it looks as if the texture back buffer is caused by the difference of the way in which opengl and directx store the texutures.

@diamond-msc
Copy link
Author

I tested glTexSubImage2D on Win32 with a modified Simple_Texture2D sample from gles2_book.
It works properly there.
That's why I assume it's a bug in the WinRT port. But I'm not sure since the gles2_book samples aren't part of the WinRT solution.

@stammen
Copy link
Member

stammen commented Feb 15, 2014

Thanks for the updates. We will be looking at why glTexSubImage2D is broken in the WinRT/WP8 versions.

@JingxuOuyang
Copy link

It may be cause by the 'updateSubresourceLevel' function in TextureStorage11.cpp line 166. The data in texture is cleared by 'mTexture->release'?

@hujian
Copy link

hujian commented May 4, 2014

Has anybody made any progress on this question?

@yihuang
Copy link

yihuang commented Jul 28, 2014

We've met the same problem, is there any progress on this, or is there work around for this?

@ghost ghost added the bug label Sep 17, 2014
@steven-chith
Copy link
Contributor

I'm not able to repo this. Would you be able to put up some sample code for us to verify?

@diamond-msc
Copy link
Author

https://gist.github.com/diamond-msc/7167ba71776e48cdb150

took the cube renderer and replaced GL stuff with Simple_Texture2D sample.
(Base is fd780fc on winrt branch)

Expected: Only the top left one of the 4 texture pixels changes color.
Actual: The other 3 pixels also change color (they alternate to/from black).

@steven-chith
Copy link
Contributor

Looks like it only works when the texture is RGBA instead of RGB on both internal format and passed in format. Will investigate why. If you need to get it done quickly just convert to RGBA for the time being.

@stammen
Copy link
Member

stammen commented Sep 30, 2014

For now add glPixelStorei(GL_UNPACK_ALIGNMENT, 1) before the call to glTexSubImage2D. We are investigating why the glPixelStorei state is not staying set.

void CubeRenderer::Update(float timeTotal, float timeDelta)
{
pixels[2] = rand() % 2 * 255;
glBindTexture(GL_TEXTURE_2D, textureId);
glPixelStorei(GL_UNPACK_ALIGNMENT, 1);
glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 1, 1, GL_RGB, GL_UNSIGNED_BYTE, pixels);
// expected: only the top left color flickers red/purple
}

@steven-chith
Copy link
Contributor

This is fixed in the winrt-es3proto branch. We'll merge these changes over to the winrt branch soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

7 participants