2009-04-27 10:48:12 -04:00
|
|
|
/*
|
|
|
|
* Cogl
|
|
|
|
*
|
|
|
|
* An object oriented GL/GLES Abstraction/Utility Layer
|
|
|
|
*
|
|
|
|
* Copyright (C) 2007,2008,2009 Intel Corporation.
|
|
|
|
*
|
|
|
|
* This library is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
* version 2 of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This library is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* Lesser General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
2010-03-01 07:56:10 -05:00
|
|
|
* License along with this library. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
*
|
|
|
|
*
|
2009-04-27 10:48:12 -04:00
|
|
|
*/
|
|
|
|
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
#if !defined(__COGL_H_INSIDE__) && !defined(CLUTTER_COMPILATION)
|
|
|
|
#error "Only <cogl/cogl.h> can be included directly."
|
|
|
|
#endif
|
|
|
|
|
2010-10-27 13:54:57 -04:00
|
|
|
#ifndef __COGL_PIPELINE_H__
|
|
|
|
#define __COGL_PIPELINE_H__
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
|
|
|
|
G_BEGIN_DECLS
|
|
|
|
|
|
|
|
#include <cogl/cogl-types.h>
|
|
|
|
#include <cogl/cogl-matrix.h>
|
|
|
|
|
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* SECTION:cogl-pipeline
|
|
|
|
* @short_description: Functions for creating and manipulating the GPU
|
|
|
|
* pipeline
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Cogl allows creating and manipulating objects representing the full
|
|
|
|
* configuration of the GPU pipeline. In simplified terms the GPU
|
|
|
|
* pipeline takes primitive geometry as the input, it first performs
|
|
|
|
* vertex processing, allowing you to deform your geometry, then
|
|
|
|
* rasterizes that (turning it from pure geometry into fragments) then
|
|
|
|
* performs fragment processing including depth testing and texture
|
|
|
|
* mapping. Finally it blends the result with the framebuffer.
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
*/
|
|
|
|
|
2010-10-27 13:54:57 -04:00
|
|
|
typedef struct _CoglPipeline CoglPipeline;
|
2010-06-22 09:02:17 -04:00
|
|
|
|
2010-10-27 13:54:57 -04:00
|
|
|
#define COGL_PIPELINE(OBJECT) ((CoglPipeline *)OBJECT)
|
2010-06-22 09:02:17 -04:00
|
|
|
|
2009-06-04 11:04:57 -04:00
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* CoglPipelineFilter:
|
|
|
|
* @COGL_PIPELINE_FILTER_NEAREST: Measuring in manhatten distance from the,
|
2009-11-19 08:31:38 -05:00
|
|
|
* current pixel center, use the nearest texture texel
|
2010-10-27 13:54:57 -04:00
|
|
|
* @COGL_PIPELINE_FILTER_LINEAR: Use the weighted average of the 4 texels
|
2009-11-19 08:31:38 -05:00
|
|
|
* nearest the current pixel center
|
2010-10-27 13:54:57 -04:00
|
|
|
* @COGL_PIPELINE_FILTER_NEAREST_MIPMAP_NEAREST: Select the mimap level whose
|
2009-11-19 08:31:38 -05:00
|
|
|
* texel size most closely matches the current pixel, and use the
|
2010-10-27 13:54:57 -04:00
|
|
|
* %COGL_PIPELINE_FILTER_NEAREST criterion
|
|
|
|
* @COGL_PIPELINE_FILTER_LINEAR_MIPMAP_NEAREST: Select the mimap level whose
|
2009-11-19 08:31:38 -05:00
|
|
|
* texel size most closely matches the current pixel, and use the
|
2010-10-27 13:54:57 -04:00
|
|
|
* %COGL_PIPELINE_FILTER_LINEAR criterion
|
|
|
|
* @COGL_PIPELINE_FILTER_NEAREST_MIPMAP_LINEAR: Select the two mimap levels
|
2009-11-19 08:31:38 -05:00
|
|
|
* whose texel size most closely matches the current pixel, use
|
2010-10-27 13:54:57 -04:00
|
|
|
* the %COGL_PIPELINE_FILTER_NEAREST criterion on each one and take
|
2009-11-19 08:31:38 -05:00
|
|
|
* their weighted average
|
2010-10-27 13:54:57 -04:00
|
|
|
* @COGL_PIPELINE_FILTER_LINEAR_MIPMAP_LINEAR: Select the two mimap levels
|
2009-11-19 08:31:38 -05:00
|
|
|
* whose texel size most closely matches the current pixel, use
|
2010-10-27 13:54:57 -04:00
|
|
|
* the %COGL_PIPELINE_FILTER_LINEAR criterion on each one and take
|
2009-11-19 08:31:38 -05:00
|
|
|
* their weighted average
|
2009-06-04 11:04:57 -04:00
|
|
|
*
|
|
|
|
* Texture filtering is used whenever the current pixel maps either to more
|
|
|
|
* than one texture element (texel) or less than one. These filter enums
|
|
|
|
* correspond to different strategies used to come up with a pixel color, by
|
|
|
|
* possibly referring to multiple neighbouring texels and taking a weighted
|
|
|
|
* average or simply using the nearest texel.
|
|
|
|
*/
|
2009-11-19 08:31:38 -05:00
|
|
|
typedef enum {
|
2010-10-27 13:54:57 -04:00
|
|
|
COGL_PIPELINE_FILTER_NEAREST = 0x2600,
|
|
|
|
COGL_PIPELINE_FILTER_LINEAR = 0x2601,
|
|
|
|
COGL_PIPELINE_FILTER_NEAREST_MIPMAP_NEAREST = 0x2700,
|
|
|
|
COGL_PIPELINE_FILTER_LINEAR_MIPMAP_NEAREST = 0x2701,
|
|
|
|
COGL_PIPELINE_FILTER_NEAREST_MIPMAP_LINEAR = 0x2702,
|
|
|
|
COGL_PIPELINE_FILTER_LINEAR_MIPMAP_LINEAR = 0x2703
|
|
|
|
} CoglPipelineFilter;
|
|
|
|
/* NB: these values come from the equivalents in gl.h */
|
|
|
|
|
|
|
|
/**
|
|
|
|
* CoglPipelineWrapMode:
|
|
|
|
* @COGL_PIPELINE_WRAP_MODE_REPEAT: The texture will be repeated. This
|
2010-04-01 06:31:33 -04:00
|
|
|
* is useful for example to draw a tiled background.
|
2010-10-27 13:54:57 -04:00
|
|
|
* @COGL_PIPELINE_WRAP_MODE_CLAMP_TO_EDGE: The coordinates outside the
|
2010-04-01 06:31:33 -04:00
|
|
|
* range 0→1 will sample copies of the edge pixels of the
|
|
|
|
* texture. This is useful to avoid artifacts if only one copy of
|
|
|
|
* the texture is being rendered.
|
2010-10-27 13:54:57 -04:00
|
|
|
* @COGL_PIPELINE_WRAP_MODE_AUTOMATIC: Cogl will try to automatically
|
2010-04-01 06:31:33 -04:00
|
|
|
* decide which of the above two to use. For cogl_rectangle(), it
|
|
|
|
* will use repeat mode if any of the texture coordinates are
|
|
|
|
* outside the range 0→1, otherwise it will use clamp to edge. For
|
2010-04-07 06:06:20 -04:00
|
|
|
* cogl_polygon() it will always use repeat mode. For
|
|
|
|
* cogl_vertex_buffer_draw() it will use repeat mode except for
|
|
|
|
* layers that have point sprite coordinate generation enabled. This
|
|
|
|
* is the default value.
|
2010-04-01 06:31:33 -04:00
|
|
|
*
|
|
|
|
* The wrap mode specifies what happens when texture coordinates
|
|
|
|
* outside the range 0→1 are used. Note that if the filter mode is
|
2010-10-27 13:54:57 -04:00
|
|
|
* anything but %COGL_PIPELINE_FILTER_NEAREST then texels outside the
|
2010-04-01 06:31:33 -04:00
|
|
|
* range 0→1 might be used even when the coordinate is exactly 0 or 1
|
|
|
|
* because OpenGL will try to sample neighbouring pixels. For example
|
|
|
|
* if you are trying to render the full texture then you may get
|
|
|
|
* artifacts around the edges when the pixels from the other side are
|
|
|
|
* merged in if the wrap mode is set to repeat.
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
2010-04-01 06:31:33 -04:00
|
|
|
*/
|
|
|
|
/* GL_ALWAYS is just used here as a value that is known not to clash
|
2010-04-08 07:21:04 -04:00
|
|
|
* with any valid GL wrap modes
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* XXX: keep the values in sync with the CoglPipelineWrapModeInternal
|
2010-04-08 07:21:04 -04:00
|
|
|
* enum so no conversion is actually needed.
|
|
|
|
*/
|
2010-04-01 06:31:33 -04:00
|
|
|
typedef enum {
|
2010-10-27 13:54:57 -04:00
|
|
|
COGL_PIPELINE_WRAP_MODE_REPEAT = 0x2901,
|
|
|
|
COGL_PIPELINE_WRAP_MODE_CLAMP_TO_EDGE = 0x812F,
|
|
|
|
COGL_PIPELINE_WRAP_MODE_AUTOMATIC = 0x0207
|
|
|
|
} CoglPipelineWrapMode;
|
|
|
|
/* NB: these values come from the equivalents in gl.h */
|
2010-04-01 06:31:33 -04:00
|
|
|
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_new:
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Allocates and initializes a default simple pipeline that will color
|
|
|
|
* a primitive white.
|
2008-12-22 11:19:49 -05:00
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Return value: a pointer to a new #CoglPipeline
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
*/
|
2010-10-27 13:54:57 -04:00
|
|
|
CoglPipeline *
|
|
|
|
cogl_pipeline_new (void);
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
|
2009-11-11 07:50:48 -05:00
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_copy:
|
|
|
|
* @source: a #CoglPipeline object to copy
|
2009-11-11 07:50:48 -05:00
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Creates a new pipeline with the configuration copied from the
|
|
|
|
* source pipeline.
|
2009-11-11 07:50:48 -05:00
|
|
|
*
|
|
|
|
* We would strongly advise developers to always aim to use
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_copy() instead of cogl_pipeline_new() whenever there will
|
|
|
|
* be any similarity between two pipelines. Copying a pipeline helps Cogl
|
|
|
|
* keep track of a pipelines ancestry which we may use to help minimize GPU
|
2009-11-11 07:50:48 -05:00
|
|
|
* state changes.
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Returns: a pointer to the newly allocated #CoglPipeline
|
2009-11-11 07:50:48 -05:00
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
2009-11-11 07:50:48 -05:00
|
|
|
*/
|
2010-10-27 13:54:57 -04:00
|
|
|
CoglPipeline *
|
|
|
|
cogl_pipeline_copy (CoglPipeline *source);
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
|
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_is_pipeline:
|
2009-02-19 06:55:54 -05:00
|
|
|
* @handle: A CoglHandle
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Gets whether the given handle references an existing pipeline object.
|
2009-02-19 06:55:54 -05:00
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Return value: %TRUE if the handle references a #CoglPipeline,
|
2009-02-19 06:55:54 -05:00
|
|
|
* %FALSE otherwise
|
|
|
|
*/
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
gboolean
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_is_pipeline (CoglHandle handle);
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
|
2008-12-23 18:35:49 -05:00
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_set_color:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
2008-12-23 18:35:49 -05:00
|
|
|
* @color: The components of the color
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Sets the basic color of the pipeline, used when no lighting is enabled.
|
2008-12-23 18:35:49 -05:00
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Note that if you don't add any layers to the pipeline then the color
|
2009-05-09 14:39:01 -04:00
|
|
|
* will be blended unmodified with the destination; the default blend
|
|
|
|
* expects premultiplied colors: for example, use (0.5, 0.0, 0.0, 0.5) for
|
|
|
|
* semi-transparent red. See cogl_color_premultiply().
|
|
|
|
*
|
2008-12-23 18:35:49 -05:00
|
|
|
* The default value is (1.0, 1.0, 1.0, 1.0)
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
2008-12-23 18:35:49 -05:00
|
|
|
*/
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
void
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_set_color (CoglPipeline *pipeline,
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
const CoglColor *color);
|
2008-12-23 18:35:49 -05:00
|
|
|
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_set_color4ub:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
* @red: The red component
|
|
|
|
* @green: The green component
|
|
|
|
* @blue: The blue component
|
|
|
|
* @alpha: The alpha component
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Sets the basic color of the pipeline, used when no lighting is enabled.
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
*
|
2009-05-01 04:53:20 -04:00
|
|
|
* The default value is (0xff, 0xff, 0xff, 0xff)
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
*/
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
void
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_set_color4ub (CoglPipeline *pipeline,
|
2010-06-22 09:02:17 -04:00
|
|
|
guint8 red,
|
|
|
|
guint8 green,
|
|
|
|
guint8 blue,
|
|
|
|
guint8 alpha);
|
2009-02-06 06:16:42 -05:00
|
|
|
|
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_set_color4f:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
2009-02-06 06:16:42 -05:00
|
|
|
* @red: The red component
|
|
|
|
* @green: The green component
|
|
|
|
* @blue: The blue component
|
|
|
|
* @alpha: The alpha component
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Sets the basic color of the pipeline, used when no lighting is enabled.
|
2009-02-06 06:16:42 -05:00
|
|
|
*
|
|
|
|
* The default value is (1.0, 1.0, 1.0, 1.0)
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
2009-02-06 06:16:42 -05:00
|
|
|
*/
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
void
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_set_color4f (CoglPipeline *pipeline,
|
2010-06-22 09:02:17 -04:00
|
|
|
float red,
|
|
|
|
float green,
|
|
|
|
float blue,
|
|
|
|
float alpha);
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
|
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_get_color:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
2009-11-19 08:31:38 -05:00
|
|
|
* @color: (out): The location to store the color
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Retrieves the current pipeline color.
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
*/
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
void
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_get_color (CoglPipeline *pipeline,
|
2010-06-22 09:02:17 -04:00
|
|
|
CoglColor *color);
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_set_ambient:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
* @ambient: The components of the desired ambient color
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Sets the pipeline's ambient color, in the standard OpenGL lighting
|
2009-11-19 08:31:38 -05:00
|
|
|
* model. The ambient color affects the overall color of the object.
|
|
|
|
*
|
|
|
|
* Since the diffuse color will be intense when the light hits the surface
|
|
|
|
* directly, the ambient will be most apparent where the light hits at a
|
|
|
|
* slant.
|
2008-12-22 11:19:49 -05:00
|
|
|
*
|
|
|
|
* The default value is (0.2, 0.2, 0.2, 1.0)
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
*/
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
void
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_set_ambient (CoglPipeline *pipeline,
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
const CoglColor *ambient);
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_get_ambient:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
* @ambient: The location to store the ambient color
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Retrieves the current ambient color for @pipeline
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
*/
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
void
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_get_ambient (CoglPipeline *pipeline,
|
2010-06-22 09:02:17 -04:00
|
|
|
CoglColor *ambient);
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
|
2008-12-22 11:19:49 -05:00
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_set_diffuse:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
2008-12-22 11:19:49 -05:00
|
|
|
* @diffuse: The components of the desired diffuse color
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Sets the pipeline's diffuse color, in the standard OpenGL lighting
|
2009-11-19 08:31:38 -05:00
|
|
|
* model. The diffuse color is most intense where the light hits the
|
|
|
|
* surface directly - perpendicular to the surface.
|
2008-12-22 11:19:49 -05:00
|
|
|
*
|
|
|
|
* The default value is (0.8, 0.8, 0.8, 1.0)
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
2008-12-22 11:19:49 -05:00
|
|
|
*/
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
void
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_set_diffuse (CoglPipeline *pipeline,
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
const CoglColor *diffuse);
|
2008-12-22 11:19:49 -05:00
|
|
|
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_get_diffuse:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
* @diffuse: The location to store the diffuse color
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Retrieves the current diffuse color for @pipeline
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
*/
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
void
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_get_diffuse (CoglPipeline *pipeline,
|
2010-06-22 09:02:17 -04:00
|
|
|
CoglColor *diffuse);
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_set_ambient_and_diffuse:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
* @color: The components of the desired ambient and diffuse colors
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Conveniently sets the diffuse and ambient color of @pipeline at the same
|
|
|
|
* time. See cogl_pipeline_set_ambient() and cogl_pipeline_set_diffuse().
|
2008-12-22 11:19:49 -05:00
|
|
|
*
|
|
|
|
* The default ambient color is (0.2, 0.2, 0.2, 1.0)
|
2009-11-19 08:31:38 -05:00
|
|
|
*
|
2008-12-22 11:19:49 -05:00
|
|
|
* The default diffuse color is (0.8, 0.8, 0.8, 1.0)
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
*/
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
void
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_set_ambient_and_diffuse (CoglPipeline *pipeline,
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
const CoglColor *color);
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
|
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_set_specular:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
* @specular: The components of the desired specular color
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Sets the pipeline's specular color, in the standard OpenGL lighting
|
2009-11-19 08:31:38 -05:00
|
|
|
* model. The intensity of the specular color depends on the viewport
|
|
|
|
* position, and is brightest along the lines of reflection.
|
2008-12-22 11:19:49 -05:00
|
|
|
*
|
|
|
|
* The default value is (0.0, 0.0, 0.0, 1.0)
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
*/
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
void
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_set_specular (CoglPipeline *pipeline,
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
const CoglColor *specular);
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_get_specular:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
* @specular: The location to store the specular color
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Retrieves the pipelines current specular color.
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
*/
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
void
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_get_specular (CoglPipeline *pipeline,
|
2010-06-22 09:02:17 -04:00
|
|
|
CoglColor *specular);
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_set_shininess:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
2010-07-20 12:34:04 -04:00
|
|
|
* @shininess: The desired shininess; must be >= 0.0
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Sets the shininess of the pipeline, in the standard OpenGL lighting
|
2010-07-20 12:34:04 -04:00
|
|
|
* model, which determines the size of the specular highlights. A
|
|
|
|
* higher @shininess will produce smaller highlights which makes the
|
|
|
|
* object appear more shiny.
|
2008-12-22 11:19:49 -05:00
|
|
|
*
|
|
|
|
* The default value is 0.0
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
*/
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
void
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_set_shininess (CoglPipeline *pipeline,
|
2010-06-22 09:02:17 -04:00
|
|
|
float shininess);
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_get_shininess:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Retrieves the pipelines current emission color.
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Return value: The pipelines current shininess value
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
*/
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
float
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_get_shininess (CoglPipeline *pipeline);
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
|
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_set_emission:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
* @emission: The components of the desired emissive color
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Sets the pipeline's emissive color, in the standard OpenGL lighting
|
2009-11-19 08:31:38 -05:00
|
|
|
* model. It will look like the surface is a light source emitting this
|
|
|
|
* color.
|
2008-12-22 11:19:49 -05:00
|
|
|
*
|
|
|
|
* The default value is (0.0, 0.0, 0.0, 1.0)
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
*/
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
void
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_set_emission (CoglPipeline *pipeline,
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
const CoglColor *emission);
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_get_emission:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
* @emission: The location to store the emission color
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Retrieves the pipelines current emission color.
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
*/
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
void
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_get_emission (CoglPipeline *pipeline,
|
2010-06-22 09:02:17 -04:00
|
|
|
CoglColor *emission);
|
Fully integrates CoglMaterial throughout the rest of Cogl
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.
2009-01-23 11:15:40 -05:00
|
|
|
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* CoglPipelineAlphaFunc:
|
|
|
|
* @COGL_PIPELINE_ALPHA_FUNC_NEVER: Never let the fragment through.
|
|
|
|
* @COGL_PIPELINE_ALPHA_FUNC_LESS: Let the fragment through if the incoming
|
2009-11-19 08:31:38 -05:00
|
|
|
* alpha value is less than the reference alpha value
|
2010-10-27 13:54:57 -04:00
|
|
|
* @COGL_PIPELINE_ALPHA_FUNC_EQUAL: Let the fragment through if the incoming
|
2009-11-19 08:31:38 -05:00
|
|
|
* alpha value equals the reference alpha value
|
2010-10-27 13:54:57 -04:00
|
|
|
* @COGL_PIPELINE_ALPHA_FUNC_LEQUAL: Let the fragment through if the incoming
|
2009-11-19 08:31:38 -05:00
|
|
|
* alpha value is less than or equal to the reference alpha value
|
2010-10-27 13:54:57 -04:00
|
|
|
* @COGL_PIPELINE_ALPHA_FUNC_GREATER: Let the fragment through if the incoming
|
2009-11-19 08:31:38 -05:00
|
|
|
* alpha value is greater than the reference alpha value
|
2010-10-27 13:54:57 -04:00
|
|
|
* @COGL_PIPELINE_ALPHA_FUNC_NOTEQUAL: Let the fragment through if the incoming
|
2009-11-19 08:31:38 -05:00
|
|
|
* alpha value does not equal the reference alpha value
|
2010-10-27 13:54:57 -04:00
|
|
|
* @COGL_PIPELINE_ALPHA_FUNC_GEQUAL: Let the fragment through if the incoming
|
2009-11-19 08:31:38 -05:00
|
|
|
* alpha value is greater than or equal to the reference alpha value.
|
2010-10-27 13:54:57 -04:00
|
|
|
* @COGL_PIPELINE_ALPHA_FUNC_ALWAYS: Always let the fragment through.
|
2008-12-22 11:19:49 -05:00
|
|
|
*
|
|
|
|
* Alpha testing happens before blending primitives with the framebuffer and
|
|
|
|
* gives an opportunity to discard fragments based on a comparison with the
|
2010-10-27 13:54:57 -04:00
|
|
|
* incoming alpha value and a reference alpha value. The #CoglPipelineAlphaFunc
|
2008-12-22 11:19:49 -05:00
|
|
|
* determines how the comparison is done.
|
|
|
|
*/
|
2009-11-19 08:31:38 -05:00
|
|
|
typedef enum {
|
2010-10-27 13:54:57 -04:00
|
|
|
COGL_PIPELINE_ALPHA_FUNC_NEVER = 0x0200,
|
|
|
|
COGL_PIPELINE_ALPHA_FUNC_LESS = 0x0201,
|
|
|
|
COGL_PIPELINE_ALPHA_FUNC_EQUAL = 0x0202,
|
|
|
|
COGL_PIPELINE_ALPHA_FUNC_LEQUAL = 0x0203,
|
|
|
|
COGL_PIPELINE_ALPHA_FUNC_GREATER = 0x0204,
|
|
|
|
COGL_PIPELINE_ALPHA_FUNC_NOTEQUAL = 0x0205,
|
|
|
|
COGL_PIPELINE_ALPHA_FUNC_GEQUAL = 0x0206,
|
|
|
|
COGL_PIPELINE_ALPHA_FUNC_ALWAYS = 0x0207
|
|
|
|
} CoglPipelineAlphaFunc;
|
|
|
|
/* NB: these values come from the equivalents in gl.h */
|
|
|
|
|
|
|
|
/**
|
|
|
|
* cogl_pipeline_set_alpha_test_function:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
|
|
|
* @alpha_func: A @CoglPipelineAlphaFunc constant
|
2008-12-22 11:19:49 -05:00
|
|
|
* @alpha_reference: A reference point that the chosen alpha function uses
|
2009-11-19 08:31:38 -05:00
|
|
|
* to compare incoming fragments to.
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
*
|
|
|
|
* Before a primitive is blended with the framebuffer, it goes through an
|
|
|
|
* alpha test stage which lets you discard fragments based on the current
|
|
|
|
* alpha value. This function lets you change the function used to evaluate
|
|
|
|
* the alpha channel, and thus determine which fragments are discarded
|
|
|
|
* and which continue on to the blending stage.
|
2008-12-22 11:19:49 -05:00
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* The default is %COGL_PIPELINE_ALPHA_FUNC_ALWAYS
|
2008-12-22 11:19:49 -05:00
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
*/
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
void
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_set_alpha_test_function (CoglPipeline *pipeline,
|
|
|
|
CoglPipelineAlphaFunc alpha_func,
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
float alpha_reference);
|
2008-12-22 11:19:49 -05:00
|
|
|
|
2009-05-10 19:40:41 -04:00
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_set_blend:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
2009-05-10 19:40:41 -04:00
|
|
|
* @blend_string: A <link linkend="cogl-Blend-Strings">Cogl blend string</link>
|
2009-11-19 08:31:38 -05:00
|
|
|
* describing the desired blend function.
|
|
|
|
* @error: return location for a #GError that may report lack of driver
|
|
|
|
* support if you give separate blend string statements for the alpha
|
|
|
|
* channel and RGB channels since some drivers, or backends such as
|
|
|
|
* GLES 1.1, don't support this feature. May be %NULL, in which case a
|
|
|
|
* warning will be printed out using GLib's logging facilities if an
|
|
|
|
* error is encountered.
|
|
|
|
*
|
|
|
|
* If not already familiar; please refer <link linkend="cogl-Blend-Strings">here</link>
|
|
|
|
* for an overview of what blend strings are, and their syntax.
|
2009-05-10 19:40:41 -04:00
|
|
|
*
|
|
|
|
* Blending occurs after the alpha test function, and combines fragments with
|
|
|
|
* the framebuffer.
|
|
|
|
|
|
|
|
* Currently the only blend function Cogl exposes is ADD(). So any valid
|
|
|
|
* blend statements will be of the form:
|
|
|
|
*
|
2009-11-19 08:31:38 -05:00
|
|
|
* |[
|
|
|
|
* <channel-mask>=ADD(SRC_COLOR*(<factor>), DST_COLOR*(<factor>))
|
|
|
|
* ]|
|
2009-05-10 19:40:41 -04:00
|
|
|
*
|
2009-11-19 08:31:38 -05:00
|
|
|
* <warning>The brackets around blend factors are currently not
|
|
|
|
* optional!</warning>
|
2009-05-10 19:40:41 -04:00
|
|
|
*
|
|
|
|
* This is the list of source-names usable as blend factors:
|
|
|
|
* <itemizedlist>
|
2009-11-19 08:31:38 -05:00
|
|
|
* <listitem><para>SRC_COLOR: The color of the in comming fragment</para></listitem>
|
|
|
|
* <listitem><para>DST_COLOR: The color of the framebuffer</para></listitem>
|
2010-10-27 13:54:57 -04:00
|
|
|
* <listitem><para>CONSTANT: The constant set via cogl_pipeline_set_blend_constant()</para></listitem>
|
2009-05-10 19:40:41 -04:00
|
|
|
* </itemizedlist>
|
2009-11-19 08:31:38 -05:00
|
|
|
*
|
2009-05-10 19:40:41 -04:00
|
|
|
* The source names can be used according to the
|
|
|
|
* <link linkend="cogl-Blend-String-syntax">color-source and factor syntax</link>,
|
|
|
|
* so for example "(1-SRC_COLOR[A])" would be a valid factor, as would
|
|
|
|
* "(CONSTANT[RGB])"
|
|
|
|
*
|
|
|
|
* These can also be used as factors:
|
|
|
|
* <itemizedlist>
|
2009-11-19 08:31:38 -05:00
|
|
|
* <listitem>0: (0, 0, 0, 0)</listitem>
|
|
|
|
* <listitem>1: (1, 1, 1, 1)</listitem>
|
|
|
|
* <listitem>SRC_ALPHA_SATURATE_FACTOR: (f,f,f,1) where f = MIN(SRC_COLOR[A],1-DST_COLOR[A])</listitem>
|
2009-05-10 19:40:41 -04:00
|
|
|
* </itemizedlist>
|
2009-11-19 08:31:38 -05:00
|
|
|
*
|
|
|
|
* <note>Remember; all color components are normalized to the range [0, 1]
|
|
|
|
* before computing the result of blending.</note>
|
|
|
|
*
|
|
|
|
* <example id="cogl-Blend-Strings-blend-unpremul">
|
|
|
|
* <title>Blend Strings/1</title>
|
|
|
|
* <para>Blend a non-premultiplied source over a destination with
|
|
|
|
* premultiplied alpha:</para>
|
|
|
|
* <programlisting>
|
2009-05-10 19:40:41 -04:00
|
|
|
* "RGB = ADD(SRC_COLOR*(SRC_COLOR[A]), DST_COLOR*(1-SRC_COLOR[A]))"
|
|
|
|
* "A = ADD(SRC_COLOR, DST_COLOR*(1-SRC_COLOR[A]))"
|
2009-11-19 08:31:38 -05:00
|
|
|
* </programlisting>
|
|
|
|
* </example>
|
|
|
|
*
|
|
|
|
* <example id="cogl-Blend-Strings-blend-premul">
|
|
|
|
* <title>Blend Strings/2</title>
|
|
|
|
* <para>Blend a premultiplied source over a destination with
|
|
|
|
* premultiplied alpha</para>
|
|
|
|
* <programlisting>
|
2009-05-10 19:40:41 -04:00
|
|
|
* "RGBA = ADD(SRC_COLOR, DST_COLOR*(1-SRC_COLOR[A]))"
|
2009-11-19 08:31:38 -05:00
|
|
|
* </programlisting>
|
|
|
|
* </example>
|
2009-05-10 19:40:41 -04:00
|
|
|
*
|
2009-05-09 14:39:01 -04:00
|
|
|
* The default blend string is:
|
2009-11-19 08:31:38 -05:00
|
|
|
* |[
|
|
|
|
* RGBA = ADD (SRC_COLOR, DST_COLOR*(1-SRC_COLOR[A]))
|
|
|
|
* ]|
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* That gives normal alpha-blending when the calculated color for the pipeline
|
2009-05-09 14:39:01 -04:00
|
|
|
* is in premultiplied form.
|
|
|
|
*
|
2009-11-19 08:31:38 -05:00
|
|
|
* Return value: %TRUE if the blend string was successfully parsed, and the
|
|
|
|
* described blending is supported by the underlying driver/hardware. If
|
|
|
|
* there was an error, %FALSE is returned and @error is set accordingly (if
|
|
|
|
* present).
|
2009-05-10 19:40:41 -04:00
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
2009-05-10 19:40:41 -04:00
|
|
|
*/
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
gboolean
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_set_blend (CoglPipeline *pipeline,
|
2010-06-22 09:02:17 -04:00
|
|
|
const char *blend_string,
|
|
|
|
GError **error);
|
2009-05-10 19:40:41 -04:00
|
|
|
|
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_set_blend_constant:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
2009-05-10 19:40:41 -04:00
|
|
|
* @constant_color: The constant color you want
|
|
|
|
*
|
|
|
|
* When blending is setup to reference a CONSTANT blend factor then
|
|
|
|
* blending will depend on the constant set with this function.
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
2009-05-10 19:40:41 -04:00
|
|
|
*/
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
void
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_set_blend_constant (CoglPipeline *pipeline,
|
2010-06-28 10:25:19 -04:00
|
|
|
const CoglColor *constant_color);
|
2009-05-10 19:40:41 -04:00
|
|
|
|
2010-03-22 05:32:17 -04:00
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_set_point_size:
|
|
|
|
* @pipeline: a #CoglHandle to a pipeline.
|
2010-03-22 05:32:17 -04:00
|
|
|
* @size: the new point size.
|
|
|
|
*
|
|
|
|
* Changes the size of points drawn when %COGL_VERTICES_MODE_POINTS is
|
|
|
|
* used with the vertex buffer API. Note that typically the GPU will
|
|
|
|
* only support a limited minimum and maximum range of point sizes. If
|
|
|
|
* the chosen point size is outside that range then the nearest value
|
|
|
|
* within that range will be used instead. The size of a point is in
|
|
|
|
* screen space so it will be the same regardless of any
|
|
|
|
* transformations. The default point size is 1.0.
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
2010-03-22 05:32:17 -04:00
|
|
|
*/
|
|
|
|
void
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_set_point_size (CoglHandle pipeline,
|
2010-03-22 05:32:17 -04:00
|
|
|
float point_size);
|
|
|
|
|
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_get_point_size:
|
|
|
|
* @pipeline: a #CoglHandle to a pipeline.
|
2010-03-22 05:32:17 -04:00
|
|
|
*
|
|
|
|
* Get the size of points drawn when %COGL_VERTICES_MODE_POINTS is
|
|
|
|
* used with the vertex buffer API.
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Return value: the point size of the pipeline.
|
2010-03-22 05:32:17 -04:00
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
2010-03-22 05:32:17 -04:00
|
|
|
*/
|
|
|
|
float
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_get_point_size (CoglHandle pipeline);
|
2010-03-22 05:32:17 -04:00
|
|
|
|
2010-08-05 05:46:54 -04:00
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_get_user_program:
|
|
|
|
* @pipeline: a #CoglPipeline object.
|
2010-08-05 05:46:54 -04:00
|
|
|
*
|
|
|
|
* Queries what user program has been associated with the given
|
2010-10-27 13:54:57 -04:00
|
|
|
* @pipeline using cogl_pipeline_set_user_program().
|
2010-08-05 05:46:54 -04:00
|
|
|
*
|
|
|
|
* Return value: The current user program or %COGL_INVALID_HANDLE.
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
2010-08-05 05:46:54 -04:00
|
|
|
*/
|
|
|
|
CoglHandle
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_get_user_program (CoglPipeline *pipeline);
|
2010-08-05 05:46:54 -04:00
|
|
|
|
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_set_user_program:
|
|
|
|
* @pipeline: a #CoglPipeline object.
|
2010-08-05 05:46:54 -04:00
|
|
|
* @program: A #CoglHandle to a linked CoglProgram
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Associates a linked CoglProgram with the given pipeline so that the
|
2010-08-05 05:46:54 -04:00
|
|
|
* program can take full control of vertex and/or fragment processing.
|
|
|
|
*
|
|
|
|
* This is an example of how it can be used to associate an ARBfp
|
2010-10-27 13:54:57 -04:00
|
|
|
* program with a #CoglPipeline:
|
2010-08-05 05:46:54 -04:00
|
|
|
* |[
|
|
|
|
* CoglHandle shader;
|
|
|
|
* CoglHandle program;
|
2010-10-27 13:54:57 -04:00
|
|
|
* CoglPipeline *pipeline;
|
2010-08-05 05:46:54 -04:00
|
|
|
*
|
|
|
|
* shader = cogl_create_shader (COGL_SHADER_TYPE_FRAGMENT);
|
|
|
|
* cogl_shader_source (shader,
|
|
|
|
* "!!ARBfp1.0\n"
|
|
|
|
* "MOV result.color,fragment.color;\n"
|
|
|
|
* "END\n");
|
|
|
|
* cogl_shader_compile (shader);
|
|
|
|
*
|
|
|
|
* program = cogl_create_program ();
|
|
|
|
* cogl_program_attach_shader (program, shader);
|
|
|
|
* cogl_program_link (program);
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* pipeline = cogl_pipeline_new ();
|
|
|
|
* cogl_pipeline_set_user_program (pipeline, program);
|
2010-08-05 05:46:54 -04:00
|
|
|
*
|
|
|
|
* cogl_set_source_color4ub (0xff, 0x00, 0x00, 0xff);
|
|
|
|
* cogl_rectangle (0, 0, 100, 100);
|
|
|
|
* ]|
|
|
|
|
*
|
|
|
|
* It is possibly worth keeping in mind that this API is not part of
|
|
|
|
* the long term design for how we want to expose shaders to Cogl
|
|
|
|
* developers (We are planning on deprecating the cogl_program and
|
|
|
|
* cogl_shader APIs in favour of a "snippet" framework) but in the
|
|
|
|
* meantime we hope this will handle most practical GLSL and ARBfp
|
|
|
|
* requirements.
|
|
|
|
*
|
|
|
|
* Also remember you need to check for either the
|
|
|
|
* %COGL_FEATURE_SHADERS_GLSL or %COGL_FEATURE_SHADERS_ARBFP before
|
|
|
|
* using the cogl_program or cogl_shader API.
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
2010-08-05 05:46:54 -04:00
|
|
|
*/
|
|
|
|
void
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_set_user_program (CoglPipeline *pipeline,
|
2010-08-05 05:46:54 -04:00
|
|
|
CoglHandle program);
|
|
|
|
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_set_layer:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
2009-06-10 07:50:45 -04:00
|
|
|
* @layer_index: the index of the layer
|
|
|
|
* @texture: a #CoglHandle for the layer object
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* In addition to the standard OpenGL lighting model a Cogl pipeline may have
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
* one or more layers comprised of textures that can be blended together in
|
2008-12-22 11:19:49 -05:00
|
|
|
* order, with a number of different texture combine modes. This function
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
* defines a new texture layer.
|
|
|
|
*
|
|
|
|
* The index values of multiple layers do not have to be consecutive; it is
|
|
|
|
* only their relative order that is important.
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* <note>In the future, we may define other types of pipeline layers, such
|
2009-06-10 07:50:45 -04:00
|
|
|
* as purely GLSL based layers.</note>
|
2008-12-22 11:19:49 -05:00
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
*/
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
void
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_set_layer_texture (CoglPipeline *pipeline,
|
|
|
|
int layer_index,
|
|
|
|
CoglHandle texture);
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
|
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_remove_layer:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
2008-12-22 11:19:49 -05:00
|
|
|
* @layer_index: Specifies the layer you want to remove
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* This function removes a layer from your pipeline
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
*/
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
void
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_remove_layer (CoglPipeline *pipeline,
|
2010-06-22 09:02:17 -04:00
|
|
|
int layer_index);
|
2008-12-22 11:19:49 -05:00
|
|
|
|
2009-05-10 19:40:41 -04:00
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_set_layer_combine:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
2009-05-10 19:40:41 -04:00
|
|
|
* @layer_index: Specifies the layer you want define a combine function for
|
|
|
|
* @blend_string: A <link linkend="cogl-Blend-Strings">Cogl blend string</link>
|
2009-11-19 08:31:38 -05:00
|
|
|
* describing the desired texture combine function.
|
|
|
|
* @error: A #GError that may report parse errors or lack of GPU/driver
|
|
|
|
* support. May be %NULL, in which case a warning will be printed out if an
|
|
|
|
* error is encountered.
|
2009-05-10 19:40:41 -04:00
|
|
|
*
|
|
|
|
* If not already familiar; you can refer
|
|
|
|
* <link linkend="cogl-Blend-Strings">here</link> for an overview of what blend
|
|
|
|
* strings are and there syntax.
|
|
|
|
*
|
|
|
|
* These are all the functions available for texture combining:
|
|
|
|
* <itemizedlist>
|
2009-11-19 08:31:38 -05:00
|
|
|
* <listitem>REPLACE(arg0) = arg0</listitem>
|
|
|
|
* <listitem>MODULATE(arg0, arg1) = arg0 x arg1</listitem>
|
|
|
|
* <listitem>ADD(arg0, arg1) = arg0 + arg1</listitem>
|
|
|
|
* <listitem>ADD_SIGNED(arg0, arg1) = arg0 + arg1 - 0.5</listitem>
|
|
|
|
* <listitem>INTERPOLATE(arg0, arg1, arg2) = arg0 x arg2 + arg1 x (1 - arg2)</listitem>
|
|
|
|
* <listitem>SUBTRACT(arg0, arg1) = arg0 - arg1</listitem>
|
|
|
|
* <listitem>
|
|
|
|
* <programlisting>
|
|
|
|
* DOT3_RGB(arg0, arg1) = 4 x ((arg0[R] - 0.5)) * (arg1[R] - 0.5) +
|
|
|
|
* (arg0[G] - 0.5)) * (arg1[G] - 0.5) +
|
|
|
|
* (arg0[B] - 0.5)) * (arg1[B] - 0.5))
|
|
|
|
* </programlisting>
|
|
|
|
* </listitem>
|
|
|
|
* <listitem>
|
|
|
|
* <programlisting>
|
|
|
|
* DOT3_RGBA(arg0, arg1) = 4 x ((arg0[R] - 0.5)) * (arg1[R] - 0.5) +
|
|
|
|
* (arg0[G] - 0.5)) * (arg1[G] - 0.5) +
|
|
|
|
* (arg0[B] - 0.5)) * (arg1[B] - 0.5))
|
|
|
|
* </programlisting>
|
|
|
|
* </listitem>
|
2009-05-10 19:40:41 -04:00
|
|
|
* </itemizedlist>
|
|
|
|
*
|
|
|
|
* Refer to the
|
|
|
|
* <link linkend="cogl-Blend-String-syntax">color-source syntax</link> for
|
|
|
|
* describing the arguments. The valid source names for texture combining
|
|
|
|
* are:
|
2009-11-19 08:31:38 -05:00
|
|
|
* <variablelist>
|
|
|
|
* <varlistentry>
|
|
|
|
* <term>TEXTURE</term>
|
|
|
|
* <listitem>Use the color from the current texture layer</listitem>
|
|
|
|
* </varlistentry>
|
|
|
|
* <varlistentry>
|
|
|
|
* <term>TEXTURE_0, TEXTURE_1, etc</term>
|
|
|
|
* <listitem>Use the color from the specified texture layer</listitem>
|
|
|
|
* </varlistentry>
|
|
|
|
* <varlistentry>
|
|
|
|
* <term>CONSTANT</term>
|
|
|
|
* <listitem>Use the color from the constant given with
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_set_layer_constant()</listitem>
|
2009-11-19 08:31:38 -05:00
|
|
|
* </varlistentry>
|
|
|
|
* <varlistentry>
|
|
|
|
* <term>PRIMARY</term>
|
2010-10-27 13:54:57 -04:00
|
|
|
* <listitem>Use the color of the pipeline as set with
|
|
|
|
* cogl_pipeline_set_color()</listitem>
|
2009-11-19 08:31:38 -05:00
|
|
|
* </varlistentry>
|
|
|
|
* <varlistentry>
|
|
|
|
* <term>PREVIOUS</term>
|
|
|
|
* <listitem>Either use the texture color from the previous layer, or
|
2010-10-27 13:54:57 -04:00
|
|
|
* if this is layer 0, use the color of the pipeline as set with
|
|
|
|
* cogl_pipeline_set_color()</listitem>
|
2009-11-19 08:31:38 -05:00
|
|
|
* </varlistentry>
|
|
|
|
* </variablelist>
|
|
|
|
*
|
|
|
|
* <refsect2 id="cogl-Layer-Combine-Examples">
|
|
|
|
* <title>Layer Combine Examples</title>
|
|
|
|
* <para>This is effectively what the default blending is:</para>
|
|
|
|
* <informalexample><programlisting>
|
2009-07-20 07:49:35 -04:00
|
|
|
* RGBA = MODULATE (PREVIOUS, TEXTURE)
|
2009-11-19 08:31:38 -05:00
|
|
|
* </programlisting></informalexample>
|
|
|
|
* <para>This could be used to cross-fade between two images, using
|
|
|
|
* the alpha component of a constant as the interpolator. The constant
|
2010-10-27 13:54:57 -04:00
|
|
|
* color is given by calling cogl_pipeline_set_layer_constant.</para>
|
2009-11-19 08:31:38 -05:00
|
|
|
* <informalexample><programlisting>
|
2009-07-20 07:49:35 -04:00
|
|
|
* RGBA = INTERPOLATE (PREVIOUS, TEXTURE, CONSTANT[A])
|
2009-11-19 08:31:38 -05:00
|
|
|
* </programlisting></informalexample>
|
2009-07-20 07:49:35 -04:00
|
|
|
* </refsect2>
|
2009-05-10 19:40:41 -04:00
|
|
|
*
|
2009-07-20 07:49:35 -04:00
|
|
|
* <note>You can't give a multiplication factor for arguments as you can
|
|
|
|
* with blending.</note>
|
|
|
|
*
|
2009-11-19 08:31:38 -05:00
|
|
|
* Return value: %TRUE if the blend string was successfully parsed, and the
|
2009-07-20 07:49:35 -04:00
|
|
|
* described texture combining is supported by the underlying driver and
|
2009-11-19 08:31:38 -05:00
|
|
|
* or hardware. On failure, %FALSE is returned and @error is set
|
2009-05-10 19:40:41 -04:00
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
2009-05-10 19:40:41 -04:00
|
|
|
*/
|
|
|
|
gboolean
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_set_layer_combine (CoglPipeline *pipeline,
|
2010-06-22 09:02:17 -04:00
|
|
|
int layer_index,
|
|
|
|
const char *blend_string,
|
|
|
|
GError **error);
|
2009-05-10 19:40:41 -04:00
|
|
|
|
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_set_layer_combine_constant:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
2009-05-10 19:40:41 -04:00
|
|
|
* @layer_index: Specifies the layer you want to specify a constant used
|
|
|
|
* for texture combining
|
2009-06-10 07:50:45 -04:00
|
|
|
* @constant: The constant color you want
|
2009-05-10 19:40:41 -04:00
|
|
|
*
|
|
|
|
* When you are using the 'CONSTANT' color source in a layer combine
|
|
|
|
* description then you can use this function to define its value.
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
2009-05-10 19:40:41 -04:00
|
|
|
*/
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
void
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_set_layer_combine_constant (CoglPipeline *pipeline,
|
2010-06-28 10:25:19 -04:00
|
|
|
int layer_index,
|
|
|
|
const CoglColor *constant);
|
2009-05-10 19:40:41 -04:00
|
|
|
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_set_layer_matrix:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
|
|
|
* @layer_index: the index for the layer inside @pipeline
|
2009-07-20 07:49:35 -04:00
|
|
|
* @matrix: the transformation matrix for the layer
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
*
|
|
|
|
* This function lets you set a matrix that can be used to e.g. translate
|
2010-10-27 13:54:57 -04:00
|
|
|
* and rotate a single layer of a pipeline used to fill your geometry.
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
*/
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
void
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_set_layer_matrix (CoglPipeline *pipeline,
|
2010-06-22 09:02:17 -04:00
|
|
|
int layer_index,
|
|
|
|
const CoglMatrix *matrix);
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
|
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_get_n_layers:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
[cogl] Improving Cogl journal to minimize driver overheads + GPU state changes
Previously the journal was always flushed at the end of
_cogl_rectangles_with_multitexture_coords, (i.e. the end of any
cogl_rectangle* calls) but now we have broadened the potential for batching
geometry. In ideal circumstances we will only flush once per scene.
In summary the journal works like this:
When you use any of the cogl_rectangle* APIs then nothing is emitted to the
GPU at this point, we just log one or more quads into the journal. A
journal entry consists of the quad coordinates, an associated material
reference, and a modelview matrix. Ideally the journal only gets flushed
once at the end of a scene, but in fact there are things to consider that
may cause unwanted flushing, including:
- modifying materials mid-scene
This is because each quad in the journal has an associated material
reference (i.e. not copy), so if you try and modify a material that is
already referenced in the journal we force a flush first)
NOTE: For now this means you should avoid using cogl_set_source_color()
since that currently uses a single shared material. Later we
should change it to use a pool of materials that is recycled
when the journal is flushed.
- modifying any state that isn't currently logged, such as depth, fog and
backface culling enables.
The first thing that happens when flushing, is to upload all the vertex data
associated with the journal into a single VBO.
We then go through a process of splitting up the journal into batches that
have compatible state so they can be emitted to the GPU together. This is
currently broken up into 3 levels so we can stagger the state changes:
1) we break the journal up according to changes in the number of material layers
associated with logged quads. The number of layers in a material determines
the stride of the associated vertices, so we have to update our vertex
array offsets at this level. (i.e. calling gl{Vertex,Color},Pointer etc)
2) we further split batches up according to material compatability. (e.g.
materials with different textures) We flush material state at this level.
3) Finally we split batches up according to modelview changes. At this level
we update the modelview matrix and actually emit the actual draw command.
This commit is largely about putting the initial design in-place; this will be
followed by other changes that take advantage of the extended batching.
2009-06-17 13:46:42 -04:00
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Retrieves the number of layers defined for the given @pipeline
|
2009-07-20 07:49:35 -04:00
|
|
|
*
|
2009-11-19 08:31:38 -05:00
|
|
|
* Return value: the number of layers
|
[cogl] Improving Cogl journal to minimize driver overheads + GPU state changes
Previously the journal was always flushed at the end of
_cogl_rectangles_with_multitexture_coords, (i.e. the end of any
cogl_rectangle* calls) but now we have broadened the potential for batching
geometry. In ideal circumstances we will only flush once per scene.
In summary the journal works like this:
When you use any of the cogl_rectangle* APIs then nothing is emitted to the
GPU at this point, we just log one or more quads into the journal. A
journal entry consists of the quad coordinates, an associated material
reference, and a modelview matrix. Ideally the journal only gets flushed
once at the end of a scene, but in fact there are things to consider that
may cause unwanted flushing, including:
- modifying materials mid-scene
This is because each quad in the journal has an associated material
reference (i.e. not copy), so if you try and modify a material that is
already referenced in the journal we force a flush first)
NOTE: For now this means you should avoid using cogl_set_source_color()
since that currently uses a single shared material. Later we
should change it to use a pool of materials that is recycled
when the journal is flushed.
- modifying any state that isn't currently logged, such as depth, fog and
backface culling enables.
The first thing that happens when flushing, is to upload all the vertex data
associated with the journal into a single VBO.
We then go through a process of splitting up the journal into batches that
have compatible state so they can be emitted to the GPU together. This is
currently broken up into 3 levels so we can stagger the state changes:
1) we break the journal up according to changes in the number of material layers
associated with logged quads. The number of layers in a material determines
the stride of the associated vertices, so we have to update our vertex
array offsets at this level. (i.e. calling gl{Vertex,Color},Pointer etc)
2) we further split batches up according to material compatability. (e.g.
materials with different textures) We flush material state at this level.
3) Finally we split batches up according to modelview changes. At this level
we update the modelview matrix and actually emit the actual draw command.
This commit is largely about putting the initial design in-place; this will be
followed by other changes that take advantage of the extended batching.
2009-06-17 13:46:42 -04:00
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
[cogl] Improving Cogl journal to minimize driver overheads + GPU state changes
Previously the journal was always flushed at the end of
_cogl_rectangles_with_multitexture_coords, (i.e. the end of any
cogl_rectangle* calls) but now we have broadened the potential for batching
geometry. In ideal circumstances we will only flush once per scene.
In summary the journal works like this:
When you use any of the cogl_rectangle* APIs then nothing is emitted to the
GPU at this point, we just log one or more quads into the journal. A
journal entry consists of the quad coordinates, an associated material
reference, and a modelview matrix. Ideally the journal only gets flushed
once at the end of a scene, but in fact there are things to consider that
may cause unwanted flushing, including:
- modifying materials mid-scene
This is because each quad in the journal has an associated material
reference (i.e. not copy), so if you try and modify a material that is
already referenced in the journal we force a flush first)
NOTE: For now this means you should avoid using cogl_set_source_color()
since that currently uses a single shared material. Later we
should change it to use a pool of materials that is recycled
when the journal is flushed.
- modifying any state that isn't currently logged, such as depth, fog and
backface culling enables.
The first thing that happens when flushing, is to upload all the vertex data
associated with the journal into a single VBO.
We then go through a process of splitting up the journal into batches that
have compatible state so they can be emitted to the GPU together. This is
currently broken up into 3 levels so we can stagger the state changes:
1) we break the journal up according to changes in the number of material layers
associated with logged quads. The number of layers in a material determines
the stride of the associated vertices, so we have to update our vertex
array offsets at this level. (i.e. calling gl{Vertex,Color},Pointer etc)
2) we further split batches up according to material compatability. (e.g.
materials with different textures) We flush material state at this level.
3) Finally we split batches up according to modelview changes. At this level
we update the modelview matrix and actually emit the actual draw command.
This commit is largely about putting the initial design in-place; this will be
followed by other changes that take advantage of the extended batching.
2009-06-17 13:46:42 -04:00
|
|
|
*/
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
int
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_get_n_layers (CoglPipeline *pipeline);
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
|
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_set_layer_filters:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
2009-06-04 11:04:57 -04:00
|
|
|
* @layer_index: the layer number to change.
|
|
|
|
* @min_filter: the filter used when scaling a texture down.
|
|
|
|
* @mag_filter: the filter used when magnifying a texture.
|
|
|
|
*
|
|
|
|
* Changes the decimation and interpolation filters used when a texture is
|
|
|
|
* drawn at other scales than 100%.
|
|
|
|
*/
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
void
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_set_layer_filters (CoglPipeline *pipeline,
|
cogl: improves header and coding style consistency
We've had complaints that our Cogl code/headers are a bit "special" so
this is a first pass at tidying things up by giving them some
consistency. These changes are all consistent with how new code in Cogl
is being written, but the style isn't consistently applied across all
code yet.
There are two parts to this patch; but since each one required a large
amount of effort to maintain tidy indenting it made sense to combine the
changes to reduce the time spent re indenting the same lines.
The first change is to use a consistent style for declaring function
prototypes in headers. Cogl headers now consistently use this style for
prototypes:
return_type
cogl_function_name (CoglType arg0,
CoglType arg1);
Not everyone likes this style, but it seems that most of the currently
active Cogl developers agree on it.
The second change is to constrain the use of redundant glib data types
in Cogl. Uses of gint, guint, gfloat, glong, gulong and gchar have all
been replaced with int, unsigned int, float, long, unsigned long and char
respectively. When talking about pixel data; use of guchar has been
replaced with guint8, otherwise unsigned char can be used.
The glib types that we continue to use for portability are gboolean,
gint{8,16,32,64}, guint{8,16,32,64} and gsize.
The general intention is that Cogl should look palatable to the widest
range of C programmers including those outside the Gnome community so
- especially for the public API - we want to minimize the number of
foreign looking typedefs.
2010-02-09 20:57:32 -05:00
|
|
|
int layer_index,
|
2010-10-27 13:54:57 -04:00
|
|
|
CoglPipelineFilter min_filter,
|
|
|
|
CoglPipelineFilter mag_filter);
|
Adds a CoglMaterial abstraction, which includes support for multi-texturing
My previous work to provide muti-texturing support has been extended into
a CoglMaterial abstraction that adds control over the texture combine
functions (controlling how multiple texture layers are blended together),
the gl blend function (used for blending the final primitive with the
framebuffer), the alpha function (used to discard fragments based on
their alpha channel), describing attributes such as a diffuse, ambient and
specular color (for use with the standard OpenGL lighting model), and
per layer rotations. (utilizing the new CoglMatrix utility API)
For now the only way this abstraction is exposed is via a new
cogl_material_rectangle function, that is similar to cogl_texture_rectangle
but doesn't take a texture handle (the source material is pulled from
the context), and the array of texture coordinates is extended to be able
to supply coordinates for each layer.
Note: this function doesn't support sliced textures; supporting sliced
textures is a non trivial problem, considering the ability to rotate layers.
Note: cogl_material_rectangle, has quite a few workarounds, for a number of
other limitations within Cogl a.t.m.
Note: The GLES1/2 multi-texturing support has yet to be updated to use
the material abstraction.
2008-12-11 15:11:30 -05:00
|
|
|
|
2010-03-22 09:33:55 -04:00
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_set_layer_point_sprite_coords_enabled:
|
|
|
|
* @pipeline: a #CoglHandle to a pipeline.
|
2010-03-22 09:33:55 -04:00
|
|
|
* @layer_index: the layer number to change.
|
|
|
|
* @enable: whether to enable point sprite coord generation.
|
|
|
|
* @error: A return location for a GError, or NULL to ignore errors.
|
|
|
|
*
|
|
|
|
* When rendering points, if @enable is %TRUE then the texture
|
|
|
|
* coordinates for this layer will be replaced with coordinates that
|
|
|
|
* vary from 0.0 to 1.0 across the primitive. The top left of the
|
|
|
|
* point will have the coordinates 0.0,0.0 and the bottom right will
|
|
|
|
* have 1.0,1.0. If @enable is %FALSE then the coordinates will be
|
|
|
|
* fixed for the entire point.
|
|
|
|
*
|
|
|
|
* This function will only work if %COGL_FEATURE_POINT_SPRITE is
|
|
|
|
* available. If the feature is not available then the function will
|
|
|
|
* return %FALSE and set @error.
|
|
|
|
*
|
|
|
|
* Return value: %TRUE if the function succeeds, %FALSE otherwise.
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
2010-03-22 09:33:55 -04:00
|
|
|
*/
|
|
|
|
gboolean
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_set_layer_point_sprite_coords_enabled (CoglPipeline *pipeline,
|
2010-03-22 09:33:55 -04:00
|
|
|
int layer_index,
|
|
|
|
gboolean enable,
|
|
|
|
GError **error);
|
|
|
|
|
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_get_layer_point_sprite_coords_enabled:
|
|
|
|
* @pipeline: a #CoglHandle to a pipeline.
|
2010-03-22 09:33:55 -04:00
|
|
|
* @layer_index: the layer number to check.
|
|
|
|
*
|
|
|
|
* Gets whether point sprite coordinate generation is enabled for this
|
|
|
|
* texture layer.
|
|
|
|
*
|
|
|
|
* Return value: whether the texture coordinates will be replaced with
|
|
|
|
* point sprite coordinates.
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
2010-03-22 09:33:55 -04:00
|
|
|
*/
|
|
|
|
gboolean
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_get_layer_point_sprite_coords_enabled (CoglPipeline *pipeline,
|
2010-03-22 09:33:55 -04:00
|
|
|
int layer_index);
|
|
|
|
|
2010-08-01 18:05:28 -04:00
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_get_layer_wrap_mode_s:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
2010-08-01 18:05:28 -04:00
|
|
|
* @layer_index: the layer number to change.
|
|
|
|
*
|
|
|
|
* Returns the wrap mode for the 's' coordinate of texture lookups on this
|
|
|
|
* layer.
|
|
|
|
*
|
|
|
|
* Return value: the wrap mode for the 's' coordinate of texture lookups on
|
|
|
|
* this layer.
|
|
|
|
*
|
|
|
|
* Since: 1.6
|
|
|
|
*/
|
2010-10-27 13:54:57 -04:00
|
|
|
CoglPipelineWrapMode
|
|
|
|
cogl_pipeline_get_layer_wrap_mode_s (CoglPipeline *pipeline,
|
2010-08-01 18:05:28 -04:00
|
|
|
int layer_index);
|
|
|
|
|
2010-04-01 06:31:33 -04:00
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_set_layer_wrap_mode_s:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
2010-04-01 06:31:33 -04:00
|
|
|
* @layer_index: the layer number to change.
|
|
|
|
* @mode: the new wrap mode
|
|
|
|
*
|
|
|
|
* Sets the wrap mode for the 's' coordinate of texture lookups on this layer.
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
2010-04-01 06:31:33 -04:00
|
|
|
*/
|
|
|
|
void
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_set_layer_wrap_mode_s (CoglPipeline *pipeline,
|
2010-04-01 06:31:33 -04:00
|
|
|
int layer_index,
|
2010-10-27 13:54:57 -04:00
|
|
|
CoglPipelineWrapMode mode);
|
2010-04-01 06:31:33 -04:00
|
|
|
|
2010-08-01 18:05:28 -04:00
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_get_layer_wrap_mode_t:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
2010-08-01 18:05:28 -04:00
|
|
|
* @layer_index: the layer number to change.
|
|
|
|
*
|
|
|
|
* Returns the wrap mode for the 't' coordinate of texture lookups on this
|
|
|
|
* layer.
|
|
|
|
*
|
|
|
|
* Return value: the wrap mode for the 't' coordinate of texture lookups on
|
|
|
|
* this layer.
|
|
|
|
*
|
|
|
|
* Since: 1.6
|
|
|
|
*/
|
2010-10-27 13:54:57 -04:00
|
|
|
CoglPipelineWrapMode
|
|
|
|
cogl_pipeline_get_layer_wrap_mode_t (CoglPipeline *pipeline,
|
2010-08-01 18:05:28 -04:00
|
|
|
int layer_index);
|
|
|
|
|
|
|
|
|
2010-04-01 06:31:33 -04:00
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_set_layer_wrap_mode_t:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
2010-04-01 06:31:33 -04:00
|
|
|
* @layer_index: the layer number to change.
|
|
|
|
* @mode: the new wrap mode
|
|
|
|
*
|
|
|
|
* Sets the wrap mode for the 't' coordinate of texture lookups on this layer.
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
2010-04-01 06:31:33 -04:00
|
|
|
*/
|
|
|
|
void
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_set_layer_wrap_mode_t (CoglPipeline *pipeline,
|
2010-04-01 06:31:33 -04:00
|
|
|
int layer_index,
|
2010-10-27 13:54:57 -04:00
|
|
|
CoglPipelineWrapMode mode);
|
2010-04-01 06:31:33 -04:00
|
|
|
|
2010-08-01 18:05:28 -04:00
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_get_layer_wrap_mode_p:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
2010-08-01 18:05:28 -04:00
|
|
|
* @layer_index: the layer number to change.
|
|
|
|
*
|
|
|
|
* Returns the wrap mode for the 'p' coordinate of texture lookups on this
|
|
|
|
* layer.
|
|
|
|
*
|
|
|
|
* Return value: the wrap mode for the 'p' coordinate of texture lookups on
|
|
|
|
* this layer.
|
|
|
|
*
|
|
|
|
* Since: 1.6
|
|
|
|
*/
|
2010-10-27 13:54:57 -04:00
|
|
|
CoglPipelineWrapMode
|
|
|
|
cogl_pipeline_get_layer_wrap_mode_p (CoglPipeline *pipeline,
|
2010-08-01 18:05:28 -04:00
|
|
|
int layer_index);
|
|
|
|
|
2010-07-02 08:33:06 -04:00
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_set_layer_wrap_mode_p:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
2010-07-02 08:33:06 -04:00
|
|
|
* @layer_index: the layer number to change.
|
|
|
|
* @mode: the new wrap mode
|
|
|
|
*
|
|
|
|
* Sets the wrap mode for the 'p' coordinate of texture lookups on
|
|
|
|
* this layer. 'p' is the third coordinate.
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
2010-07-02 08:33:06 -04:00
|
|
|
*/
|
|
|
|
void
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_set_layer_wrap_mode_p (CoglPipeline *pipeline,
|
2010-07-02 08:33:06 -04:00
|
|
|
int layer_index,
|
2010-10-27 13:54:57 -04:00
|
|
|
CoglPipelineWrapMode mode);
|
2010-07-02 08:33:06 -04:00
|
|
|
|
2010-04-01 06:31:33 -04:00
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_set_layer_wrap_mode:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
2010-04-01 06:31:33 -04:00
|
|
|
* @layer_index: the layer number to change.
|
|
|
|
* @mode: the new wrap mode
|
|
|
|
*
|
2010-07-02 08:33:06 -04:00
|
|
|
* Sets the wrap mode for all three coordinates of texture lookups on
|
|
|
|
* this layer. This is equivalent to calling
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_set_layer_wrap_mode_s(),
|
|
|
|
* cogl_pipeline_set_layer_wrap_mode_t() and
|
|
|
|
* cogl_pipeline_set_layer_wrap_mode_p() separately.
|
2010-04-01 06:31:33 -04:00
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
2010-04-01 06:31:33 -04:00
|
|
|
*/
|
|
|
|
void
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_set_layer_wrap_mode (CoglPipeline *pipeline,
|
2010-04-01 06:31:33 -04:00
|
|
|
int layer_index,
|
2010-10-27 13:54:57 -04:00
|
|
|
CoglPipelineWrapMode mode);
|
2010-05-26 06:33:32 -04:00
|
|
|
|
|
|
|
#ifdef COGL_ENABLE_EXPERIMENTAL_API
|
|
|
|
|
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_set_depth_test_enabled:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
2010-05-26 06:33:32 -04:00
|
|
|
* @enable: The enable state you want
|
|
|
|
*
|
|
|
|
* Enables or disables depth testing according to the value of
|
|
|
|
* @enable.
|
|
|
|
*
|
|
|
|
* If depth testing is enable then the #CoglDepthTestFunction set
|
2010-10-27 13:54:57 -04:00
|
|
|
* using cogl_pipeline_set_depth_test_function() us used to evaluate
|
2010-05-26 06:33:32 -04:00
|
|
|
* the depth value of incoming fragments against the corresponding
|
|
|
|
* value stored in the current depth buffer, and if the test passes
|
|
|
|
* then the fragments depth value is used to update the depth buffer.
|
|
|
|
* (unless you have disabled depth writing via
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_set_depth_writing_enabled ())
|
2010-05-26 06:33:32 -04:00
|
|
|
*
|
|
|
|
* By default depth testing is disabled.
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
2010-07-09 10:59:14 -04:00
|
|
|
* Stability: Unstable
|
2010-05-26 06:33:32 -04:00
|
|
|
*/
|
|
|
|
void
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_set_depth_test_enabled (CoglPipeline *pipeline,
|
2010-05-26 06:33:32 -04:00
|
|
|
gboolean enable);
|
|
|
|
|
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_get_depth_test_enabled:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
2010-05-26 06:33:32 -04:00
|
|
|
*
|
|
|
|
* Gets the current depth test enabled state as previously set by
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_set_depth_test_enabled().
|
2010-05-26 06:33:32 -04:00
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Returns: The pipeline's current depth test enabled state.
|
|
|
|
* Since: 2.0
|
2010-07-09 10:59:14 -04:00
|
|
|
* Stability: Unstable
|
2010-05-26 06:33:32 -04:00
|
|
|
*/
|
|
|
|
gboolean
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_get_depth_test_enabled (CoglPipeline *pipeline);
|
2010-05-26 06:33:32 -04:00
|
|
|
|
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_set_depth_writing_enabled:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
2010-05-26 06:33:32 -04:00
|
|
|
* @enable: The enable state you want
|
|
|
|
*
|
|
|
|
* Enables or disables depth buffer writing according to the value of
|
|
|
|
* @enable. Normally when depth testing is enabled and the comparison
|
|
|
|
* between a fragment's depth value and the corresponding depth buffer
|
|
|
|
* value passes then the fragment's depth is written to the depth
|
|
|
|
* buffer unless writing is disabled here.
|
|
|
|
*
|
|
|
|
* By default depth writing is enabled
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
2010-07-09 10:59:14 -04:00
|
|
|
* Stability: Unstable
|
2010-05-26 06:33:32 -04:00
|
|
|
*/
|
|
|
|
void
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_set_depth_writing_enabled (CoglPipeline *pipeline,
|
2010-05-26 06:33:32 -04:00
|
|
|
gboolean enable);
|
|
|
|
|
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_get_depth_writing_enabled:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
2010-05-26 06:33:32 -04:00
|
|
|
*
|
|
|
|
* Gets the depth writing enable state as set by the corresponding
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_set_depth_writing_enabled.
|
2010-05-26 06:33:32 -04:00
|
|
|
*
|
|
|
|
* Returns: The current depth writing enable state
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
2010-07-09 10:59:14 -04:00
|
|
|
* Stability: Unstable
|
2010-05-26 06:33:32 -04:00
|
|
|
*/
|
|
|
|
gboolean
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_get_depth_writing_enabled (CoglPipeline *pipeline);
|
2010-05-26 06:33:32 -04:00
|
|
|
|
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_set_depth_test_function:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
2010-05-26 06:33:32 -04:00
|
|
|
* @function: The #CoglDepthTestFunction to set
|
|
|
|
*
|
|
|
|
* Sets the #CoglDepthTestFunction used to compare the depth value of
|
|
|
|
* an incoming fragment against the corresponding value in the current
|
|
|
|
* depth buffer.
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
2010-07-09 10:59:14 -04:00
|
|
|
* Stability: Unstable
|
2010-05-26 06:33:32 -04:00
|
|
|
*/
|
|
|
|
void
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_set_depth_test_function (CoglPipeline *pipeline,
|
2010-05-26 06:33:32 -04:00
|
|
|
CoglDepthTestFunction function);
|
|
|
|
|
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_get_depth_test_function:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
2010-05-26 06:33:32 -04:00
|
|
|
*
|
|
|
|
* Gets the current depth test enable state as previously set via
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_set_depth_test_enabled().
|
2010-05-26 06:33:32 -04:00
|
|
|
*
|
|
|
|
* Returns: The current depth test enable state.
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
2010-07-09 10:59:14 -04:00
|
|
|
* Stability: Unstable
|
2010-05-26 06:33:32 -04:00
|
|
|
*/
|
|
|
|
CoglDepthTestFunction
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_get_depth_test_function (CoglPipeline *pipeline);
|
2010-05-26 06:33:32 -04:00
|
|
|
|
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_set_depth_range:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
2010-06-18 10:33:03 -04:00
|
|
|
* @near_val: The near component of the desired depth range which will be
|
2010-05-26 06:33:32 -04:00
|
|
|
* clamped to the range [0, 1]
|
2010-06-18 10:33:03 -04:00
|
|
|
* @far_val: The far component of the desired depth range which will be
|
2010-05-26 06:33:32 -04:00
|
|
|
* clamped to the range [0, 1]
|
|
|
|
* @error: location to store an error of type #CoglError
|
|
|
|
*
|
|
|
|
* Sets the range to map depth values in normalized device coordinates
|
|
|
|
* to before writing out to a depth buffer.
|
|
|
|
*
|
|
|
|
* After your geometry has be transformed, clipped and had perspective
|
|
|
|
* division applied placing it in normalized device
|
|
|
|
* coordinates all depth values between the near and far z clipping
|
|
|
|
* planes are in the range -1 to 1. Before writing any depth value to
|
|
|
|
* the depth buffer though the value is mapped into the range [0, 1].
|
|
|
|
*
|
|
|
|
* With this function you can change the range which depth values are
|
|
|
|
* mapped too although the range must still lye within the range [0,
|
|
|
|
* 1].
|
|
|
|
*
|
|
|
|
* If your driver does not support this feature (for example you are
|
|
|
|
* using GLES 1 drivers) then this will return %FALSE and set an error
|
|
|
|
* if @error isn't NULL. You can check ahead of time for the
|
|
|
|
* %COGL_FEATURE_DEPTH_RANGE feature with cogl_features_available() to
|
|
|
|
* know if this function will succeed.
|
|
|
|
*
|
|
|
|
* By default normalized device coordinate depth values are mapped to
|
|
|
|
* the full range of depth buffer values, [0, 1].
|
|
|
|
*
|
|
|
|
* Returns: %TRUE if driver support is available else %FALSE.
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
2010-07-09 10:59:14 -04:00
|
|
|
* Stability: Unstable
|
2010-05-26 06:33:32 -04:00
|
|
|
*/
|
|
|
|
gboolean
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_set_depth_range (CoglPipeline *pipeline,
|
2010-06-18 10:33:03 -04:00
|
|
|
float near_val,
|
|
|
|
float far_val,
|
2010-05-26 06:33:32 -04:00
|
|
|
GError **error);
|
|
|
|
|
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_get_depth_range_mapping:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
2010-06-18 10:33:03 -04:00
|
|
|
* @near_val: A pointer to store the near component of the depth range
|
|
|
|
* @far_val: A pointer to store the far component of the depth range
|
2010-05-26 06:33:32 -04:00
|
|
|
*
|
|
|
|
* Gets the current range to which normalized depth values are mapped
|
|
|
|
* before writing to the depth buffer. This corresponds to the range
|
2010-10-27 13:54:57 -04:00
|
|
|
* set with cogl_pipeline_set_depth_range().
|
2010-05-26 06:33:32 -04:00
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
2010-07-09 10:59:14 -04:00
|
|
|
* Stability: Unstable
|
2010-05-26 06:33:32 -04:00
|
|
|
*/
|
|
|
|
void
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_get_depth_range (CoglPipeline *pipeline,
|
2010-06-18 10:33:03 -04:00
|
|
|
float *near_val,
|
|
|
|
float *far_val);
|
2010-05-26 06:33:32 -04:00
|
|
|
|
2010-07-05 16:33:26 -04:00
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* CoglPipelineLayerCallback:
|
|
|
|
* @pipeline: The #CoglPipeline whos layers are being iterated
|
2010-07-05 16:33:26 -04:00
|
|
|
* @layer_index: The current layer index
|
2010-10-27 13:54:57 -04:00
|
|
|
* @user_data: The private data passed to cogl_pipeline_foreach_layer()
|
2010-07-05 16:33:26 -04:00
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* The callback prototype used with cogl_pipeline_foreach_layer() for
|
|
|
|
* iterating all the layers of a @pipeline.
|
2010-07-05 16:33:26 -04:00
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
2010-07-05 16:33:26 -04:00
|
|
|
* Stability: Unstable
|
|
|
|
*/
|
2010-10-27 13:54:57 -04:00
|
|
|
typedef gboolean (*CoglPipelineLayerCallback) (CoglPipeline *pipeline,
|
2010-07-05 16:33:26 -04:00
|
|
|
int layer_index,
|
|
|
|
void *user_data);
|
|
|
|
|
|
|
|
/**
|
2010-10-27 13:54:57 -04:00
|
|
|
* cogl_pipeline_foreach_layer:
|
|
|
|
* @pipeline: A #CoglPipeline object
|
|
|
|
* @callback: A #CoglPipelineLayerCallback to be called for each layer
|
2010-07-05 16:33:26 -04:00
|
|
|
* index
|
|
|
|
* @user_data: Private data that will be passed to the callback
|
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Iterates all the layer indices of the given @pipeline.
|
2010-07-05 16:33:26 -04:00
|
|
|
*
|
2010-10-27 13:54:57 -04:00
|
|
|
* Since: 2.0
|
2010-07-05 16:33:26 -04:00
|
|
|
* Stability: Unstable
|
|
|
|
*/
|
|
|
|
void
|
2010-10-27 13:54:57 -04:00
|
|
|
cogl_pipeline_foreach_layer (CoglPipeline *pipeline,
|
|
|
|
CoglPipelineLayerCallback callback,
|
2010-07-05 16:33:26 -04:00
|
|
|
void *user_data);
|
|
|
|
|
2010-05-26 06:33:32 -04:00
|
|
|
#endif /* COGL_ENABLE_EXPERIMENTAL_API */
|
|
|
|
|
2008-12-22 11:19:49 -05:00
|
|
|
G_END_DECLS
|
|
|
|
|
2010-10-27 13:54:57 -04:00
|
|
|
#endif /* __COGL_PIPELINE_H__ */
|