Fixes some blending issues when using color arrays since we were
conflicting with the cogl_enable state + fixes a texture layer
validation bug.
Adds a basic textured triangle to test-vertex-buffer-contiguous.
- In cogl-material.h it directly sets the values of the
CoglMaterialLayerCombineFunc to some GL_* constants. However these
aren't defined in GLES 2 beacuse it has no fixed function texture
combining. Instead the CGL_* versions are now used. cogl-defines.h
now sets these to either the GL_* version if it is available,
otherwise it directly uses the number.
- Under GLES 2 cogl-material.c needs to access the CoglTexture struct
so it needs to include cogl-texture-private.h
- There are now #define's in cogl-gles2-wrapper.h to remap the GL
function names to the wrapper names. These are disabled in
cogl-gles2-wrapper.c by defining COGL_GLES2_WRAPPER_NO_REMAP.
- Added missing wrappers for glLoadMatrixf and glMaterialfv.
- Renamed the TexEnvf wrapper to TexEnvi because the latter is used
instead from the material API.
This glues CoglMaterial in as the fundamental way that Cogl describes how to
fill in geometry.
It adds cogl_set_source (), which is used to set the material which will be
used by all subsequent drawing functions
It adds cogl_set_source_texture as a convenience for setting up a default
material with a single texture layer, and cogl_set_source_color is now also
a convenience for setting up a material with a solid fill.
"drawing functions" include, cogl_rectangle, cogl_texture_rectangle,
cogl_texture_multiple_rectangles, cogl_texture_polygon (though the
cogl_texture_* funcs have been renamed; see below for details),
cogl_path_fill/stroke and cogl_vertex_buffer_draw*.
cogl_texture_rectangle, cogl_texture_multiple_rectangles and
cogl_texture_polygon no longer take a texture handle; instead the current
source material is referenced. The functions have also been renamed to:
cogl_rectangle_with_texture_coords, cogl_rectangles_with_texture_coords
and cogl_polygon respectivly.
Most code that previously did:
cogl_texture_rectangle (tex_handle, x, y,...);
needs to be changed to now do:
cogl_set_source_texture (tex_handle);
cogl_rectangle_with_texture_coords (x, y,....);
In the less likely case where you were blending your source texture with a color
like:
cogl_set_source_color4ub (r,g,b,a); /* where r,g,b,a isn't just white */
cogl_texture_rectangle (tex_handle, x, y,...);
you will need your own material to do that:
mat = cogl_material_new ();
cogl_material_set_color4ub (r,g,b,a);
cogl_material_set_layer (mat, 0, tex_handle));
cogl_set_source_material (mat);
Code that uses the texture coordinates, 0, 0, 1, 1 don't need to use
cog_rectangle_with_texure_coords since these are the coordinates that
cogl_rectangle will use.
For cogl_texture_polygon; as well as dropping the texture handle, the
n_vertices and vertices arguments were transposed for consistency. So
code previously written as:
cogl_texture_polygon (tex_handle, 3, verts, TRUE);
need to be written as:
cogl_set_source_texture (tex_handle);
cogl_polygon (verts, 3, TRUE);
All of the unit tests have been updated to now use the material API and
test-cogl-material has been renamed to test-cogl-multitexture since any
textured quad is now technically a test of CoglMaterial but this test
specifically creates a material with multiple texture layers.
Note: The GLES backend has not been updated yet; that will be done in a
following commit.
This better reflects the fact that the api manages sets of vertex attributes,
and the attributes really have no implied form. It is only when you use the
attributes to draw that they become mesh like; when you specify how they should
be interpreted, e.g. as triangle lists or fans etc. This rename frees up the
term "mesh", which can later be applied to a concept slightly more fitting.
E.g. at some point it would be nice to have a higher level abstraction that
sits on top of cogl vertex buffers that adds the concept of faces. (Somthing
like Blender's mesh objects.) There have also been some discussions over
particle engines, and these can be defined in terms of emitter faces; so some
other kind of mesh abstraction might be usefull here.
