> I think the way to do this is to create a new structure called
> P3_image in image.c and image.h, containing width, height, type, and
> GLubyte* pixels.
I think the P3_image is quite useless and that you can directly use P3_material
instead (since images are only used for material. oups forgotten the font but it's a
minority)
Finaly maybe it's better to have a P3_image (but I will have to recode P3_image)
If you really want to have a P3_image use the following hackish definitions (we need
less modification like that ;-):
typedef struct {
int option;
int type; /* GL_RGB or GL_RGBA or GL_LUMINANCE */
int width;
int height;
GLubyte* pixels;
} P3_image;
typedef struct {
P3_SYSTEM_OBJECT_HEADER
int option;
int type; /* GL_RGB or GL_RGBA or GL_LUMINANCE */
int width;
int height;
GLubyte* pixels;
GLuint id; /* for glBindTexture */
GLfloat shininess;
GLfloat colors[8]; /* diffuse color r,g,b,a + specular color r,g,b,a */
P3_renderer_list* r_list;
} P3_material;
#define P3_material_as_image(material) \
(&(material->option))
According to me, the best way to do this is to superclass the PyP3Material_SetImage
function in material_python.c
you can check the number of arguments given, if it's more than 1 (ie only a filename)
your suppose the user has given a string, width, height, type and flag
tell me if that's ok for you
> if the data needs to be flipped upside down
> (I believe this is needed between PIL and OpenGL?)
I don't know
> I notice that there is currently no
> P3_material_free, and freeing is handled in the Python wrapper, which
> is probably OK since the Python interface is the only place where that
> freeing should ever occur, but there *is* a P3_material_new in
> material.c, so it would kind of make sense to have a P3_material_free
> and call *that* from the Python wrapper.
you're right, that's corrected
--
Pour vous desabonner envoyez un mail a [EMAIL PROTECTED]
