View Full Version : Porting sequential control flow from IrisGL
12-06-2005, 06:20 AM
I have been stuck with the unfortunate job of porting some OLD Fortran 77 IrisGL code to OpenGL. I've had some success, but the big problem is the overall structure of the code. It tends to treat the graphics window as a resource that can be "drawn upon" at any time. And the control flow of the overall program is pure spaghetti in tracing down where graphics calls are made. And there are abundant reads from standard input intermingled, so that the user can direct the flow of the program.
On the other hand, OpenGL appears to only work using an "infinite MainLoop" via callbacks. I have been trying to use GLUT. I've seen where SGI's "OpenGL Porting Guide" for IrisGL also shows an example using straight X-Windows using GLX or Xt. But their example also appears to be "MainLoop" based.
So, my main question is: "Is there any way to use OpenGL using a more sequential/serial program control flow?"
12-07-2005, 03:25 PM
OpenGL works the same way IrisGL does w.r.t. drawing to the window at any time.
The only requirement is that you have a valid context and that won't change once you set it up.
OpenGL does not work in callbacks, something like GLUT gives the user a drawing callback, but that's GLUT not OpenGL. The OpenGL interface is just a low level sequential command interface with persistent state, like IrisGL in a lot of ways.
The main problems porting IrisGL is the stuff that's missing, like user input and windowing and that changes from platform to platform (GLUT is not it, that's just a utility written by Kilgard), so you have to implement your platform specific windef etc. and user input and it's messy. Stuff that used to exist as objects but now doesn't like materials, lights and light models, which are now incremental state rather than objects (no lmbind etc.). With OpenGL 1.1 onwards texture objects are supported but not other stuff like texenv so no tevdef and tevbind but you do have texbind equivalent (although texdef is implied by binding the handle at creation).
Good luck, you shouldn't have too much trouble with the port once you steer clear of stuff like GLUT.
12-08-2005, 06:34 AM
Thanks much. That is encouraging!
Would you (or anyone else out there) happen to have an simple example of using OpenGL without a "display callback" in X-Windows? Fortran would be great, but C would be good too. I've looked around on many sites, but everyone seems to use callbacks in their examples.
12-08-2005, 11:23 AM
Never mind the example. I found one that works for me. The glxIntro man page had an example, but was missing some details (XCreateWindow). I located another version of this code with the missing details included. I appear to be moving in the right direction now.
I'll just have to move from glut fonts to the callList approach.
12-08-2005, 01:17 PM
just for interest- about how many lines of code do we talk?
12-08-2005, 01:31 PM
and, to the problem itself: i'm not quite sure if i get you right, but maybe this is an answer to the problem.
in general, there are two ways of program control:
1. register callbacks, which are called when certain events occur.
2. check if certain events have occured whenever you want.
solution 1. looks like this on linux:
XSelectInput(...); // allow certain event types
in this case, the while-loop is blocked by XNextEvent until an event occurs, which does not seem to be what you want.
// DO SOMETHING
// DO SOMETHING ELSE
} here, program execution is not suspended. if there is no event in the queue, <DO SOMETHING ELSE> is executed immediately.
this is how you would program a game, for example, <DO SOMETHING ELSE> could be a function, which draws a new frame.
btw: if you choose solution 2, you should be aware that this might consume 100% of your cpu,
while solution 1 will sleep until an event occurs.
12-10-2005, 01:10 AM
Yep, simple string printing is another gap in OpenGL that was there in IrisGL, but there are loads of trivial examples of how to print text in OpenGL.
Powered by vBulletin® Version 4.2.2 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.