Hosting and domain costs until October 2024 have been generously sponsored by dumptruck_ds. Thank you!
Difference between revisions of "EXT CSQC COPYTOTEXTURE"
From Quake Wiki
(New page: ===Extension Proposal=== Suggested extension for copying a portion of the screen to a texture in client side QuakeC. This will essentially be a wrapper for the OpenGL function ''glCopyTexI...) |
(→Extension Proposal) |
||
| Line 2: | Line 2: | ||
Suggested extension for copying a portion of the screen to a texture in client side QuakeC. This will essentially be a wrapper for the OpenGL function ''glCopyTexImage2D'' (http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/gl/copyteximage2d.html). | Suggested extension for copying a portion of the screen to a texture in client side QuakeC. This will essentially be a wrapper for the OpenGL function ''glCopyTexImage2D'' (http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/gl/copyteximage2d.html). | ||
| − | Builtin | + | Builtin functions: |
| + | <pre>string csqc_allocdynamictexture();</pre> | ||
| + | |||
| + | Allocates a dynamic texture, returns a string which can be used as any precached texture could be. | ||
| + | |||
<pre>vector csqc_copytotexture(float x, float y, float w, float h, string texture);</pre> | <pre>vector csqc_copytotexture(float x, float y, float w, float h, string texture);</pre> | ||
''x, y, w, and h'' specify the portion of the screen from which to copy pixels. They use the exact same coordinate space as ''R_SetView'' does for the view portal, were the top left of the screen is 0, 0, and the width and height are vid_conwidth and vid_conheight respectively. | ''x, y, w, and h'' specify the portion of the screen from which to copy pixels. They use the exact same coordinate space as ''R_SetView'' does for the view portal, were the top left of the screen is 0, 0, and the width and height are vid_conwidth and vid_conheight respectively. | ||
| − | ''texture'' specifies the name of the destination texture which will receive the new data. It | + | ''texture'' specifies the name of the destination texture which will receive the new data. It must have been allocated with ''csqc_alloctexture''. |
If the engine supports automatically precaching textures as soon as they are used, then the same should be implemented for this extension - the texture name will no longer need to have been precached with a dummy texture. | If the engine supports automatically precaching textures as soon as they are used, then the same should be implemented for this extension - the texture name will no longer need to have been precached with a dummy texture. | ||
Revision as of 13:21, 27 July 2008
Extension Proposal
Suggested extension for copying a portion of the screen to a texture in client side QuakeC. This will essentially be a wrapper for the OpenGL function glCopyTexImage2D (http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/gl/copyteximage2d.html).
Builtin functions:
string csqc_allocdynamictexture();
Allocates a dynamic texture, returns a string which can be used as any precached texture could be.
vector csqc_copytotexture(float x, float y, float w, float h, string texture);
x, y, w, and h specify the portion of the screen from which to copy pixels. They use the exact same coordinate space as R_SetView does for the view portal, were the top left of the screen is 0, 0, and the width and height are vid_conwidth and vid_conheight respectively.
texture specifies the name of the destination texture which will receive the new data. It must have been allocated with csqc_alloctexture.
If the engine supports automatically precaching textures as soon as they are used, then the same should be implemented for this extension - the texture name will no longer need to have been precached with a dummy texture.
glCopyTexImage2D requires that the destination texture have width and height be a power of two, though they don't have to be the same length. csqc_copytotexture should accept any width and height, and automatically use a larger texture. The vector returned is the s and t texture coordinates of the corner of the desired texture within the larger power-of-2 sided texture.
Possible Issues
glCopyTexImage2D copies pixels upside-down compared to quake's 2D coordinate system: Pixel ordering is such that lower x and y screen coordinates correspond to lower s and t texture coordinates.
This means that the texture coordinates will be upside down in QuakeC.
I think the desired image will be aligned to the top left of the texture, but upside down. (It might be aligned to the bottom, have to check).