Re: [fltk.opengl] Fl_Gl_Window flashes on context creation (Windows7)
On 04/09/13 23:24, Ivan Nedrehagen wrote: I also suspect that there might be problems replicating this bug, so I will try to do some digging of my own. Since I have built the FLTK library on my own, I might tinker a bit with the source and might run a strace (or windows equiv.) on the glut demos and the fltk demos to see if there might be a difference. Yes, strace might be good, and also I think there's a way to view the X11 messages going back and forth.. It might be as easy as setting an environment variable, or attaching a program to the process or some such.. can't remember. Sometimes just running the app through a remote xsession would let you sniff the X11 network messages (ethereal, or wireshark, or whatever its called these days which sniffs network packets and deconstructs them at the protocol level into meaningful messages. Used this once to solve an STR a few years ago where our code was creating zero sized windows IIRC) ___ fltk-opengl mailing list fltk-opengl@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-opengl
Re: [fltk.opengl] Fl_Gl_Window flashes on context creation (Windows7)
On 04/09/13 10:07, Ivan Nedrehagen wrote: Which version of FLTK (1.3.1, 1.3.2..) I use FLTK 1.3.2 Also: do the FLTK opengl test programs cube.exe and shape.exe exhibit this same behavior? Yes they do. Right, good to know. I cannot replicate with Win7 + mingw-64 (gcc4.5.2) + fltk 1.3.x-svn current; I am using the 4.7.2 rev 9 with Win 7 Hardware is a mac mini running win7/64 ultimate, default drivers. I use a Dell precision What does this means in terms of the graphics card? Those specifics are probably useful to help replicate. I don't have any dell equipment here (though one of the other devs might), but depending on the graphics, that might help zero it in. I am wondering about the drivers also, but I cannot say for sure. I did upgrade my drivers before posting just to make sure, but still it is strange that I cannot see this behaviour on any other opengl program. I did download and compile freeglut, their demos run smooth without any problems. I see. Well, you could open an STR with all the details we've found to date. It's going to be a problem though if the devs can't replicate. If you're able to identify the issue, supply a patch, or at least let us know what changes the problem if you try messing around with the FLTK innards. You may find something in the FLTK opengl win32 initialization code that needs adjusting. You might try tweaking the freeglut examples to enable features FLTK is enabling (double buffer mode, etc) to see if you can perhaps replicate the problem outside FLTK, to see if it's a particular opengl feature causing the problem. ___ fltk-opengl mailing list fltk-opengl@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-opengl
Re: [fltk.opengl] Fl_Gl_Window flashes on context creation (Windows7)
On 04/02/13 02:28, Ivan Nedrehagen wrote: Does anyone know how I can get the Fl_Gl_Window to play nicely in windows? Which version of FLTK (1.3.1, 1.3.2..) Also: do the FLTK opengl test programs cube.exe and shape.exe exhibit this same behavior? I cannot replicate with Win7 + mingw-64 (gcc4.5.2) + fltk 1.3.x-svn current; your app opens right up, no weird behavior while it opens. Same with the cube.exe and shape.exe demos. Hardware is a mac mini running win7/64 ultimate, default drivers. If you're getting this behavior with all the GL demos, try downloading GLUT and see if their demos do it too. If so, it's probably your GL drivers. If not, let us know.. ___ fltk-opengl mailing list fltk-opengl@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-opengl
Re: [fltk.opengl] Can Use GLSL in FLTK?
On 12/10/12 01:34, Sepehr Aryani wrote: Hi, I'm wondering if we can use GLSL in fltk application. I also want to know which version of OpenGL FLTK support. If there is a sample code to help I'll appreciate. I don't think there are any modern versions of openGL that FLTK /doesn't/ support, so it should work with whatever version you have. FLTK generally only gets involved to establish the openGL context. From there, all your openGL calls go directly to the openGL library, not through FLTK, which should mean any extensions to openGL (such as GLSL) should be supported without any special coding in FLTK. So in other words it should just work. If it doesn't, let us know. ___ fltk-opengl mailing list fltk-opengl@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-opengl
Re: [fltk.opengl] FLTK Written With OpenGL?
On 10/08/12 10:53, Mike Werner wrote: FLTK widgets can appear *around* an opengl drawing area, but not inside it. I make extensive use of the Fl_Gl_Window widget. In fact I actually do place widgets INSIDE the OpenGL window. They don't visually 'appear' because the OGL graphics is written on top of them. However they provide useful functionality. For example I often split the GL window into 3 or 4 viewports. To 'activate' a viewport the user left clicks anywhere inside it. This is implemented by putting a large FLTK button under the entire viewport with an appropriate callback. That should be ok if you make the fltk widget invisible The docs only warn about mixing fltk drawing with the opengl window: From: http://fltk.org/doc-1.3/classFl__Gl__Window.html#details Please note that the FLTK drawing and clipping functions will not work inside an Fl_Gl_Window. All drawing should be done using OpenGL calls exclusively. To make a widget invisible but still active, I think you can just call the widget's clear_visible(), Fl_Widget's base class method. But you're right, there are times where it's OK to have FLTK widgets overlap with opengl; one technique is to make a giant invisible Fl_Menu_Button over the entire window to easily get a right-click menu over the entire window. Works even for an opengl app IIRC. The popup menu draws OK because it's really handled as a separate window in the window manager, so there's no cross over of fltk drawing code with opengl; they're in separate windows. But to just detect a left click, I'd probably go the route of adding a handle() method to my gl window class and have it look for left click events, avoiding the use of an FLTK widget altogether. ___ fltk-opengl mailing list fltk-opengl@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-opengl
Re: [fltk.opengl] FLTK Written With OpenGL?
On 10/06/12 16:25, Mike Werner wrote: On 10/05/12 16:03, Mike Werner wrote: I'm fairly sure FLTK is written with OpenGL. FLTK supports opengl, but does not use it for implementing widgets. For that, FLTK uses the native graphics libraries: Linux: Xlib Windows: Win32 OSX: Cocoa This allows FLTK apps that don't need openGL to run on machines that don't have openGL. That's a surprise. Yep -- the FLTK widgets are native drawing code. OpenGL is simply supported as a feature, implementing opengl as a special rectangular area into which only opengl drawing can be done. FLTK widgets can appear *around* an opengl drawing area, but not inside it. For instance, the FLTK 'cube' demo has two opengl areas inside a single FLTK window; the fltk widgets are positioned /between/ the two opengl areas. The widgets can control operations that happen inside the opengl areas, but FLTK widgets themselves can't be positioned /inside/ the opengl rectangular regions, that I know of. There is probably no reason FLTK couldn't provide widgets that are opengl specific, but currently there are none that I know of that are included with the distro. There might be third party extensions, though. I thought FLTK widgets were created using the OpenGL graphics library. I just checked the FLTK docs introduction to make sure it is correct. Quoting the first page of the Introduction to FLTK under 'Features': http://fltk.org/doc-1.3/intro.html Written directly atop core libraries (Xlib, WIN32 or Cocoa) for maximum speed, and carefully optimized for code size and performance. ..which is correct. But perhaps elsewhere on that page, one of the mentions of openGL might seem to indicate FLTK was /implemented/ with openGL, though that's not the case. For instance, perhaps this sentence on that same page under History of FLTK is the one that confused you: The need to switch to OpenGL and GLX, portability, and a desire to use C++ subclassing required a rewrite of Forms. This produced the first version of FLTK. I could see reading that and thinking, 'oh, they wanted to switch to opengl to implement FLTK to make it more portable than Forms.', when that's not actually the case. Probably a small fix or two to the wording could clarify that, eg: The need to *support* OpenGL and GLX, offer portability across platforms, and a desire to use C++ subclassing required a rewrite of Forms. This produced the first version of FLTK... If there are other parts of the docs that gave the impression of FLTK being implemented as opengl, let us know. ___ fltk-opengl mailing list fltk-opengl@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-opengl
Re: [fltk.opengl] FLTK Written With OpenGL?
On 10/05/12 16:03, Mike Werner wrote: I'm fairly sure FLTK is written with OpenGL. FLTK supports opengl, but does not use it for implementing widgets. For that, FLTK uses the native graphics libraries: Linux: Xlib Windows: Win32 OSX: Cocoa This allows FLTK apps that don't need openGL to run on machines that don't have openGL. But I wanted to check on this forum. Is it so? If I understand your question correctly, no -- fltk's widgets are not all implemented in opengl. But fltk provides a way for apps to use openGL, so that one can have FLTK widgets around opengl windows in which your opengl can run. If so, what version of OpenGL? In the way that FLTK lets you use opengl within your fltk app, it will use whatever openGL installation is available on the end user's machine. When you compile an FLTK app that uses opengl, you would need to have an opengl development environment available on the machine, and the end users would need opengl on the machines that run your FLTK/opengl app. For regular FLTK apps that don't use opengl, you don't need an opengl environment (FLTK and non-opengl FLTK apps can build just fine without it), and end user machines don't need openGL for the non-opengl FLTK apps to run. When you write an FLTK app that uses openGL, your app is making direct calls to the openGL library.. FLTK's job is to provide you an openGL window into which you can make your opengl calls. ___ fltk-opengl mailing list fltk-opengl@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-opengl
Re: [fltk.opengl] OpenGL window in Fl_Wizard
On 05/18/12 23:21, david_ai...@yahoo.com wrote:
hi all..
I would like to place an OpenGL window into a wizard, but I'm new to fltk so
my source has some problems.
You need to create the opengl window inside the first group.
So just move this line from where it is:
mygl = new MyGlWindow(10, 10, W-20, H-80);
..over to here:
// Wizard: page 1
{
// **
// 1. OpenGL window. Want this to appear only in page 1.
// Currently it overlaps on top of the Fl_Multiline_Output
// windows.
// **
Fl_Group *g = new Fl_Group(0, H-60, W, 60);
mygl = new MyGlWindow(10, 10, W-20, H-80); MOVE HERE
Fl_Button *next = new Fl_Button(290,H-30,100,25,Next);
next-callback(next_cb);
g-end();
}
This ensures the window will be attached (parented)
to that first group that comprises the first wizard page.
___
fltk-opengl mailing list
fltk-opengl@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-opengl
Re: [fltk.opengl] OpenGL window in Fl_Wizard
On 05/18/12 23:21, david_ai...@yahoo.com wrote:
1. the OpenGL window overlaps all of the wizard pages. It should only appear
on the first page.
Oh, and besides moving the creation of the window,
I think your Fl_Group's are oddly positioned.
Can you say why you're using:
Fl_Group *g = new Fl_Group(0, H-60, W, 60);
:
Fl_Group *g = new Fl_Group(0, H-60, W, 60);
:
Fl_Group *g = new Fl_Group(0, H-60, W, 60);
..instead of:
Fl_Group *g = new Fl_Group(0, 0, W, H);
:
Fl_Group *g = new Fl_Group(0, 0, W, H);
:
Fl_Group *g = new Fl_Group(0, 0, W, H);
I think if you use the latter, and the mod in my last post,
things will work.
I think if you were to change the box() type for your
groups to FL_FLAT_BOX and set the color() to FL_RED,
you'd see where the groups were being positioned, and
why you were getting strange drawing artifacts.
(children should be positioned within Fl_Group,
and if they are positioned outside of it, they draw oddly)
FWIW, the following works for me, and can be compiled
with 'fltk-config --compile -use-gl foo.cxx'.
Changed the casing on some of the include files
to get it to build on linux (which cares about case).
I'm only resolving question #1 and #3, #2 is a separate
issue that is pretty well covered elsewhere on resizable()
behavior, eg: http://fltk.org/articles.php?L415
-
#include stdlib.h
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Gl_Window.H
#include FL/Fl_Group.H
#include FL/Fl_Wizard.H
#include FL/Fl_Button.H
#include FL/Fl_Multiline_Output.H
#include FL/gl.h
class MyGlWindow : public Fl_Gl_Window {
// FIX OPENGL VIEWPORT
// Do this on init or when window's size is changed
void FixViewport(int W,int H) {
glLoadIdentity();
glViewport(0,0,W,H);
glOrtho(-W,W,-H,H,-1,1);
}
// DRAW METHOD
void draw() {
if (!valid()) { valid(1); FixViewport(w(), h()); } // first time?
init
// Clear screen to bg color
glClearColor(0, 0, 0, 0);
glClear(GL_COLOR_BUFFER_BIT);
// Draw 'X' in fg color
glColor3f(1, 1, 1);
glBegin(GL_LINE_STRIP); glVertex2f(w(), h()); glVertex2f(-w(),-h());
glEnd();
glBegin(GL_LINE_STRIP); glVertex2f(w(),-h()); glVertex2f(-w(), h());
glEnd();
}
// HANDLE WINDOW RESIZING
void resize(int X,int Y,int W,int H) {
Fl_Gl_Window::resize(X,Y,W,H);
FixViewport(W,H);
redraw();
}
public:
// OPENGL WINDOW CONSTRUCTOR
MyGlWindow(int X,int Y,int W,int H,const char*L=0) :
Fl_Gl_Window(X,Y,W,H,L) {
end();
}
};
Fl_Wizard *G_wiz = 0;
void back_cb(Fl_Widget*,void*) {
G_wiz-prev();
}
void next_cb(Fl_Widget*,void*) {
G_wiz-next();
}
void done_cb(Fl_Widget*,void*) {
exit(0);
}
class MyAppWindow : public Fl_Window {
MyGlWindow *mygl;// opengl window
public:
// APP WINDOW CONSTRUCTOR
MyAppWindow(int W,int H,const char*L=0) : Fl_Window(W,H,L) {
G_wiz = new Fl_Wizard(0,0,W,H);
// Wizard: page 1
{
Fl_Group *g = new Fl_Group(0, 0, W, H);
Fl_Button *next = new Fl_Button(290,H-30,100,25,Next);
next-callback(next_cb);
mygl = new MyGlWindow(10, 10, W-20, H-80);
g-end();
}
// Wizard: page 2
G_wiz-begin();
{
Fl_Group *g = new Fl_Group(0,0,W,H);
Fl_Button *next = new Fl_Button(290,H-30,100,25,Next);
next-callback(next_cb);
Fl_Button *back = new Fl_Button(120,H-30,100,25,Back);
back-callback(back_cb);
Fl_Multiline_Output *out = new
Fl_Multiline_Output(10,30,W-20,H-80,Terms And Conditions);
out-labelsize(20);
out-align(FL_ALIGN_TOP|FL_ALIGN_LEFT);
out-value(This is the Second page);
g-end();
}
G_wiz-end();
// Wizard: page 3
G_wiz-begin();
{
Fl_Group *g = new Fl_Group(0,0,W,H);
Fl_Button *done = new Fl_Button(290,H-30,100,25,Finish);
done-callback(done_cb);
Fl_Button *back = new Fl_Button(120,H-30,100,25,Back);
back-callback(back_cb);
Fl_Multiline_Output *out = new
Fl_Multiline_Output(10,30,W-20,H-80,Finish);
out-labelsize(20);
out-align(FL_ALIGN_TOP|FL_ALIGN_LEFT);
out-value(This is the Last page);
g-end();
}
G_wiz-end();
end();
}
};
// Simple 'wizard' using fltk's new Fl_Wizard widget
Fl_Window *G_win = 0;
int main(int argc, char **argv) {
int w = 500, h=300;
G_win = new MyAppWindow(w,h,Example Wizard);
G_win-resizable(G_win);
G_win-end();
Re: [fltk.opengl] GL windows in Fl_Tile
On 12/16/11 00:07, Robert Strickland wrote: Thank you so much for your help. Changing from Fl_Window to Fl_Group did the trick. I don't think I would have figured this out on my own. Your FLTK Cheat pages are a tremendous resource. Thanks for creating and posting them. Without them, I wouldn't have had a clue about how to get started with this. Cool -- glad it helps! I use it all the time myself. Thanks also for moderating the forum. Ha, I don't actually moderate it, I'm just a frequent poster and dev. Mike (Sweet) is the moderator, though I think managing CUPS has been keeping him busy (you can see his activity over on cups.general on this same NNTP server) About the +1/-1 offsets on the yellow borders: without any +1 or -1, I get a yellow outline on two sides of the box only, the right and bottom. The way I had it (with the lopsided offsets) just fixed the top and left sides that weren't drawn (on linux, anyway) without disturbing the two sides that were drawn. I'll try again tomorrow on Windows. Hmm, I was testing on linux (64bit) myself; with your example, only saw yellow lines on two sides with 1.3.x. Strange we're having different results on the same OS. Might be some floating point fun going on there, not sure. ___ fltk-opengl mailing list fltk-opengl@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-opengl
Re: [fltk.opengl] GL windows in Fl_Tile
I wouldn't derive from Fl_Window, as that implies your
coordinate space origin gets reset to zero. Changed that
to Fl_Group.
Also, fixed your yellow borders a bit; your code wasn't
consistent with the +1/-1 offsets to keep the border onscreen.
Revised code; see CHANGED lines:
---
/**
Test by Robert Strickland to tile four OpenGL windows.
Based on Erco's cheat:
http://seriss.com/people/erco/fltk/#GL4PortResizable
but without the code to do the proportional resizing
*/
#include FL/Fl.H
#include FL/Fl_Double_Window.H
#include FL/Fl_Tile.H
#include FL/Fl_Gl_Window.H
#include FL/gl.h
/**
A Fl_Gl_Window that draws an X in a box
*/
class FLGL : public Fl_Gl_Window {
public:
FLGL(int x, int y, int w, int h, const char* l=0) :
Fl_Gl_Window(x, y, w, h, l) {
end();
}
protected:
void draw() {
if ( !valid() ) {
// First time? init viewport, etc.
valid(1);
glLoadIdentity();
glViewport(0, 0, w(), h());
glOrtho(-w(), w(), -h(), h(), -1, 1);
}
// Clear screen
glClear(GL_COLOR_BUFFER_BIT);
// Draw white 'X'
glColor3f(1.0, 1.0, 1.0);
glBegin(GL_LINES);
glVertex2f( w(), h());
glVertex2f(-w(), -h());
glVertex2f( w(), -h());
glVertex2f(-w(), h());
glEnd();
// Draw yellow border last, around the outer edge
glColor3f(1.0, 1.0, 0.0);
glBegin(GL_LINE_LOOP);
glVertex2f(-w()+1, -h()+1); // CHANGED
glVertex2f( w()-1, -h()+1); // CHANGED
glVertex2f( w()-1, h()-1); // CHANGED
glVertex2f(-w()+1, h()-1); // CHANGED
glEnd();
}
};
/**
A container for a FLGL window that leaves room for a border
*/
class Viewport : public Fl_Group { // CHANGED: Window - Group
protected:
FLGL *gl;
public:
Viewport(int x, int y, int w, int h, const char* l=0) :
Fl_Group(x, y, w, h, l) { // CHANGED: Window - Group
box(FL_DOWN_FRAME);
gl = new FLGL( x+10, y+10, w-20, h-20 );// CHANGED: x,y,w,h
resizable(gl);
end();
}
};
/**
A 2x2 tile of OpenGL windows in Viewport containers with borders
*/
class Layout:public Fl_Tile {
private:
Viewport *view[4];
public:
Layout(int x, int y, int w, int h) : Fl_Tile(x, y, w, h) {
box(FL_DOWN_BOX);
color(FL_RED); // (shouldn't be seen)
// Create the 4 Viewports
int k = 0;
for (int j = 0; j 2; j++) {
for (int i = 0; i 2; i++) {
view[k] = new Viewport(i*200, j*200, 200, 200);
view[k]-box(FL_DOWN_BOX);
view[k]-color(9+k);
view[k]-align(FL_ALIGN_CLIP);
k++;
}
}
end();
}
};
int main() {
Fl_Double_Window *win = new Fl_Double_Window(400, 400, gltileb);
Layout *layout = new Layout(0, 0, win-w(), win-h());
win-resizable(layout);
win-end();
win-show();
return(Fl::run());
}
// End of test code
___
fltk-opengl mailing list
fltk-opengl@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-opengl
Re: [fltk.opengl] Problems mixing GLUT FLTK
On 06/02/11 09:57, joe wrote: I'm having some problems mixing GLUT FLTK I mix FLTK and GLUT in my larger graphics simulations. But I don't use GLUT to manage the windows. I'd suggest you use FLTK to manage windows. Thanks you for replying but it's my first approach to this stuff and I'm not very expert :) Can you please explain with more details? Or can you post some examples.. There's an example here of using glut to create a sphere, but FLTK for everything else: http://seriss.com/people/erco/fltk/#OpenGLSphereWithLight That's the typical use of GLUT in FLTK apps; to access the opengl shortcuts that you would normally have to do in raw opengl code (eg. glutSolidSphere()) GLUT's edict is to serve two purposes: 1) Provide simple cross platform window and event management so that one can build simple standalone opengl apps that don't depend on other libraries besides opengl. 2) Supply some neat opengl shortcut functions (such as creating spheres) to make opengl examples easier to write. FLTK has #1 covered, so if you're using FLTK, you wouldn't use GLUT to do the #1 stuff. But the features GLUT provides in #2 can be useful inside FLTK apps. FLTK can provide an opengl window via Fl_Gl_Window, in which you can do normal opengl programming. GLUT has some cool opengl convenience functions that makes sense to use inside the Fl_Gl_Window; usually things you just don't want to code in raw opengl, because GLUT already provides an easy to use interface for them. But you should /avoid/ using GLUT calls that try to do anything with the event queue or window management. eg. glutCreateWindow(), glutIdleFunc(), etc.. in an FLTK app, those would compete for window manager and device event management (mouse/keyboard) causing havoc. showing how to embed a GLUT window into a FLTK window? I'd avoid going there; this is asking for trouble because both FLTK and GLUT will compete for the window manager and event queue resources. Better to use an FLTK GL window, and use opengl oriented GLUT calls that don't involve event or window management. ___ fltk-opengl mailing list fltk-opengl@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-opengl
Re: [fltk.opengl] how to use glutWire* functions ?
Greg Ercolano wrote:
I could probably make it work if I made it more like the fractal.cxx
program where the fltk widgets are in an FLTK window, and the glut stuff
in a separate window. Might try that next.
I translated this into a pure glut application, and it runs fine.
So this verifies glut is OK. (In this case, no linkage to FLTK
is needed at all. Not really useful for debugging the problem
but at least verifies the example code and glut is OK)
jseb; I'm guessing the problem might be in fltk2's own glutInit()
that is omitting something that the real glut library wants set.
I'd suggest waiting for others to reply, and if they can't help,
log an STR against FLTK2.
#ifdef _WIN32
#include windows.h
#endif
#include math.h
#include GL/glut.h
#define WIDTH 640
#define HEIGHT 480
//
// Render a simple opengl shaded sphere with a single side light -- erco
11/28/08
// pure glut version (no FLTK linkage needed) -- erco 03/14/11
//
// RESHAPE THE VIEWPORT
void Reshape(int W, int H) {
// (REFERENCE: SGI light.c DEMO)
GLfloat ratio = (float)W / (float)H;
glViewport(0, 0, (GLsizei)W, (GLsizei)H);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glOrtho(-1.5*ratio, 1.5*ratio, -1.5, 1.5, -10.0, 10.0);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
}
void Redraw() {
static int valid = 0;
if (!valid) {
valid = 1;
Reshape(WIDTH, HEIGHT);
// (REFERENCE: SGI 'light.c' EXAMPLE)
GLfloat mat_ambient[]= { 1.0, 1.0, 1.0, 1.0 }; // RGBA
GLfloat mat_diffuse[]= { 1.0, 1.0, 1.0, 1.0 }; // RGBA
GLfloat mat_specular[] = { 1.0, 1.0, 1.0, 1.0 }; // RGBA
GLfloat light_position[] = { 5.0, 5.0, 0.0, 0.0 }; // XYZ
glClearColor(0.0, 0.0, 0.4, 0.0); // bg color
glShadeModel(GL_SMOOTH);
//
glMaterialfv(GL_FRONT, GL_AMBIENT, mat_ambient);
glMaterialfv(GL_FRONT, GL_DIFFUSE, mat_diffuse);
glMaterialfv(GL_FRONT, GL_SPECULAR, mat_specular);
glMaterialf(GL_FRONT, GL_SHININESS, 20.0);
glLightfv(GL_LIGHT0, GL_POSITION, light_position);
//
glEnable(GL_LIGHTING);
glEnable(GL_LIGHT0);
glEnable(GL_DEPTH_TEST);
}
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
glPushMatrix();
glColor3f(0.5, 0.5, 0.5);
glutSolidSphere(0.5, 30, 30);
glPopMatrix();
}
int main(int argc, char *argv[]) {
glutInit(argc, argv);
glutInitWindowSize(WIDTH, HEIGHT);
glutCreateWindow(sphere);
glutReshapeFunc(Reshape);
glutDisplayFunc(Redraw);
glutMainLoop();
return(0);
}
___
fltk-opengl mailing list
fltk-opengl@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-opengl
Re: [fltk.opengl] how to use glutWire* functions ?
Albrecht Schlosser wrote: On 13.03.2011 11:20, jseb wrote: I put a freeglut window in fltk gui. I think FLTK has its own glut interface via #include FL/glut.H See below. And when executing: freeglut ERROR: Function glutWireSphere called without first calling 'glutInit'. Did you try to call glutInit ? If i remove the call to glutWireSphere, everything is right. I don't have any knowledge about glut etc., but I hope that I can help anyway. There are two example programs that ought to work, but I see different code. :-( One is calling glutInit, whereas the other doesn't. Please take a look at those, maybe it can help. Do they work for you? There's some info here regarding whether to call glutInit() or not: http://www.fltk.org/doc-1.3/glut.html Here's an example I wrote using FLTK's glut; might be a good starting point: http://seriss.com/people/erco/fltk/#OpenGLSphereWithLight ___ fltk-opengl mailing list fltk-opengl@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-opengl
Re: [fltk.opengl] how to use glutWire* functions ?
Greg Ercolano wrote:
Maybe show us your FLTK2 translated sphere.cxx file.
I decided to take a shot at translating this example to FLTK2.
I'm not sure if it's right because I get the same error you do,
with or without the glutInit() call, and no matter where I put it in main().
With this code I'm trying to use FLTK2 to completely handle the
windows, and calling fltk::run().
I could probably make it work if I made it more like the fractal.cxx
program where the fltk widgets are in an FLTK window, and the glut stuff
in a separate window. Might try that next.
In this case I created foo.cxx in the FLTK2 test directory
and used a modified version of the glpuzzle build flags
(by commenting out .SILENT in the makeinclude and rebuilding it,
then changing all instances of glpuzzle - foo)
g++ -I.. -I../fltk/compat -O2 -Wall -Wunused -I/usr/include/freetype2
-Wno-non-virtual-dtor -c foo.cxx
g++ foo.o ../lib/libfltk2_glut.a -L../lib -lfltk2_gl -lfltk2 -lGLU -lGL -lX11
-lXi -lXinerama -lXft -lpthread -lm -lXext -lsupc++ -lglut -o foo
Here's my first shot at translating to FLTK2.
It builds with no errors, but dies with the glutInit() error
at runtime. (A window does briefly open).
---
#ifdef _WIN32
#include windows.h
#endif
#include math.h
#include fltk/glut.h // changed for fltk
#include fltk/DoubleBufferWindow.h
#include fltk/GlWindow.h
#include fltk/run.h
//
// Render a simple opengl shaded sphere with a single side light -- erco
11/28/08
// translated to fltk2 -- erco 03/14/11
//
// NOTE: Glut needed *only* for glutSolidSphere()
//
class MyGlWindow : public fltk::GlWindow {
public:
// RESHAPE THE VIEWPORT
void Reshape(GLfloat W, GLfloat H) {
// (REFERENCE: SGI light.c DEMO)
GLfloat ratio = W / H;
glViewport(0, 0, (GLsizei)W, (GLsizei)H);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glOrtho(-1.5*ratio, 1.5*ratio, -1.5, 1.5, -10.0, 10.0);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
}
void draw() {
if (!valid()) {
valid(1);
Reshape(w(), h());
// (REFERENCE: SGI 'light.c' EXAMPLE)
GLfloat mat_ambient[]= { 1.0, 1.0, 1.0, 1.0 }; // RGBA
GLfloat mat_diffuse[]= { 1.0, 1.0, 1.0, 1.0 }; // RGBA
GLfloat mat_specular[] = { 1.0, 1.0, 1.0, 1.0 }; // RGBA
GLfloat light_position[] = { 5.0, 5.0, 0.0, 0.0 }; // XYZ
glClearColor(0.0, 0.0, 0.4, 0.0); // bg color
glShadeModel(GL_SMOOTH);
//
glMaterialfv(GL_FRONT, GL_AMBIENT, mat_ambient);
glMaterialfv(GL_FRONT, GL_DIFFUSE, mat_diffuse);
glMaterialfv(GL_FRONT, GL_SPECULAR, mat_specular);
glMaterialf(GL_FRONT, GL_SHININESS, 20.0);
glLightfv(GL_LIGHT0, GL_POSITION, light_position);
//
glEnable(GL_LIGHTING);
glEnable(GL_LIGHT0);
glEnable(GL_DEPTH_TEST);
}
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
glPushMatrix();
glColor3f(0.5, 0.5, 0.5);
glutSolidSphere(0.5, 30, 30);
glPopMatrix();
}
// CTOR
MyGlWindow(int X,int Y,int W,int H,const char*L=0) :
fltk::GlWindow(X,Y,W,H,L) {
}
};
int main(int argc, char *argv[]) {
fltk::DoubleBufferWindow dwin(640, 480, sphere);
dwin.begin();
MyGlWindow mygl(10, 10, dwin.w()-20, dwin.h()-20);
dwin.end();
dwin.resizable(mygl);
dwin.show();
fprintf(stderr, CALLING GLUT INIT\n);
glutInit(argc,argv);
return(fltk::run());
}
___
fltk-opengl mailing list
fltk-opengl@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-opengl
Re: [fltk.opengl] How to clear fl_gl_window when a button is click
Giau P wrote: Hello, Can any one tell me how to clear my window to redraw something new? I have a class which inherits from Fl_Gl_Window. I can draw on it but when a button is click, I need to clear the the window to redraw with new data populated when a button is click. glClear() is what you'd want I think. http://www.opengl.org/sdk/docs/man3/xhtml/glClear.xml You can look at this simple FLTK/OpenGL example which shows how playing with an FLTK widget can affect redrawing the gl window: http://seriss.com/people/erco/fltk/#OpenGlSimpleWidgets ___ fltk-opengl mailing list fltk-opengl@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-opengl
Re: [fltk.opengl] Frozen screen after a lock-unlock computer
Bruno Pospichil wrote: I had a issue using a Fl_Gl_Window inherited class. The screen is shown but, if I lock and unlock the screen (I’m using Windows 7) the Fl_Gl_Window is shown frozen. If I ask to redraw, the issue is fixed and the application still working. There is a way to force the redraw when I unlock the OS? (Or other fix/workaround for this issue) It certainly should redraw automatically. Which version of FLTK, and which compiler was used to build it? Offhand it kinda sounds like a driver issue. I just tried having the test/glpuzzle demo open from FLTK 1.1.10 and FLTK 1.3.x, then locked the screen (using META-l) then logged back in, and the puzzles were both drawn OK. Do you have the problem you're reporting with the glpuzzle demo? If not, can you post a simple (one page) compilable example program that makes a window + gl window using the same technique your larger program does.. examples: http://seriss.com/people/erco/fltk/#OpenGlSimple http://seriss.com/people/erco/fltk/#OpenGLSphereWithLight Assuming you can replicate with something like that, post it here so we can try to replicate. ___ fltk-opengl mailing list fltk-opengl@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-opengl
Re: [fltk.opengl] Best way to manage scaling?
Some examples of opengl window initialization code here, in case you're concerned about window width/height affecting scaling (shouldn't be an issue): SIMPLE: http://seriss.com/people/erco/fltk/#OpenGlSimple CHECKERED TEXTURE CUBE (NO LIGHTING) http://seriss.com/people/erco/fltk/#OpenGLTextureMap TEXTURE MAPPED CUBE WITH MATERIALS/LIGHTING: http://seriss.com/people/erco/fltk/#OpenGLTextureMappedImage http://seriss.com/people/erco/fltk/image-texturemapped-cube.cxx If there's a group of objects you want to scale, you can parent an extra matrix to them so that they can all be controlled by a single matrix (eg. scales) You can also zoom the objects on Z, but that has a side effect of distortion due to perspective projection. I usually always just scale the object. I think you can also play with the camera's projection calculations. Usually precision issues are due to being 'too close' to the object, or having some situation with the camera and object sizes that cause precision loss in the resulting projection calculations. As far as precision issues are concerned, usually it takes a little work to figure out the concatenation of the matrix hierarchy and camera projection to figure out why you're getting loss or 'roughness' in precision. I rarely run into that. It's usually gimble lock I'm concerned about. Usually prec loss has to do with scene using values that are at extreme limits that pushes the limits of the projection floating point calculations. If you have an example of /compilable/ code (a small single C++ file) that shows the issue, we can probably give more info on how to avoid. Try to simplify as much as possible. rogx.libero wrote: Dear Fltk friends, I'm trying to write a very little 3D engine, to use it for a very very simple CAD (points, lines, planes, axis and opengl triangles or quads) and Kinematic simulator(with 2 kind of links, prismatic and revolution, You can simulate 99% of numerical control machines). I am not sure wath may be the best way to manage scaling, including the ratio between w() and h() of the Fl_Gl_Window. My first try is to do most in the MODELVIEW matrix, as You can read in The camera analogy (a paper from SGI). My need is to have the maximum precision (specially in the rotation part of the matrix), for objects that may go from mm 100 to mm 1. ___ fltk-opengl mailing list fltk-opengl@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-opengl
Re: [fltk.opengl] Shaders
Paul Blythe wrote: [..] when I call glCreateShader I get an exception. This is normally the result of the opengl context not being setup before the call, but I am calling it in the draw method, so the opengl context must be set. Be sure its inside the valid() check section of the draw() code, and be sure all glBegin() and glEnd()s' are closed before the call. Post a simple but compilable example along the lines of eg: http://seriss.com/people/erco/fltk/#OpenGlSimple Let us know the platform as well. ___ fltk-opengl mailing list fltk-opengl@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-opengl
Re: [fltk.opengl] CallBack
Loic wrote:
Hi all,
sorry for spamming, but I have an other problem...
I change my code to include a menubar. (as in the example)
my old code :
---
Fl_Window* window = new Fl_Window(0,0,WINDOW_WIDTH,WINDOW_HEIGHT, FROG
Displayer);
window-end();
window-resizable(window);
window-show();
while(window-shown()){
Fl::check();
window-redraw();
}
---
Has been changed to
---
Fl_Window* window = new Fl_Window(0,0,WINDOW_WIDTH,WINDOW_HEIGHT+20, FROG
Displayer_Main);
FROG_MainWindow* frog_window = new
FROG_MainWindow(0,20,WINDOW_WIDTH,WINDOW_HEIGHT, FROG Displayer);
frog_window-end();
frog_window-resizable(frog_window);
frog_window-show();
frog_window-end();
Fl_Menu_Bar* menubar = new Fl_Menu_Bar(0,0,WINDOW_WIDTH,20);
menubar-menu(menutable);
menubar-callback(test_cb);
menubar-show();
window-end();
window-resizable(window);
window-show();
while(window-shown()){
Fl::check();
frog_window-redraw();
}
---
But the callback get crazy...
for mouse callback everything seems to be fine...
but for keyboard callback..
Hmm, what's a keyboard callback mean in this context?
To read the keyboard you usually have to setup a handle()
to trap events, unless I'm forgetting something. Or maybe
you've got keyboard shortcuts enabled for certain menu items,
but that should trigger the same callback as the mouse, so
it'd be odd if one worked and the other did not.
either the program crashes or it does nothing (while it is suppose to do
something with the key pressed).
Hard to tell from the code you've posted, as it's missing what's
going on in the callback and menutable, which is where the problem
likely lies.
If it crashes, it might be the menutable isn't NULL terminated
correctly..
or the callback is doing something it shouldn't with the widget or
userdata
pointers.
Building the menutable is a careful business to do manually -- usually
I only let fluid handle building menu tables, as submenus need special
extra NULL terminations, IIRC.
I prefer to use menubar-add() to build a menubar in contexts outside
of fluid, eg:
menubar-add(File/Save, ..);
menubar-add(File/Save As, ..);
menubar-add(File/Quit, ..);
menubar-add(Edit/Copy, ..);
For more info, see this example:
http://seriss.com/people/erco/fltk/#Fl_Menu_Bar_Single_Callback
BTW, since this is most likely a non-opengl issue, it's better
to use fltk.general for this kinda stuff; you'll get more replies,
and the back+forths will be more useful to folks on that group.
Try running the debugger to see where it crashes..
___
fltk-opengl mailing list
fltk-opengl@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-opengl
Re: [fltk.opengl] Please help with OpenGL error!
Emil wrote: I do get this kind of errors with all FLTK OpenGl programs! Is this a bug or somethig is bad in my system? I run on my laptop Slackware Linux 12.2, my video drivers are instaled (Intel GM965). And I have tried the example with FLTK2 too, the same problem. By the way, I forgot to write what the same example was running well before I have installed some programs for openbox (PIL etc.). OK! I have fixed this problem. I have just installed Mesa! Yes, based your image showing horizontal black bands running through not only your app, but also your unix terminal window as well would seem to indicate either a graphics driver issue or a problem with the opengl install. The window manager shouldn't let an app's artifacts leak into other windows unless the drivers had been compromised in some way. Glad you figured it out. ___ fltk-opengl mailing list fltk-opengl@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-opengl
Re: [fltk.opengl] Can't get context on OS X?
Christian Convey wrote:
I'm porting to OS X 10.5 an app that works just fine on Linux. I'm using
FLTK 1.1.7.
We have a class (MarineViewer) that subclasses from Fl_Gl_Window. In
MarineViewer's constructor, we have this code:
m_textures = new GLuint[1];
...
glGenTextures(1, m_textures);
The call to glGenTextures is generating a bus error. I think it's related to
something I found while debugging: If I call this-context() from within
that same constructor, I get back the value NULL. I assume this means that
for some reason, FLTK isn't able to get an OpenGL context for my program to
use.
Any idea why I might be seeing this? Any idea how I can fix it?
If the code you're running needs a valid gl context, try moving
this code to the !valid() section of your draw() method, eg:
void MarineViewer::draw() {
if ( ! valid() ) {
..
glGenTextures(1, m_textures);
..
}
}
By that time FLTK will have created the actual window and context.
I'm thinking FLTK doesn't actually create the GL window/context
until after the constructors have been called, and the program
has started the FLTK event loop.
___
fltk-opengl mailing list
fltk-opengl@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-opengl
Re: [fltk.opengl] gl_font not affecting text size
Kevin Cockrell wrote: gl_font(FL_HELVETICA, 18); But I can't seem to get anything to affect the size of the font. Can't say for sure, but I do know if I change the gl_font(1,12) in this program: http://seriss.com/people/erco/fltk/#OpenGlTextOn3D ..to gl_font(1,24), the font is definitely larger. Might have something to do with the placement in your code, or the order of gl calls, hare to say. Works for me in fltk-1.1.x on fedora3. ___ fltk-opengl mailing list fltk-opengl@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-opengl
Re: [fltk.opengl] menu and redraw()
Kevin Cockrell wrote: Hi, I setup a very simple fltk GUI with Fl_Window that has a Fl_Menu_Bar and an Fl_Gl_Window. I have the following items in my menu (which is called mbar): mbar-add(ChangeSquareColors/Make Square Red, 'r', (Fl_Callback*)TopSide_GUI::cb_MakeSquareRed, (void*)0, 0); mbar-add(ChangeSquareColors/Make Square Blue, 'b', (Fl_Callback*)TopSide_GUI::cb_MakeSquareBlue, (void*)0, 0); Inside of my Fl_Gl_Window draw() function, I just draw a square that is red or blue according to a variable that is set with the callback functions from the menu. But I am running into something that confuses me. If I use a mouse to click on the menu and choose one of the items, then it automatically calls the draw() function of my Fl_Gl_Window. But if I use the shortcuts 'r' or 'b', it changes the local variable but does not call the draw() function. Why is clicking on the menu different than using the kayboard shortcuts? When you click on the menu, the menu is probably posting over the opengl window, damaging it. When the menu clears, fltk tells the damaged widget (the opengl window) to redraw. Keyboard shortcuts don't post damaging graphics, so no redraw is needed. If your callback is changing things in the opengl window, then you'll need to force a redraw for the opengl widget to force it to redraw; to do that, use yourglwindow-redraw(); in your callback after making the color change. This will schedule FLTK to redraw the widget, which it should do when you return from the callback. And how does my Fl_Menu_Bar know that there is a Fl_Gl_Window to draw? This seems very weird to me... The menubar doesn't; FLTK does. FLTK knows about all the widgets, and is responsible for managing redrawing them in the correct order. ___ fltk-opengl mailing list fltk-opengl@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-opengl
