Xcode + FLTK + GLUT

164 views
Skip to first unread message

Pepe Ribelles

unread,
Apr 11, 2014, 4:10:44 AM4/11/14
to fltkg...@googlegroups.com
I am working with Xcode 5.1 on Mac OS X Mavericks in a project involving OpenGL and GLUT. Now, I need to add some widgets to the interface and I would like to use FLTK. However, I have some problems.

Next is the code using just GLUT and it works (a window with a dark red background): 

#include <OpenGL/gl3.h>

#include <glut/glut.h>

#include <stdio.h>


void display (void) { 

  glClearColor (0.5,0.0,0.0,0.0);

  glClear      (GL_COLOR_BUFFER_BIT);

  glutSwapBuffers();

}


int main(int argc, char* argv[]) {

  glutInit                (&argc, argv);

  glutInitDisplayMode     (GLUT_DOUBLE | GLUT_RGBA | GLUT_3_2_CORE_PROFILE);

  glutInitWindowSize      (950, 570);

  glutInitWindowPosition  (10, 10);

  glutCreateWindow        ("GLUT Core Profile Demo");

  glutDisplayFunc         (display);

  

  printf("Version: %s\r\n",      glGetString(GL_VERSION));

  printf("Renderer: %s\r\n",     glGetString(GL_RENDERER));

  printf("Vendor: %s\r\n",       glGetString(GL_VENDOR));

  printf("GLSL Version: %s\r\n", glGetString(GL_SHADING_LANGUAGE_VERSION));  

  glutMainLoop();

  return 0;

}

And I get this output too:

Version: 3.3 ATI-8.24.11

Renderer: ATI Radeon HD 4850 OpenGL Engine

Vendor: ATI Technologies Inc.

GLSL Version: 3.30

Now I made some changes in order to add a FLTK window. When I run the code I get the window, everything is ok but the background is gray, this is the code:

#include <OpenGL/gl3.h>

#include <glut/glut.h>

#include <stdio.h>


#include <Fl/Fl.H>

#include <FL/Fl_Double_Window.H>


void display (void) {

  glClearColor (0.5,0.0,0.0,0.0);

  glClear      (GL_COLOR_BUFFER_BIT);

  glutSwapBuffers();

}


int main(int argc, char* argv[]) {

  Fl_Double_Window *window_glut = new Fl_Double_Window(970, 590);

  window_glut->end();

  window_glut->show();

  window_glut->begin();


  glutInitDisplayMode     (GLUT_DOUBLE | GLUT_RGBA | GLUT_3_2_CORE_PROFILE);

  glutInitWindowSize      (950, 570);

  glutInitWindowPosition  (10, 10);

  glutCreateWindow        ("GLUT Core Profile Demo");

  glutDisplayFunc         (display);


  window_glut->end();


  printf("Version: %s\r\n",      glGetString(GL_VERSION));

  printf("Renderer: %s\r\n",     glGetString(GL_RENDERER));

  printf("Vendor: %s\r\n",       glGetString(GL_VENDOR));

  printf("GLSL Version: %s\r\n", glGetString(GL_SHADING_LANGUAGE_VERSION));

  

  Fl::run();

  return 0;

}

Of course, the output is the same (Vendor, GLSL Version, etc.). And when I run these codes in Linux, both works well.

Hope you can help me :) 



Kevin Ingwersen

unread,
Apr 11, 2014, 3:56:46 PM4/11/14
to fltkg...@googlegroups.com
Change your openGL stuff to…

#include <FL/gl.H>
#include <FL/glut.h>
#include <…whatever you need….>

The reason is, that FLTK can automaticaly map the GL api into itself. I am using this myself to abstract the general GL api. Try it out, maybe it works! Oh, and you won’t need the fl_Double_Window…your original code should wori just fine. But if you wish to use more FLTK-ish API, then look at Fl_Gl_Window. IIRC you can obtain the GL context from that window, so you get the fltk and gl control… o.o

Just my cent~ ^^.

Kind regards, Ingwie.
--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Pepe Ribelles

unread,
Apr 12, 2014, 2:57:26 AM4/12/14
to fltkg...@googlegroups.com, ingwi...@googlemail.com
It works when I change the the #includes (I see the window with a dark red background), however the OpenGL version changes to 2.1 and GLSL 1.20 (instead of 3.3), so this solution is not good for me.

I''ll take a look to Fl_Gl_Window.

-- Jose

Pepe Ribelles

unread,
Apr 12, 2014, 3:04:49 AM4/12/14
to fltkg...@googlegroups.com, ingwi...@googlemail.com
Just the same using Fl_Gl_Window, it works but OpenGL 2.1 and GLSL 1.2.

Kevin Ingwersen

unread,
Apr 12, 2014, 9:31:46 AM4/12/14
to Pepe Ribelles, fltkg...@googlegroups.com
That is because FLTK emulates openGL. I just forgot to tell you one thing! ^^;

Fl_Window* flWin(...);
NSWindow* Win = fl_xid(flWin);
[Win DoSomethingWithIt];

Using fl_xid, you get to the native handle.  never worked with openGL myself, but maybe this is helpful for oyu? Same should work with Fl_Gl_Window.

Kind regards, Ingwie.

Pepe Ribelles

unread,
Apr 13, 2014, 9:18:59 AM4/13/14
to fltkg...@googlegroups.com
I am not very sure about how to use fl_xid. Anyway, I think the problem may be in the building of the fltk library, because the glut.framefork is not used. And this framework is needed to use opengl 3.3. Therefore, I have serious doubts I can use fltk and opengl 3.3 on mac os x.

MacArthur, Ian (Selex ES, UK)

unread,
Apr 14, 2014, 5:16:01 AM4/14/14
to fltkg...@googlegroups.com
> That is because FLTK emulates openGL. I just forgot to tell you one
> thing! ^^;


No, that's not really true.

Fltk emulates GLUT and (to some extent) GLU, but it does not emulate GL itself at all.


The reason Pepe sees GL 2.1 when fltk sets it up, rather than 3.3, is because (in very broad terms) the GL implementation you get is the GL implementation you ask for...

When it initiates GL, fltk only asks for the GL 2 API, since that was what fltk "knew", and it was a safe and widely supported option for the longest time.

(The GL API was "quiet" for a very long time, but the Khronos folks, and others, seem to have re-invigorated work in that area and the API has been evolving much faster recently.)


In general, a GL driver that knows later API versions will give you the API you ask for, however (if you ask for 2.1, you get 2.1, as fltk does, but if you ask for 3.3 then you can have that instead; or as well...)

So, if you want a later GL API, you need to start that up yourself; I'd strongly suggest using an extension wrangler (I've been using GLEW-1.10.0 myself with fltk) to enable later GL API capabilities.

Works fine.

But you need to do a bit of work yourself. GL is like that...




Selex ES Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

Pepe Ribelles

unread,
Apr 14, 2014, 3:29:31 PM4/14/14
to fltkg...@googlegroups.com, ian.ma...@selex-es.com
I am not sure FLTK is not setting up GL 3.3. 

When It runs glutInitDisplayMode(... | GLUT_3_2_CORE_PROFILE, the program does not produce errors. It works. And when I compile and link a GLSL 3.3 shader it also works. The only problem: it does not produce any render in the window. However, I think it is using the right API.

You say, I get the GL 2 API because fltk asks for this API when it initiates GL. However, this does not happen in linux where I can use fltk + glut + the lastest API (4.x). The same code. It works, it's perfect.

I am absolutely confused :-(

-- Pepe

Greg Ercolano

unread,
Apr 14, 2014, 4:07:17 PM4/14/14
to fltkg...@googlegroups.com
On 04/14/14 12:29, Pepe Ribelles wrote:
> I am not sure FLTK is not setting up GL 3.3.
>
> When It runs glutInitDisplayMode(... | GLUT_3_2_CORE_PROFILE) , the program does not produce errors. It works. And when I compile and link a GLSL 3.3 shader it also works. The only problem: it does not produce any render in the window. However, I think it is using the right API.
>
> You say, I get the GL 2 API because fltk asks for this API when it initiates GL. However, this does not happen in linux where I can use fltk + glut + the lastest API (4.x). The same code. It works, it's perfect.
>
> I am absolutely confused :-(

If you want to use fltk, then I'd suggest using FLTK
to control the windows and Fl_Gl_Window to manage the GL stuff,
and only use glut minimally for its shortcuts for things
like making shapes, and not use it for window management.

In my mind there's two ways you can go with FLTK + GLUT:

1) Mostly FLTK app that uses glut only for shortcuts, e.g.
http://seriss.com/people/erco/fltk/opengl-sphere-with-light-old.cxx
..this example uses fltk + opengl to do most everything,
and only uses glut to make the sphere object procedurally.

2) Mostly GLUT app with FLTK just to create the window.
http://seriss.com/people/erco/fltk/#OpenGLSphereWithLight
..scroll down to the "OpenGL Sphere With Light" example code
in the gray box to get that.
I don't think I'd recommend that approach though if I wanted
to mix in FLTK widgets, since FLTK will want to manage all window
events and redrawing to manage widgets.

Personally, I think the (1) approach is best, as GLUT was really
intended to demonstrate opengl by adding a simple way to get
a window on the screen and do minimal event handling just so that
opengl apps could be easily compiled without a lot of native
window management code. GLUT and FLTK are similar in that their
goal is to protect the user from having to write native window mgmt
code, to make apps simple and portable. But FLTK's goals are a bit
higher; to provide widgets.. I don't believe that's the case for glut,
so to use the higher level tool, it's best to use it to manage the app,
and leave glut to only do stuff NOT related to window management/event
management, such as shortcuts for making 3D geometry, and other such
things.
Reply all
Reply to author
Forward
0 new messages