On Tue, 14 Nov 2006 10:42:55 +0100,
Rene Jensen <[EMAIL PROTECTED]> wrote :
> Simon, thanks, it worked!
>
> Next I'll see how well one can get away with mixing Etk with this.
> With a little luck it is just a matter of calling glViewport and
> glScissor before painting (and resetting them again afterwards of
> course).
Here is a really simple code that shows how to make it work in
Etk. It's still heavy experimentation, really dirty and it has some
problems.
To make it work, you still need the Evas patch (the flush callback
thing) and the latest Etk to have the GL-X11 engine of Etk (I've just
committed it).
To compile it:
gcc -o etk_gl_proto etk_gl_proto.c `etk-config --libs --cflags` -Wall
-lGL -lGLU
and to execute it, you have to say to the app that you'd like to use
the GL-X11 engine, so the command is:
./etk_gl_proto --etk-engine=ecore_evas_gl_x11
It should work but it's a bit buggy (probably because I don't reset all
the GL states before drawing the cube, so sometimes blending is
enabled, sometimes scissor-test is enabled, ... it would be useful to
have a command to reset all the GL-states to their default value...)
> I know this is a hack, but experimentation first, then we can start
> thinking about a clean solution that is OK with the lead developers.
A way to make it cleaner and more generic would be to do as Jose said:
render the OpenGL scene in a buffer, and render the buffer content in
an Evas image. This should even be compatible with all the engines, but
it may be a lot slower (I don't know, I never did something like that).
Simon
>
> Regards
> Rene
>
>
>
> Simon TRENY wrote:
> > Here is a fixed version of the test code. It fixes the back-face
> > culling and some glPush/Pop*() bugs.
> >
> > Simon
> >
> >
> > On Sun, 12 Nov 2006 18:21:09 +0100,
> > Simon TRENY <[EMAIL PROTECTED]> wrote :
> >
> >
> >> Hi Rene,
> >>
> >> The main problem we have here is that what you'd like to do is
> >> definitely engine-specific whereas Evas tends to abstract totally
> >> the engine layer. Anyway, with some Evas engines it should be
> >> quite easy to use OpenGL to render 3D stuff. Here is how to do it
> >> with the GL-X11 engine of Evas (which is obviously the most
> >> appropriate engine to do that since it already provides the GL
> >> context).
> >>
> >> So, with the GL-X11 engine of Evas, all you have to do basically
> >> is to call all your OpenGL functions before glXSwapBuffers() gets
> >> called. glXSwapBuffers() is called by the output_flush() method of
> >> the GL-X11 engine, which is called by
> >> evas_render_updates_internal(). So the problem is that we need to
> >> be somehow notified before evas_render_updates_internal() calls
> >> the output_flush() method, and, for now, there is no way to do
> >> that. I have written a small patch for Evas to add a callback
> >> called each time before output_flush() is called. The function to
> >> set this callback is evas_flush_callback_set(). The Evas patch is
> >> joined with this email (this patch should not be applied to the
> >> CVS repository of Evas, it's a quick'n'dirty hack!!).
> >>
> >> Now, all you have to do is to make the calls to the OpenGL
> >> functions in the "flush-callback". I have attached a a small code
> >> that shows how to do it. It's totally dirty and hacky but it works
> >> quite well :) There is just a small problem with the Zbuffer of
> >> with the backbface culling I guess (the cube looks weird...), but
> >> it shouldn't be hard to fix. To compile this code, you have to
> >> apply the patch to Evas, and to compile it with:
> >> gcc -o evas_gl_proto evas_gl_proto.c `ecore-config --cflags --libs`
> >> -lGL -lGLU -Wall
> >>
> >>
> >> Note that the GL engine of Evas has some serious problems though.
> >> Here is a list of the know problems written by raster some times
> >> ago:
> >>> 1. a font with glyphs > 256x256 pixels will just break.
> >>> 2. images that are bigger than max texture size simply won't show
> >>> (need to build a mesh)
> >>> 3. cards that don't support rectangular textures will end up with
> >>> nasty scaling results when scaling "stretched" or "squashed"
> >>> mostly in 1 dimension (mipmap issues basically when used for 2d)
> >>> 4. scaling down even with smooth scaling is ugly (need to use
> >>> anisotropic filtering if possible)
> >>> 5. doesn't support destination alpha (easy-ish to fix)
> >>> 6. need pbuffer support implemented for the future (we need to be
> >>> able to render to an intermediate buffer)
> >>> 7. if the window is fullscreen glx may choose to do page flipping
> >>> not copy from back to front buffer. in this case evas's assumption
> >>> that the buffer was exactly as it left it when it last rendered is
> >>> wrong - as it actually is as it was rendered 2 frames ago, not the
> >>> last frame.
> >>>
> >> There is also a problem when you have several windows using the GL
> >> engine in your program, but I think it's probably a problem with
> >> Ecore_Evas_GL. The Glitz engine that raster seems to be writting
> >> should fix most of these problems :)
> >>
> >>
> >> Regards :)
> >> Simon
> >>
> >>
> >>
> >>
> >> On Sun, 12 Nov 2006 12:40:37 +0100,
> >> Rene Jensen <[EMAIL PROTECTED]> wrote :
> >>
> >>
> >>> WARNING: LONG POST AHEAD...
> >>>
> >>> (Sigh) After having posted on both IRC and the webforum, I get
> >>> the distinct feeling that this community has been worn down by
> >>> daft requests for getting fancy window drawing using OpenGL.
> >>>
> >>> This is a serious shame because now even the smallest utterance of
> >>> that API makes it's author look guilty. The developers forget that
> >>> end-users asking for something XGL'ish is a far cry from
> >>> application developers asking for their favorite API for
> >>> graphics/GLGPU programming, which they need to make video/3D
> >>> applications using Ewl/Etk.
> >>>
> >>> However, as an application developer, I feel that:
> >>>
> >>> 1) Etk/Edje is perfect for the job. The efficiency is the reason I
> >>> am choosing E if I can get away with it in the first place. I
> >>> need a strong and themable GUI. I *LOVE* Efl's well-organized
> >>> style!
> >>>
> >>> 2) The window manager and graphics lib should NOT squander my
> >>> precious GPU cycles on needless features. If I could make a 3D in
> >>> a console window, I'd do that.
> >>>
> >>> 3) An extra GL layer is actually another source of errors! Once I
> >>> made a small 3D paint-program that used GL for the painting
> >>> procedures, http://artcamilla.dk/centipede. I spend a LOT of time
> >>> tracking down a bug in Windows where I use Nvidias desktop
> >>> switcher. All that was drawn on my screen was a frame delayed.
> >>> Turned out that when I switched off the desktop switcher or even
> >>> turned off screen rotation (I have a tablet-pc), the bug
> >>> dissappeared. Wasn't in my program after all. Incidently, the
> >>> above mentioned program used my own OpenGL based mini-GUI. Guess
> >>> why I am looking for another GUI with a strong support of
> >>> themes ;-)
> >>>
> >>> 4) It will be hard to write any program at all in the video/3D
> >>> industry without having support for OpenGL.
> >>>
> >>> --------------------------------
> >>>
> >>> Ok, enough ranting. This is a verbatim copy of the forum post I
> >>> made few days ago. By the end of this mail, I have already
> >>> answered some of it:
> >>>
> >>> --------------------------------
> >>>
> >>> I've learned that OpenGL requests falls in two camps this place:
> >>> Those for a way to put Evas into OpenGL (for kicks), and those
> >>> for a way to put OpenGL into Evas/Etk (for making any kind of
> >>> serious multimedia program). This post belongs in the latter camp.
> >>>
> >>> Without in any way claiming to be a proficient E programmer, I've
> >>> taken the liberty to scout for the possibility of drawing 3D in
> >>> ETK, since it appears to be a non-existing feature right now.
> >>> Hope I won't make too big a fool of myself ;-)
> >>>
> >>> Basically all that is needed to be able to draw using opengl in X
> >>> is the creation of a GL context using GLX. The only thing
> >>> required is that you have a handle to an X drawable (Window or
> >>> Pixmap). I can see that in E getting this handle is less obvious,
> >>> since E is unaware of a specific render-backend. Opposite GTK
> >>> which has an X Window for each widget, ETK renders each element
> >>> directly to a buffer, and only this grand superbuffer has an
> >>> associated Window - if using some kind of X11 backend of course.
> >>> If I read the code correctly, the Evas software-X11 backend
> >>> actually renders to a pixbuf in shared-memory.
> >>>
> >>> So far so good. I traced this Drawable to a function called
> >>> 'eng_setup', which is handed an X Drawable (amongst other things).
> >>> Though I can't see where this Drawable is created since I don't
> >>> know who CALLS eng_setup, I guess it would still be possible to
> >>> get the super-drawable somehow.
> >>>
> >>> So I guess that in order to get OpenGL support in ETK, three
> >>> things are needed:
> >>>
> >>> 1) Access the Drawable for the root Evas (if using X11/GLX) or a
> >>> Window (if using GDI/WGL on windows)
> >>>
> >>> 2) Knowledge about where in the root-evas the widget which on
> >>> which OpenGL drawing should occur is placed.
> >>>
> >>> 3) Cooperation from ETK: It shouldn't paint anything to update
> >>> that widget and it should make it possible to emit a "paint"
> >>> signal so the user can emit the proper set of OpenGL commands.
> >>>
> >>> Getting 2. to work should be easy. Accessing the Drawable in 1 is
> >>> not at all impossible either, I guess. (save the Drawable in a
> >>> global var in some of the E libraries and get it through a
> >>> function. As to 3., it is more of a mystery exactly how, but
> >>> perhaps somebody sees the light more clearly.
> >>>
> >>> Before I go on, I'd like your sentiments on this
> >>> request/suggestion. Presumable somebody will cry: "No way! E has
> >>> nothing to do with OpenGL period! This would violate the API which
> >>> is totally architecture agnostic, you ignorant philistine", which
> >>> is a perfectly adult way of opening this interesting discussion.
> >>> Other people may ask why I am not simply using this ...XXX...
> >>> GL-widget. I certainly hope that happens ;-)
> >>>
> >>>
> >>> --------------------------------
> >>>
> >>> And a few more thoughts (and solutions) I have since made:
> >>>
> >>> 1) I can see a problem if Evas uses some form of buffering. Then
> >>> you need to pump out the data from the GL context. This may not be
> >>> as slow as it sounds on modern architectures and if the updating
> >>> of the cache doesn't happen every time a single bit has been
> >>> changed.
> >>>
> >>> 2) A spin on the above. In case Evas buffers use that cache, it is
> >>> going to be hard to emit some kind of "paint" signal which will be
> >>> needed to draw opengl into the canvas. However I studied Evas'
> >>> code and I can see that the engine-module simply get a
> >>>
> >>> eng_image_draw (in modules/engines/gl_x11/evas_engine.c)
> >>>
> >>> which converts into a
> >>>
> >>> evas_gl_common_image_draw (in
> >>> modules/engines/gl_common/evas_gl_image.c)
> >>>
> >>> In the last function, the is evident that the Image being painted
> >>> is actually a GL texture. So a quick solution could be to use GL's
> >>> recent Render-To-Texture mechanism (a.k.a Framebuffers) to make
> >>> the Image being juggled with an actual 3D image rendered at users
> >>> will (as long as (s)he remembers to tell Evas that the "image" has
> >>> changed). Not the fastest solution, but not bad either. The
> >>> programmer is unburdened with "paint" calls, and Evas is free to
> >>> repaint and buffer as it sees fit.
> >>>
> >>>
> >>> Responding to my own statements earlier:
> >>>
> >>> 1) We already have access to the Drawable from the program's main
> >>> function, which sets up the environment. I missed that because it
> >>> seems etk_init handles it. Thus etk_init needs to open up a bit.
> >>>
> >>> 2) If you use Render-To-Texture, you don't need anything from Etk
> >>> except access/modification possibility of it's GLuint that holds
> >>> the texture name
> >>>
> >>> 3) - ditto -
> >>>
> >>>
> >>> Caveat's:
> >>>
> >>> 1) You still need the GL CONTEXT that get's created. For some
> >>> reason this isn't dont in the main function, e.g.
> >>>
> >>> bin/evas_gl_x11_main.c
> >>>
> >>> 2) You need to be able to get the GLuint of an image.
> >>>
> >>> 3) This is inherently ENGINE SPECIFIC. No sense in asking for a
> >>> texture-id from a cairo backend.
> >>>
> >>>
> >>> --------------------------------
> >>>
> >>> And something completely different:
> >>>
> >>> I have good experience with OpenGL and a small GDI/GL + X/GL
> >>> cross-platform GUI behind me. I couldn't help noticing that your
> >>> Win32/GDI engine files are almost empty. Just ask if you need any
> >>> tips. I might be able to help. I also have a somewhat deep
> >>> understanding of OpenGL Framebuffer Objects and all that "weird"
> >>> OpenGL stuff.
> >>>
> >>> Oh, and don't use the GDI way of transferring buffered graphics
> >>> data to a window (Device Independent Bitmap). Slow like hell.
> >>> Either use a GL context (why not?) or DirectX. I don't know
> >>> anything about GDI+ or the new stuff from MS.
> >>>
> >>>
> >>>
> >>> Ahem, I should stop talking.
> >>>
> >>>
> >>> Regards Centipede (Rene Jensen)
> >>>
> >>>
> >>> -------------------------------------------------------------------------
> >>> Using Tomcat but need to do more? Need to support web services,
> >>> security? Get stuff done quickly with pre-integrated technology to
> >>> make your job easier Download IBM WebSphere Application Server
> >>> v.1.0.1 based on Apache Geronimo
> >>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> >>> _______________________________________________
> >>> enlightenment-devel mailing list
> >>> enlightenment-devel@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >>>
> >>>
> >>> ------------------------------------------------------------------------
> >>>
> >>> #include <stdlib.h>
> >>> #include <stdio.h>
> >>> #include <Evas.h>
> >>> #include <Ecore.h>
> >>> #include <Ecore_Evas.h>
> >>> #include <GL/gl.h>
> >>> #include <GL/glu.h>
> >>>
> >>> #define WIDTH 800
> >>> #define HEIGHT 600
> >>>
> >>> static int _animator_cb(void *data);
> >>> static void _flush_cb(Evas *e);
> >>>
> >>> int main(int argc, char *argv[])
> >>> {
> >>> Evas *e;
> >>> Ecore_Evas *ee;
> >>> Evas_Object *bg;
> >>> Evas_Object *rect;
> >>>
> >>> evas_init();
> >>> ecore_init();
> >>> ecore_evas_init();
> >>>
> >>> ee = ecore_evas_gl_x11_new(NULL, 0, 0, 0, WIDTH, HEIGHT);
> >>> ecore_evas_size_min_set(ee, WIDTH, HEIGHT);
> >>> ecore_evas_size_max_set(ee, WIDTH, HEIGHT);
> >>> e = ecore_evas_get(ee);
> >>> evas_flush_callback_set(e, _flush_cb);
> >>> ecore_evas_show(ee);
> >>>
> >>>
> >>> /* We create a black background rect because Evas doesn't
> >>> clear the color buffer */ bg = evas_object_rectangle_add(e);
> >>> evas_object_color_set(bg, 0, 0, 0, 255);
> >>> evas_object_move(bg, 0, 0);
> >>> evas_object_resize(bg, WIDTH, HEIGHT);
> >>> evas_object_show(bg);
> >>>
> >>> /* The rectangle is here to show that Evas can render object
> >>> while OpenGL is also rendering */ rect =
> >>> evas_object_rectangle_add(e); evas_object_color_set(rect, 0, 200,
> >>> 180, 255); evas_object_move(rect, 10, 10);
> >>> evas_object_resize(rect, 30, 30);
> >>> evas_object_show(rect);
> >>>
> >>> /* By default, an animator is 30 times per second */
> >>> ecore_animator_frametime_set(1.0 / 60.0);
> >>> ecore_animator_add(_animator_cb, e);
> >>> ecore_main_loop_begin();
> >>>
> >>> ecore_evas_shutdown();
> >>> ecore_shutdown();
> >>> evas_shutdown();
> >>>
> >>> return 0;
> >>> }
> >>>
> >>> /* Forces Evas to redraw */
> >>> static int _animator_cb(void *data)
> >>> {
> >>> Evas *e;
> >>>
> >>> if (!(e = data))
> >>> return 1;
> >>>
> >>> evas_damage_rectangle_add(e, 0, 0, WIDTH, HEIGHT);
> >>> return 1;
> >>> }
> >>>
> >>> /* This is called before glXSwapBuffers() gets called.
> >>> * The calls to the GL API have to be placed here */
> >>> static void _flush_cb(Evas *e)
> >>> {
> >>> static float rot = 0.0;
> >>>
> >>> glPushAttrib(GL_ALL_ATTRIB_BITS);
> >>>
> >>> glEnable(GL_DEPTH_TEST);
> >>> glDepthFunc(GL_LEQUAL);
> >>> /* We have to disable the scissor test or sometimes it's not
> >>> rendered. Not sure why... */ glDisable(GL_SCISSOR_TEST);
> >>> glEnable(GL_CULL_FACE);
> >>> glCullFace(GL_BACK);
> >>>
> >>> glClear(GL_DEPTH_BUFFER_BIT);
> >>>
> >>> glMatrixMode(GL_PROJECTION);
> >>> glPushMatrix();
> >>> glLoadIdentity();
> >>> gluPerspective(45.0, (float)WIDTH / (float)HEIGHT, 0.1, 100.0);
> >>>
> >>> glMatrixMode(GL_MODELVIEW);
> >>> glPushMatrix();
> >>> glLoadIdentity();
> >>>
> >>> glTranslatef(0.0, 0.0, -5.0);
> >>> glRotatef(rot, 0.3, 0.6, 0.0);
> >>> glBegin(GL_QUADS);
> >>> /* Top of cube */
> >>> glColor3f(0.0f, 1.0f, 0.0f);
> >>> glVertex3f(1.0f, 1.0f, -1.0f);
> >>> glVertex3f(-1.0f, 1.0f, -1.0f);
> >>> glVertex3f(-1.0f, 1.0f, 1.0f);
> >>> glVertex3f(1.0f, 1.0f, 1.0f);
> >>> /* Bottom of cube */
> >>> glColor3f(1.0f, 0.5f, 0.0f);
> >>> glVertex3f(1.0f, -1.0f, 1.0f);
> >>> glVertex3f(-1.0f, -1.0f, 1.0f);
> >>> glVertex3f(-1.0f, -1.0f, -1.0f);
> >>> glVertex3f(1.0f, -1.0f, -1.0f);
> >>> /* Front of cube */
> >>> glColor3f(1.0f, 0.0f, 0.0f);
> >>> glVertex3f(1.0f, 1.0f, 1.0f);
> >>> glVertex3f(-1.0f, 1.0f, 1.0f);
> >>> glVertex3f(-1.0f, -1.0f, 1.0f);
> >>> glVertex3f(1.0f, -1.0f, 1.0f);
> >>> /* Back of cube */
> >>> glColor3f(1.0f, 1.0f, 0.0f);
> >>> glVertex3f(-1.0f, 1.0f, -1.0f);
> >>> glVertex3f(1.0f, 1.0f, -1.0f);
> >>> glVertex3f(1.0f, -1.0f, -1.0f);
> >>> glVertex3f(-1.0f, -1.0f, -1.0f);
> >>> /* Right side of cube */
> >>> glColor3f(1.0f, 0.0f, 1.0f);
> >>> glVertex3f(1.0f, 1.0f, -1.0f);
> >>> glVertex3f(1.0f, 1.0f, 1.0f);
> >>> glVertex3f(1.0f, -1.0f, 1.0f);
> >>> glVertex3f(1.0f, -1.0f, -1.0f);
> >>> /* Left side of cube */
> >>> glColor3f(0.0f, 1.0f, 1.0f);
> >>> glVertex3f(-1.0f, 1.0f, 1.0f);
> >>> glVertex3f(-1.0f, 1.0f, -1.0f);
> >>> glVertex3f(-1.0f, -1.0f, -1.0f);
> >>> glVertex3f(-1.0f, -1.0f, 1.0f);
> >>> glEnd();
> >>>
> >>> /* Restore the previous transform matrices */
> >>> glPopAttrib();
> >>> glMatrixMode(GL_PROJECTION);
> >>> glPopMatrix();
> >>> glMatrixMode(GL_MODELVIEW);
> >>> glPopMatrix();
> >>>
> >>> rot += 1.0;
> >>> }
> >>>
>
#include <Etk.h>
#include <GL/gl.h>
#include <GL/glu.h>
static void _opengl_view_realize_cb(Etk_Object *object, void *data);
static void _rotation_toggled_cb(Etk_Object *object, void *data);
static int _animator_cb(void *data);
static void _flush_cb(Evas *e);
static Etk_Widget *_opengl_view;
static Etk_Bool _rotate = ETK_TRUE;
int main(int argc, char *argv[])
{
Etk_Widget *window;
Etk_Widget *vbox;
Etk_Widget *frame;
Etk_Widget *button;
etk_init(&argc, &argv);
window = etk_window_new();
vbox = etk_vbox_new(ETK_FALSE, 0);
etk_container_add(ETK_CONTAINER(window), vbox);
frame = etk_frame_new("OpenGL View");
etk_box_append(ETK_BOX(vbox), frame, ETK_BOX_START, ETK_BOX_EXPAND_FILL, 0);
_opengl_view = etk_widget_new(ETK_WIDGET_TYPE, NULL);
etk_widget_size_request_set(_opengl_view, 240, 320);
etk_signal_connect("realize", ETK_OBJECT(_opengl_view), _opengl_view_realize_cb, NULL);
etk_container_add(ETK_CONTAINER(frame), _opengl_view);
etk_box_append(ETK_BOX(vbox), etk_hseparator_new(), ETK_BOX_START, ETK_BOX_NONE, 0);
button = etk_toggle_button_new_with_label("Stop Rotation");
etk_signal_connect("toggled", ETK_OBJECT(button), _rotation_toggled_cb, NULL);
etk_box_append(ETK_BOX(vbox), button, ETK_BOX_START, ETK_BOX_NONE, 0);
ecore_animator_frametime_set(1.0 / 60.0);
ecore_animator_add(_animator_cb, NULL);
etk_widget_show_all(window);
etk_main();
return 0;
}
/* Called when the OpenGL view is realized: we set the "flush callback" to the Evas */
static void _opengl_view_realize_cb(Etk_Object *object, void *data)
{
Evas *e;
if (!(e = etk_widget_toplevel_evas_get(ETK_WIDGET(object))))
return;
evas_flush_callback_set(e, _flush_cb);
}
/* Called when the "Stop Rotation" button is toggled */
static void _rotation_toggled_cb(Etk_Object *object, void *data)
{
_rotate = !etk_toggle_button_active_get(ETK_TOGGLE_BUTTON(object));
}
/* Forces Evas to redraw */
static int _animator_cb(void *data)
{
Evas *e;
if (!(e = etk_widget_toplevel_evas_get(_opengl_view)))
return 1;
evas_damage_rectangle_add(e, 0, 0, 1000, 1000);
return 1;
}
/* This is called before glXSwapBuffers() gets called.
* The calls to the GL API have to be placed here */
static void _flush_cb(Evas *e)
{
Etk_Geometry geometry;
static float rot = 0.0;
etk_widget_geometry_get(_opengl_view, &geometry.x, &geometry.y, &geometry.w, &geometry.h);
glPushAttrib(GL_ALL_ATTRIB_BITS);
glViewport(geometry.x, geometry.y, geometry.w, geometry.h);
glEnable(GL_DEPTH_TEST);
glDepthFunc(GL_LEQUAL);
/* We have to disable the scissor test or sometimes it's not rendered. Not sure why... */
glDisable(GL_BLEND);
glDisable(GL_SCISSOR_TEST);
glEnable(GL_CULL_FACE);
glCullFace(GL_BACK);
glClear(GL_DEPTH_BUFFER_BIT);
glMatrixMode(GL_PROJECTION);
glPushMatrix();
glLoadIdentity();
gluPerspective(45.0, (float)geometry.w / (float)geometry.h, 0.1, 100.0);
glMatrixMode(GL_MODELVIEW);
glPushMatrix();
glLoadIdentity();
glTranslatef(0.0, 0.0, -5.0);
glRotatef(rot, 0.3, 0.6, 0.0);
glBegin(GL_QUADS);
/* Top of cube */
glColor3f(0.0f, 1.0f, 0.0f);
glVertex3f(1.0f, 1.0f, -1.0f);
glVertex3f(-1.0f, 1.0f, -1.0f);
glVertex3f(-1.0f, 1.0f, 1.0f);
glVertex3f(1.0f, 1.0f, 1.0f);
/* Bottom of cube */
glColor3f(1.0f, 0.5f, 0.0f);
glVertex3f(1.0f, -1.0f, 1.0f);
glVertex3f(-1.0f, -1.0f, 1.0f);
glVertex3f(-1.0f, -1.0f, -1.0f);
glVertex3f(1.0f, -1.0f, -1.0f);
/* Front of cube */
glColor3f(1.0f, 0.0f, 0.0f);
glVertex3f(1.0f, 1.0f, 1.0f);
glVertex3f(-1.0f, 1.0f, 1.0f);
glVertex3f(-1.0f, -1.0f, 1.0f);
glVertex3f(1.0f, -1.0f, 1.0f);
/* Back of cube */
glColor3f(1.0f, 1.0f, 0.0f);
glVertex3f(-1.0f, 1.0f, -1.0f);
glVertex3f(1.0f, 1.0f, -1.0f);
glVertex3f(1.0f, -1.0f, -1.0f);
glVertex3f(-1.0f, -1.0f, -1.0f);
/* Right side of cube */
glColor3f(1.0f, 0.0f, 1.0f);
glVertex3f(1.0f, 1.0f, -1.0f);
glVertex3f(1.0f, 1.0f, 1.0f);
glVertex3f(1.0f, -1.0f, 1.0f);
glVertex3f(1.0f, -1.0f, -1.0f);
/* Left side of cube */
glColor3f(0.0f, 1.0f, 1.0f);
glVertex3f(-1.0f, 1.0f, 1.0f);
glVertex3f(-1.0f, 1.0f, -1.0f);
glVertex3f(-1.0f, -1.0f, -1.0f);
glVertex3f(-1.0f, -1.0f, 1.0f);
glEnd();
/* Restore the previous transform matrices */
glPopAttrib();
glMatrixMode(GL_PROJECTION);
glPopMatrix();
glMatrixMode(GL_MODELVIEW);
glPopMatrix();
if (_rotate)
rot += 1.0;
}
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
