Specs 3.3 texture buildup

I have a functional texture containing font-data. Input format is RED and internal format is RGBA and *data fills the texture in one go, and it’s reflected in
glTexImage2D( .. params ..).
I contemplate changing this by leaving the *data to be 0 and then fill it up using glTexSubImage2D() with:

  1. the initial one-byte font-data
  2. pixels from the screen (RGBA) using glReadPixels()

here is a clip of the specs:

void TexSubImage2D( enum target, int level, int xoffset, int yoffset, sizei width, sizei height, enum format, enum type, const void *data );

Each of the TexSubImage commands interprets and processes pixelgroups in exactly the manner of its TexImage counterpart,except that the assignment of R, G, B, A, depth, and stencil index pixel group values to the texture components is controlled by the internalformat of the texel array, not by an argument to the command.

Likewise, TexSubImage2D arguments width, height, format, type, and data match the corresponding arguments to TexImage2D

The TexSubImage2D arg “type” will differ on the two calls to TexSubImage2D(…) … shall I expect this to be a problem?

Looking at the admissable types in the specs I’m not sure if I understand it. … is it the type of each component of the color/pixel?

No.

For scalar types it identifies the type of each component, i.e. the data for one pixel consists of N consecutive values of the specified type where N is the number of components. Packed types (e.g. GL_UNSIGNED_SHORT_5_6_5) describe the format of a complete pixel.

hi @GClements,
That leaves the question about format,
The first TexSubImage2D(..) call uses format = glRED
The next call that reads from the screen (glReadPixels()) will have to accept glRGBA as return. Writing that block of data suggests that I’ll have to use format glRGBA for the next write to TexSubImage2D (…) .
The ‘internal_format’ is RGBA, so the alignment is probably ok. The total size of the *data-contents may be 4 times too large though?

The external format doesn’t have to match the internal format. If you supply too few components, the missing components are set to 0.0 for green and blue and to 1.0 for alpha. If you supply too many, the additional components are discarded.

Thank you @GClements,

It would make sense. I’ll pop the code if I get something working.

Of all roads to Rome, this must be the easiest …
There aren’t any code to show:

allocate an appropriate data-pointer
bind your program-object (havn’t tried without)
bind the texture-object and it’s texture-unit (this is guessing, havn’t tried without)
draw the stuff you want to fix in the texture. Call
glReadBuffer(GL_BACK)
glReadPixels() with whatever pixel-format your using. Call
TexSubImage2D() … both calls using the data-pointer
… and you’r good.
It’s amateurish to use a client-side allocation, but the operation happens so fast that you do not see the intermediate frame that needs to be drawn.
There are some rectangles to clutter up tho ;o)
thanks again

Or use glCopyTexSubImage2D to copy directly from the read framebuffer to the texture.

Copying from the specs:

Texture Copying Feedback Loops
Calling CopyTexSubImage3D, CopyTexImage2D, CopyTexSubImage2D, CopyTexImage1D, or CopyTexSubImage1D will result in unde?ned behavior if the destination texture image level is also bound to to the selected read buffer (see section 4.3.1) of the read framebuffer. This situation is discussed in more detail in the description of feedback loops in section 4.4.3.

Whenever I’ve followed this kind of trail (objects and bindings) I’ve noted that version 3.3 is just a taste of what’s to come. Looking closer I eventually ends up in better info but younger versions. I noted something like CopyTexSubImage and CopyTextureSubImage … then it’s time to find an easier, less error-prone venue due to confusion.
… maybe I’m too suspicious of the opengl complexity

Now would be the proper time to test it …
To take a full aside: this copying to texture seems to open up for … just updating part of the screen … if the situation are for it. For now, my stuff is drowning in gui-stuff. Opening a pop-up for say a value-edit kind of screems: take a full snap-shot of the screen, put it into a texture and just use the same rect for drawing the screen while you work in the popup, drawn on top of it.
Even if my powerfull pc seems to be able to do this copying in a wiff, a slower one need not be a problem since starting an editor also is a kind of mental shift where a short natural pause happens anyway. One thing that seems likely: it could become a responsive editor ;o)

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.