PDA

View Full Version : Problems copying screen with glCopyTexImage2D



PP2005
06-30-2009, 05:42 AM
I'm working on a 2D game and am using OpenGL to draw the screen from sprites converted into textures. Everything works fine, except that it takes quite a lot of time to draw the entire screen every refresh as I'm drawing a bunch of textured quads (I'm mimicking a 80x50 console output, so am drawing 4000 quads - one for each "character" on the "console"). I want to employ dirty rectangles and only redraw the parts of the screen that have changed. I figured I could just use glCopyTexImage2D to copy the screen into a few power of 2 textures, but I just can't get it to work. Here's a code snippet:



// Getting the pixels from the upper left 512x512 part of the screen:
glReadBuffer(GL_Front);
glBindTexture(GL_TEXTURE_2D, ScreenTextureID[1, 1]);
glCopyTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, 0, 0, 512, 512, 0);

// Clear the screen:
glClear(GL_COLOR_BUFFER_BIT);

// Drawing the saved screen texture back to the screen:
glBindTexture(GL_TEXTURE_2D, ScreenTextureID[1, 1]);
glBegin(GL_QUADS);
glTexCoord2f(0, 0);
glVertex3f(0, 0, 0.0);
glTexCoord2f(1, 0);
glVertex3f(512, 0, 0);
glTexCoord2f(1, 1);
glVertex3f(512, 512, 0);
glTexCoord2f(0, 1);
glVertex3f(0, 512, 0);
glEnd();


This just draws a flickering image with some parts of the correct image mirrored and drawn twice. I've tried drawing another image and that works fine, so the error seems to be in the part of my code that saves the screen pixel information into the texture, not in the part that draws it back.

BionicBytes
06-30-2009, 06:51 AM
why switch to the front buffer? This will usually contain the previous frames contents and not what you have drawn this frame (which is in the back buffer). I don't know what you have setup (double buffering) or perhaps this is what you are trying to acheive?

For performance you could use glCopyTexSubImage2D as this avoids converting data formats for each texture upload.

Finally, you have not shown that you have set a suitable projection matrix and setup the viewport with the correct w and h. If you don't do this you may get garbage in your textures.

Dark Photon
06-30-2009, 06:55 AM
glReadBuffer(GL_Front);
glBindTexture(GL_TEXTURE_2D, ScreenTextureID[1, 1]);
glCopyTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, 0, 0, 512, 512, 0);
...
If you're double buffering, you're most likely going to want to be reading the back buffer (GL_BACK) if you're calling this before SwapBuffers. Also be aware that glCopyTexImage2D allocates the MIP and copies pixels, while glCopyTexSubImage2D only copies the pixels. For best perf, you probably want the latter. To preallocate the texture MIPs, call glTexImage2D with a NULL pointer for the data.

PP2005
06-30-2009, 08:13 AM
I have set up the projection matrix and everything else in the initialization of my program. Like I said, everything else works perfectly and draws to the screen like it's supposed to - I'm just having trouble with saving the contents of the screen and redrawing it for use with my dirty rectangles approach.

What I want to do is save the contents of the previous frame (i.e. what's currently on the screen) before I clear it to draw the next frame. I only want to refresh the parts that have changed, but that means I have to save the parts of the screen that haven't changed and redraw them. That's why I'm saving the contents of the screen and drawing it to the back buffer before before drawing the changes to the new frame to the back buffer.

I tried switching to glCopyTexSubImage2D, which gave a bit of progress. Instead of a garbled image I'm now getting a white box on the 512x512 upper left part of the screen that I'm saving and redrawing.

EDIT: I was passing incorrect parameters when switching to glCopyTexSubImage2D. With the correct parameters I'm getting the same result: garbled image.

EDIT 2: Here's an image of the resulting screen.

http://img3.imageshack.us/img3/4673/81064332.th.png (http://www.postimage.org/image.php?v=Pqasrb0)

And what it looks like when I remove the dirty rectangles stuff I'm trying to do and just render all 4000 quads:

http://img43.imageshack.us/img43/6891/12578728.th.png (http://www.postimage.org/image.php?v=aV1QshJA)

BionicBytes
07-01-2009, 03:05 AM
What I want to do is save the contents of the previous frame (i.e. what's currently on the screen) before I clear it to draw the next frame. I only want to refresh the parts that have changed, but that means I have to save the parts of the screen that haven't changed and redraw them. That's why I'm saving the contents of the screen and drawing it to the back buffer before before drawing the changes to the new frame to the back buffer.


Can you be clearer with what you are doing?
Are you either:
a) Copying the entire screen (back buffer) to a texture, or
b) Copying various portions of the screen to various textures?

I suspect you mean a) - copy the entire screen, in which case this should be very straight forward.
Directly after you have drawn the scene to the back buffer, simply bind your texture and call glCopyTexSubImage2D (GL_TEXTURE2D,0,0,0,0,0, Tex_w, Tex_h). No need to switch to front buffer or anything like that. For this to work, the texture size must match the screen size (viewport dimensions) otherwise you are going to get strange results. If your screen is set to the main GL rendering context (system default window) then that is usually some non-power of two dimension, eg 1024 * 768. Therefore you need to ensure you can support NPOT textures (OpenGL 2.0 or EXT_Non_Power_ofTwo) and you have sized the textures accordingly.
I have a feeling you are trying to capture the 'screen' into a small texture (512 * 512) but have not resized the viewport to the texture dimensions.

_NK47
07-01-2009, 03:25 AM
"For this to work, the texture size must match the screen size"
not really essential. important is that the texture (if NPOT not supported) is bigger then the backbuffer. you will need to adjust texture coordinates < 1.0f in ST directions to draw it correctly. recommend NPOT textures though to not waste any vram.

PP2005
07-01-2009, 03:36 AM
I'm not saving the entire screen into a power of two texture. I'm trying to save parts of the screen into multiple textures. But right now all I'm trying to do is save the (0,0,512,512) part of the screen into a 512x512 texture. If I can get that to work, it'll just be a matter of copying that code for the remaining screen.

Here's what I want to do in my "draw the screen" procedure:

1) Save the contents on the screen (the last frame) to textures.
2) Clear the screen.
3) Redraw the screen saved in 1).
4) Draw the parts of the screen that have changed since the last frame.

Like I said, I'm emulating a 80x50 console and don't want to draw 4000 quads every refresh. So saving the last frame and redrawing it, and then just redrawing the quads that have changed will save a lot of time, as I will only have to draw the 4 or so 512x512 textures that make up the last frame and then the ~100 quads that have changed.

I've used SDL for drawing the screen in the past, and it wasn't a problem at all to use dirty rectangles with that, as the screen is just a surface (texture) like any other, so you could just draw the changes to that surface and blit it to the screen. With double buffered OpenGL, I lose the contents of my screen "surface" when swapping buffers, so I can't just draw the changed quads, as everything else would be lost.

def
07-01-2009, 04:08 AM
Use glCopyTexSubImage2D() just before your glSwapBuffers() in the previous frame and use the copied texture in the current frame as background.
Usually the content of the "non-rendering" buffer will become undefined (implementation specific) after the swap.

BionicBytes
07-01-2009, 04:41 AM
Here's what I want to do in my "draw the screen" procedure:

1) Save the contents on the screen (the last frame) to textures.
2) Clear the screen.
3) Redraw the screen saved in 1).
4) Draw the parts of the screen that have changed since the last frame.


If this "draw the screen" procedure is really a single procedure/function call then how are steps 1-3 any different that just step 1 ? I.e. you draw to the screen, clear it and then redraw exactly what you had before.

For what you are trying to achive (take a copy of the back buffer) you need to drop step 1 from the draw procedure and perform the copy at the end of the render loop (or just before the swap buffers - same thing really). The point here is you can't do it before the render loop has begun because you'll have lost the previous frame's contents during the swap buffers process.

PP2005
07-01-2009, 05:01 AM
Use glCopyTexSubImage2D() just before your glSwapBuffers() in the previous frame and use the copied texture in the current frame as background.
Usually the content of the "non-rendering" buffer will become undefined (implementation specific) after the swap.


I tried that and it gives the exact same result.

PP2005
07-01-2009, 05:05 AM
If this "draw the screen" procedure is really a single procedure/function call then how are steps 1-3 any different that just step 1 ? I.e. you draw to the screen, clear it and then redraw exactly what you had before.

For what you are trying to achive (take a copy of the back buffer) you need to drop step 1 from the draw procedure and perform the copy at the end of the render loop (or just before the swap buffers - same thing really). The point here is you can't do it before the render loop has begun because you'll have lost the previous frame's contents during the swap buffers process.


I'm not trying to save the back buffer. I'm trying to save the front buffer and copy it to the back buffer. The front buffer is what's currently on the screen, right?

So what I'm trying to do is:

1) Save the front buffer.
2) Copy it to the back buffer.
3) Draw all the quads that have changed to the back buffer.
4) Swap buffer, so what will be drawn is the last frame along with all the stuff that has changed for the current frame.

BionicBytes
07-01-2009, 05:22 AM
Unless you have done some setup that's different to the norm, then this not what usually happens.
GL implementations actually don't like the application drawing to the front buffer directly as it messes up all sorts of driver optimisations. Instead, application draw to the back buffer. During the swapbuffers operaton, the back becomes the front and that is blitted to the screen. Therefore, as far as you are concerned, you are only ever drawing to the back buffer and forget the front ever existed. If you want another surface to draw to, then you need to use an offscreen surface (pbuffer or FrameBuffer).
Therefore, to save what you have drawn this frame, right after you have finished with the draw routine, set the viewport dimensions to the texture width/height, bind the texture and call glCopyTexSubImage.

On some implemnetations, after swap buffers, the contents of the front buffer may be undefined - so this technique is flawed from the start.

PP2005
07-01-2009, 05:34 AM
GL implementations actually don't like the application drawing to the front buffer directly as it messes up all sorts of driver optimisations.

When did I ever say I'm trying to draw to the front buffer? Like I've said a bunch of times now, I'm trying to copy the front buffer to the back buffer!

BionicBytes
07-01-2009, 05:50 AM
...and what do you think is in the front buffer? Usually (depending on your setup - perhaps you should post that) you have been drawing to the back buffer. GL then swaps this to the front buffer automatically. You are trying to fight the system by copying the front buffer to the back buffer.
If all you want is a copy of the current frame, then copy the back buffer to a texture - this is guaranteed to work.

PP2005
07-01-2009, 06:01 AM
What I think is in the front buffer is the last frame that was drawn.

I'm not "fighting the system" by copying the front buffer to the back buffer. After copying the front buffer to the back buffer I then draw the stuff that has changed, i.e. the dirty rectangles.

And I've already tried copying the back buffer to a texture before the glswap. Another guy suggested this only a few posts ago and I responded that it gives the same result: garbled image. And this wouldn't do what I want anyway, as all that would be in the back buffer are the quads that have changed since the last frame.

BionicBytes
07-01-2009, 06:12 AM
I'm sure there are 1000's of us who copy the back buffer to a texture on a regular basis - so this does work. In my render engine, as a matter of routine, if the GL client does not support FrameBufferObjects I fall back to glCopyTexSubImage2D. Therefore the garbage you are getting is a result of something else - not the copying of the back buffer to a texture.

Perhaps you can try giving a bit more detail to the process you are doing because I can't see why you need to copy front to back buffer when the system has already copied back buffer to front for you. Can you explain what you mean by the dirty rectangles a bit more?

PP2005
07-01-2009, 06:24 AM
I've already explained it 4-5 times. I don't know how else to explain it, but I'll try again...

My program emulates a 80x50 console. That's 4000 characters (80x50). In the case of OpenGL, 4000 quads that need to be drawn each frame, as I'm drawing each character as a separate quad. That takes a long time. What I want to do (and what I've been doing for 2 years with SDL) is only having to draw those of the 4000 quads that have changed since the last frame (I keep track of this in my code). If I only draw the quads that have changed to the back buffer, all the quads that haven't changed won't be drawn, as the back buffer has been cleared since the last frame. That's why I first want to draw the contents of the screen (the last frame) to the back buffer and THEN draw those of the 4000 quads that have changed.

_NK47
07-01-2009, 06:26 AM
try giving your texture trash data before using or simply glTexImage2D(......,NULL);

PP2005
07-01-2009, 06:39 AM
try giving your texture trash data before using or simply glTexImage2D(......,NULL);

I'm initializing the textures for saving the screen like this in the beginning of my program. Am I perhaps doing something wrong here?



FOR I := 1 TO 5 DO BEGIN
FOR J := 1 TO 4 DO BEGIN
glGenTextures(1, @ScreenTextureID[I, J]);
glBindTexture(GL_TEXTURE_2D, ScreenTextureID[I, J]);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexImage2D(GL_TEXTURE_2D, 0, 4, 512, 512, 0, GL_RGBA, GL_UNSIGNED_BYTE, NIL);
END;
END;


(That's Pascal code, by the way.)

ZbuffeR
07-01-2009, 06:45 AM
0) create a texture (refered later to textureA) to hold the whole framebuffer, no need to fill it now, as said AK47.
1) draw all quads normally
2) glCopyTexSubImage the whole viewport to textureA
3) swapbuffers
4) -- new frame:
5) render large quad with textureA
6) redraw the parts that have changed
7) GOTO 2)

As others said, never mess with the frontbuffer, it does not even exists on composited desktops.

Now, at which step do you still have a problem ?

_NK47
07-01-2009, 06:46 AM
well if you GL_RGBA the texture and glCopy with GL_RGB? not good.

BionicBytes
07-01-2009, 07:00 AM
Nothing wrong with your texture generation on the whole (although the use of 4 as the internal format should be GL_RGBA8). Does not make a difference though.

I now have a better picture of what you are trying to achive with your last description. much appreciated.

There really is no need to copy front buffer to back....

in your draw routine do the following: (using the standard back buffer)

1. Bind copytexture
2. draw full screen quad
3. Draw all 'dirty' quads
4. copy backbuffer to texture
5. perform GL swapbuffer

Notes:
1. Copytexture is the texture you use to 'capture' the back buffer as suggested before (step 4 below)
2. No need to clear screen (depth buffer or color buffer) as the full screen quad will erase the contents of the back buffer anyway. I assume depth testing is disabled as your console emulator is 2D.
3. Update screen with new contents
4. Capture screen ready for the start of the new frame.


So you see, there is no need to use front buffer. As long as the texture has the same dimensions as the GL window (back buffer) then the subcopy will copy everything correctly to the currently bound texture. Try and ensure your code sets the main GL window and capture texture dimensions to the same value (eg 512*512).

PP2005
07-01-2009, 07:31 AM
Okay, so now I just ignore the front buffer and get the frame from the back buffer. That makes sense. However, I still can't get it to display properly. Here's my draw screen procedure:



// Draw the last frame:
glBindTexture(GL_TEXTURE_2D, ScreenTextureID[1, 1]);
glBegin(GL_QUADS);
glTexCoord2f(0, 0);
glVertex3f(0, 0, 0.0);
glTexCoord2f(1, 0);
glVertex3f(512, 0, 0);
glTexCoord2f(1, 1);
glVertex3f(512, 512, 0);
glTexCoord2f(0, 1);
glVertex3f(0, 512, 0);
glEnd();

// Draw the quads that have changed:
FOR X := 0 TO 79 DO BEGIN
FOR Y := 0 TO 49 DO BEGIN
IF (ScreenBuffer[X, Y].Color <> OldScreenBuffer[X, Y].Color)
OR (ScreenBuffer[X, Y].Character <> OldScreenBuffer[X, Y].Character)
THEN DrawDirectlyToScreen(X, Y, ScreenBuffer[X, Y].Color, ScreenBuffer[X, Y].Character);
END;
END;

// Save the frame to texture:
glViewPort(0, 0, 512, 512);
glReadBuffer(GL_BACK);
glBindTexture(GL_TEXTURE_2D, ScreenTextureID[1, 1]);
glCopyTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 0, 0, 512, 512);
glViewPort(0, 0, 960, 600);

SDL_GL_SwapBuffers();

// Update dirty rectangles info:
FOR X := 0 TO 79 DO BEGIN
FOR Y := 0 TO 49 DO BEGIN
OldScreenBuffer[X, Y].Character := ScreenBuffer[X, Y].Character;
OldScreenBuffer[X, Y].Color := ScreenBuffer[X, Y].Color;
END;
END;


This is the result:

http://img269.imageshack.us/img269/5166/53594917.th.png (http://www.postimage.org/image.php?v=gxZNL1S)

If I clear the screen to get rid of the garbled stuff (as I'm only doing this on the (0,0,512,512) part of the screen), this is what I get:

http://img188.imageshack.us/img188/5548/46283571.th.png (http://www.postimage.org/image.php?v=aV1VqRQ0)

It's odd that the texture doesn't seem to fill from the upper left corner... :confused:

EDIT: And why is part of it mirrored horizontally?

BionicBytes
07-01-2009, 08:09 AM
Don't forget that GL uses lower left as the origin (0,0).

I have not seen the projection matrix when you use for rendering.

At the start of your draw routine, use this:

//draw the last frame
glviewport (0,0,900,600);
glMatrixMode (GL_PROJECTION);
glLoadIdentity();
glOrtho(0,900,0,600,0,100);
glMatrixMode (GL_MODELVIEW);
glLoadIdentity();


Also, have you tried setting the capturetexture dimension to 900 * 600? That way both the texture and backbuffer have the same dimensions so there is no possiblity of wrapping horizontal lines.

PP2005
07-01-2009, 08:21 AM
Here's how I set up GL in the initialization part of my program:



glEnable(GL_TEXTURE_2D);
glClearColor(0.0, 0.0, 0.0, 0.0);
glViewport(0, 0, ResolutionWidth, ResolutionHeight);
glClear(GL_COLOR_BUFFER_BIT);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glOrtho(0.0, ResolutionWidth, ResolutionHeight, 0.0, -1.0, 1.0);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);


For all other texture drawing, the origin is upper left and works fine.

And wouldn't setting the texture to 960x600 possibly cause problems as it's not a power of 2?

_NK47
07-01-2009, 08:46 AM
your projection seems fine. also it should go to upper-left if you use it like you do already, glOrtho(0.0, ResolutionWidth, ResolutionHeight, 0.0, -1.0, 1.0);
the flip, any change you use some glScalef(-1) before rendering the quad or you simply provide wrong texture coordinates.

"And wouldn't setting the texture to 960x600 possibly cause problems as it's not a power of 2?"
it should be your window dimension. i.e. 1024x768 to map 1:1.

PP2005
07-01-2009, 08:51 AM
your projection seems fine. also it should go to upper-left if you use it like you do already, glOrtho(0.0, ResolutionWidth, ResolutionHeight, 0.0, -1.0, 1.0);
the flip, any change you use some glScalef(-1) before rendering the quad or you simply provide wrong texture coordinates.

No glScalef. All the code is there in my previous post.


"And wouldn't setting the texture to 960x600 possibly cause problems as it's not a power of 2?"
it should be your window dimension. i.e. 1024x768 to map 1:1.

My window dimension is 960x600 when not fullscreen, but shouldn't what I'm doing work anyway: setting glviewport and copying the upper left 512x512 part of the screen into a 512x512 texture?

_NK47
07-01-2009, 08:57 AM
or you simply provide wrong texture coordinates.

"but shouldn't what I'm doing work anyway"
viewport is the 2d area you will actually see. making it smaller will rasterize smaller image and vice versa. by setting it to your window size you will get 1:1 mapping otherwise a resize. i would recommend to stick to OpenGL default origin (lower-left) because many calls operate on that (glScissor, glCopy). should.

PP2005
07-01-2009, 09:14 AM
or you simply provide wrong texture coordinates.
Like I said, I posted all the code in my previous post. Can you see if I am providing wrong texture coordinates there?


"but shouldn't what I'm doing work anyway"
viewport is the 2d area you will actually see. making it smaller will rasterize smaller image and vice versa. by setting it to your window size you will get 1:1 mapping otherwise a resize. i would recommend to stick to OpenGL default origin (lower-left) because many calls operate on that (glScissor, glCopy). should.
I'm not sure I understand. Are you telling me that I can't copy part of the viewscreen to a texture because using glviewport will just "shrink" the viewport size instead of limiting it to the part I want to copy?

And changing to the default lower left origin means I'll have to change all my other code. Can't I just do something to the glCopyTexSubImage2D call to make it work with the upper left origin?

_NK47
07-01-2009, 09:19 AM
"Like I said, I posted all the code in my previous post. Can you see if I am providing wrong texture coordinates there?"
no, because projection setup is totally unrelated! where is your drawing code of the quads?

"I'm not sure I understand. Are you telling me that I can't copy part of the viewscreen to a texture because using glviewport will just "shrink" the viewport size instead of limiting it to the part I want to copy?"
you can copy whatever is inside your backbuffer. when you draw it (glBegin() glEnd() / glDrawElemets / whatever) it will make a difference. either or just leave the parameters on glViewport and glOrtho to your screen size.

"And changing to the default lower left origin means I'll have to change all my other code. Can't I just do something to the glCopyTexSubImage2D call to make it work with the upper left origin?"
you can adjust the y coordinate. y - screenHeight to flip it.

def
07-01-2009, 09:26 AM
What GL_Version are you using?
Specifying a null pointer at texture creation only works for version 1.1 and up.
I'm guessing, but the garbled texture would indicate something like this.

Does it help to pass a 512x512x4 byte array when setting up the textures?

PP2005
07-01-2009, 09:32 AM
"Like I said, I posted all the code in my previous post. Can you see if I am providing wrong texture coordinates there?"
no, because projection setup is totally unrelated! where is your drawing code of the quads?
It's in post #259899, two posts above the one you're looking at.


"I'm not sure I understand. Are you telling me that I can't copy part of the viewscreen to a texture because using glviewport will just "shrink" the viewport size instead of limiting it to the part I want to copy?"
you can copy whatever is inside your backbuffer. when you draw it (glBegin() glEnd() / glDrawElemets / whatever) it will make a difference. either or just leave the parameters on glViewport and glOrtho to your screen size.
So I don't need to alter glviewport? Why was I then previously told to set glviewport to the size of the texture to copy to and then reset it to the screen size after copying?


"And changing to the default lower left origin means I'll have to change all my other code. Can't I just do something to the glCopyTexSubImage2D call to make it work with the upper left origin?"
you can adjust the y coordinate. y - screenHeight to flip it.
Okay, so if it would be glCopyTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 0, 512, 512, 512) with lower left origin it will be glCopyTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 0, 512 - 600, 512, 512) with upper left origin? Then I get a negative y value...?

_NK47
07-01-2009, 09:33 AM
i hope this helps:
http://www.lighthouse3d.com/opengl/glut/index.php?bmpfontortho

they use gluOrtho for orthographic projection, it is same as glOrtho(0.0,w,h,0.0,-1.0,+1.0); also they use glScalef(1,-1,1) to reflect the origin.

my bad on y - screenHeight;
say screenHeight = 800; y = 0;
y in lower left will be 800 - 0 = 800 in upper left copied what you need to copy (now y axis is pointing down).

PP2005
07-01-2009, 09:40 AM
What GL_Version are you using?
Specifying a null pointer at texture creation only works for version 1.1 and up.
I'm guessing, but the garbled texture would indicate something like this.

Does it help to pass a 512x512x4 byte array when setting up the textures?
I'm using "1.5.0 - Build 6.14.10.4814".

The texture isn't garbled when I clear the screen. The garbled stuff is just the part of the screen that doesn't get drawn, since I'm only trying to get it to work on the upper left 512x512 part of the screen at the moment. And the texture gets filled with data the first time I run the update screen loop anyway, so that shouldn't be a problem, should it?

PP2005
07-01-2009, 09:47 AM
my bad on y - screenHeight;
say screenHeight = 800; y = 0;
y in lower left will be 800 - 0 = 800 in upper left copied what you need to copy (now y axis is pointing down).

Okay, using Height - y (which is 600 - 512 in my code) results in this:

http://img11.imageshack.us/img11/8183/64911262.th.png (http://www.postimage.org/image.php?v=aV1W7kBS)

It's a bit better as it's defintely filling the upper left 512x512 part now...

def
07-01-2009, 10:28 AM
I'm using "1.5.0 - Build 6.14.10.4814".

That sounds ancient!

What hardware/plattform/drivers are we talking about here anyway?

Have you tried a simple app with glCopyTexSubImage2D() ?

It still looks to me as if someone is poking around in texture memory...

PP2005
07-01-2009, 10:31 AM
I think I figured it out. I just had to pass the texture from bottom to top when drawing it as well. Seems to work now. :)

def
07-01-2009, 10:36 AM
Hmmm, that doesn't explain mirroring, wrong colors and pixels, though...

PP2005
07-01-2009, 11:01 AM
No, it seems there was still some problem with the data in the textures when initialized with NULL. I just copied a completely black image to the textures.