Blitting between 2D textures?

I’m trying to create a 2D texture that is updated every frame.

The texture is fairly large (1024x1024) and is composed of a number of smaller cells, each 8x8. The cells can only have a limited number of contents (say up to 256 different values)

To create the texture my loop goes something like this :

// generate the map (each entry is a tile number)
unsigned char map[][]=generate_map(frame_number);

// copy the tiles to the texture
for (x=0;x<(1024/8);x++) {
     for (y=0;y<(1024/8);y++) {
        copytile(texture,x,y,map[x][y])  // copy the tile to the texture
     }
}

My problem at the moment is trying to find the quickest way to implement the copytile function.

I guess the simplest way is to use memcpy to construct the data in system memory, then upload it to video memory with glTexImage2D, but this seems like a lot of extra shuffling of data.

Is it possible to store the tiles in video memory (ie, as a seperate packed texture) and then blit it to the already existing texture?

I have seen people using textured quads but in my case there would be 16384 of them and i’m guessing the time taken to bind the textures would be excessive.

Any ideas would be appreciated!

Use glTexSubImage2D .

If each cell only can take predefined content (256 different bitmaps) why don’t you just use a fixed texture map for the content (the 256x8x8 texture can be stored in a 128x128 texture), and update an cell index texture each fame. You can the use a shader to reconstruct the texture. This way you only need to update a (1024/8) x (1024/8) = 128 x 128 cell index texture each frame (16KB/frame).

– Niels

You can even reconstruct the 1024 x 1024 texture in a separate pass by using an FBO.

Thanks for the replies!

With regard to using FBOs or glTexSubImage2D, my impression is that they both copy data from system memory to video memory, is this correct?

If so, is there a significant speed penalty copying from system->video versus video->video?