Difference between revisions of "Texture Manager and OpenGLGraphic description"

From LinuxMCE
Jump to: navigation, search
 
m (beautification)
 
(6 intermediate revisions by 4 users not shown)
Line 1: Line 1:
<table width="100%"> <tr><td bgcolor="#FFCFCF">This page was written by Pluto and imported with their permission when LinuxMCE branched off in February, 2007.  In general any information should apply to LinuxMCE.  However, this page should be edited to reflect changes to LinuxMCE and remove old references to Pluto.</td></tr> </table>TextureManager class
+
{{versioninfo}}
 +
TextureManager class
  
 
Texturing mechanism in OpenGL is next:
 
Texturing mechanism in OpenGL is next:
- read the data in a buffer where you know the format (for instance RGB or RGBA)
+
* read the data in a buffer where you know the format (for instance RGB or RGBA)
- convert it from pixel surface to a texture
+
* convert it from pixel surface to a texture
- get an index that may be used to "paint the geometry" using glEnable(GL_TEXTURE_2D) call using different parameters, as current color, transparency, etc.
+
* get an index that may be used to "paint the geometry" using glEnable(GL_TEXTURE_2D) call using different parameters, as current color, transparency, etc.
 +
 
  
 
Restrictions of OpenGL implementation:
 
Restrictions of OpenGL implementation:
- OpenGL should be implemented in it's own thread, else the convert textures will not appear to the drawing. The conclusion is simple,
+
* OpenGL should be implemented in it's own thread, else the convert textures will not appear to the drawing.  
- the textures should be sized as power of two, etc. and the scalling may take time to complete
+
* the textures should be sized as power of two, etc. and the scaling may take time to complete
 +
 
 +
The conclusion is simple,
  
 
The flow is next:
 
The flow is next:
- OpenGLEngine creates an TextureManager
+
* OpenGLEngine creates an TextureManager
- at every frame at start we should  
+
* at every frame at start we should  
  
 
Manages multiple graphics and geometry lists:
 
Manages multiple graphics and geometry lists:
- texture for pending
+
 
std::list <OpenGLGraphic*> WaitForConvert;
+
* textures for pending for convert
std::list <OpenGLTexture> WaitForRelease;
+
std::list <OpenGLGraphic*> WaitForConvert;
std::map<std::string, MeshFrame*> Graphics;
+
* texture indexes which needs to be removed
 +
std::list <OpenGLTexture> WaitForRelease;
 +
* Geometry cache, it keeps all geometry with uniques IDs. It can be used for store local objects.
 +
std::map<std::string, MeshFrame*> Graphics;
 +
[[Category: Programmer's Guide]]

Latest revision as of 20:55, 17 May 2010

Version Status Date Updated Updated By
710 Unknown N/A N/A
810 Unknown N/A N/A
1004 Unknown N/A N/A
1204 Unknown N/A N/A
1404 Unknown N/A N/A
Usage Information

TextureManager class

Texturing mechanism in OpenGL is next:

  • read the data in a buffer where you know the format (for instance RGB or RGBA)
  • convert it from pixel surface to a texture
  • get an index that may be used to "paint the geometry" using glEnable(GL_TEXTURE_2D) call using different parameters, as current color, transparency, etc.


Restrictions of OpenGL implementation:

  • OpenGL should be implemented in it's own thread, else the convert textures will not appear to the drawing.
  • the textures should be sized as power of two, etc. and the scaling may take time to complete

The conclusion is simple,

The flow is next:

  • OpenGLEngine creates an TextureManager
  • at every frame at start we should

Manages multiple graphics and geometry lists:

  • textures for pending for convert
std::list <OpenGLGraphic*> WaitForConvert;
  • texture indexes which needs to be removed
std::list <OpenGLTexture> WaitForRelease;
  • Geometry cache, it keeps all geometry with uniques IDs. It can be used for store local objects.
std::map<std::string, MeshFrame*> Graphics;