Has anyone ported IRIS GL to Opengl?????

Has anyone ported IRIS GL to Opengl?????

Post by Max Waterma » Thu, 08 Jul 1999 04:00:00




> I am trying to port IRIS GL to Opengl on the Windows environment.
> If someone has done that before, please give me some tips.

> some codes myself.

Toogl is fine. If you have an OpenGL SGI machine handy, I would recommend
having a look at using ogldebug to convert portions of code. See
http://reality.sgi.com/maxw/ogldebug_tips/ogldebug_tips.html

Max.

Quote:>  Then do I have to use MFC to port X programming part?  I
> want to contact an expert about this porting job.
> Please any expert who can help me????

--

PSE-GPS
-------------------------------------------------------------------------------
 
 
 

Has anyone ported IRIS GL to Opengl?????

Post by CADCA » Fri, 09 Jul 1999 04:00:00


I am trying to port IRIS GL to Opengl on the Windows environment.
If someone has done that before, please give me some tips.

some codes myself.  Then do I have to use MFC to port X programming part?  I
want to contact an expert about this porting job.
Please any expert who can help me????

 
 
 

Has anyone ported IRIS GL to Opengl?????

Post by Mark Lasersoh » Fri, 09 Jul 1999 04:00:00




> > I am trying to port IRIS GL to Opengl on the Windows environment.
> > If someone has done that before, please give me some tips.

> > some codes myself.

> Toogl is fine. If you have an OpenGL SGI machine handy, I would recommend
> having a look at using ogldebug to convert portions of code. See
> http://reality.sgi.com/maxw/ogldebug_tips/ogldebug_tips.html

> Max.

> >  Then do I have to use MFC to port X programming part?  I
> > want to contact an expert about this porting job.
> > Please any expert who can help me????

> --

> PSE-GPS
> -------------------------------------------------------------------------------

--

        Actually, this brings up one of the strangest decisions
SGI ever made: when they made IrisGL it had much of the windowing
capabilities encapsulated. In order to make it "Open" these were
removed. This did make GL usable across platforms (meaning in
Windoze) but it also forced the exposure of the windowing code
in all the OpenGL programs - thereby making the actual porting
of OpenGL programs much more difficult.

        Would it not have made a lot more sense to leave the
windowing functions in GL, and rewritten those (for an appropriate
licensing fee) for each new platform that wanted onboard? That way,
GL programmers getting in the windoze world would be insulated
from the bizare details of Wondoze SDK/MFC. I imagine that even
seasoned Windites would've enjoyed being able to open and use
a graphical window in a line or two of code. In addition, a simple
recompile would've moved that program - unchanged, from one
platform to another.

        Does anyone here have any insight into that decision?

Mark Lasersohn
Aztech Design

http://www.aztechdesign.com
Don't let the cows fool you!
330-569-7492

 
 
 

Has anyone ported IRIS GL to Opengl?????

Post by Jon Lee » Sat, 10 Jul 1999 04:00:00




Quote:>    Actually, this brings up one of the strangest decisions
>SGI ever made: when they made IrisGL it had much of the windowing
>capabilities encapsulated. In order to make it "Open" these were
>removed. This did make GL usable across platforms (meaning in
>Windoze) but it also forced the exposure of the windowing code
>in all the OpenGL programs - thereby making the actual porting
>of OpenGL programs much more difficult.

>    Would it not have made a lot more sense to leave the
>windowing functions in GL, and rewritten those (for an appropriate
>licensing fee) for each new platform that wanted onboard? That way,
>GL programmers getting in the windoze world would be insulated
>from the bizare details of Wondoze SDK/MFC. I imagine that even
>seasoned Windites would've enjoyed being able to open and use
>a graphical window in a line or two of code. In addition, a simple
>recompile would've moved that program - unchanged, from one
>platform to another.

>    Does anyone here have any insight into that decision?

    Adding a windowing API to OpenGL means that you have to *have* a
window system on any target platform, which is an unreasonable
constraint on e.g. embedded or small-footprint or dedicated devices.
It's also inappropriate for dedicated "render server" type applications
where OpenGL really is used only for rendering on systems that may not
even have a graphics head.

    For those platforms which do have some sort of window system, you
would be doing all the work of writing yet another WS which doesn't have
the platform's native look and feel, may not semantically map well onto
the native WS, and certainly won't encompass every last capability
specific to that WS.

    Finally, forcing a new WS on OpenGL licensees would have been a
formidable barrier to adoption, while enabling it to work in the
platform's own environment has resulted in OpenGL being available on
Irix, HP/UX, AIX, BeOS, MacOS, Linux, Solaris, Digital Unix, Windows 9x,
NT, QNX, and many other platforms.

    But there are a bunch of OpenGL-friendly libraries like GLUT, MUI,
PUI, GLUI, Tk, fltk, Forms, etc. which offer portable windowing
abstractions and toolkits of several types. Some are layers on the
native GUI which let you construct OpenGL "widgets" of some type, and
some are built on top of OpenGL itself. If you just want to do basic
OpenGL stuff or have only modest 2D GUI needs, GLUT with one of the
widget libraries like GLUI is great; for more aggressive interfaces look
at something like Tk or Forms.

    Jon Leech
    SGI

 
 
 

Has anyone ported IRIS GL to Opengl?????

Post by Mark Lasersoh » Sat, 10 Jul 1999 04:00:00



>     Adding a windowing API to OpenGL means that you have to *have* a
> window system on any target platform, which is an unreasonable
> constraint on e.g. embedded or small-footprint or dedicated devices.

        I don't understand why adding a windowing system then
requires that you *have* to have a windowing system for other
portions of OpenGL to work. If they work now without a windowing
system - or work well with the "abstracted" windowing systems
mentioned as compatible, then surely it could work with or without
such an abstracted api if it was originally provided as part of
the system.

Quote:> It's also inappropriate for dedicated "render server" type applications
> where OpenGL really is used only for rendering on systems that may not
> even have a graphics head.

        See comment (question) above.

Quote:

>     For those platforms which do have some sort of window system, you
> would be doing all the work of writing yet another WS which doesn't have
> the platform's native look and feel, may not semantically map well onto
> the native WS, and certainly won't encompass every last capability
> specific to that WS.

        I certainly don't want that. I am still wondering why it was
not provided with an encapsulation of the windowing system native
to that platform. Thereby, if on motif - it looks like motif, if
on NS it looks like NS - etc...

Quote:

>     Finally, forcing a new WS on OpenGL licensees would have been a
> formidable barrier to adoption, while enabling it to work in the
> platform's own environment has resulted in OpenGL being available on
> Irix, HP/UX, AIX, BeOS, MacOS, Linux, Solaris, Digital Unix, Windows 9x,
> NT, QNX, and many other platforms.

        The original IrisGL call: winopen(), certainly was able to
provide a window that didn't conflict at all with the Irix/X look
and feel (unless the programmer wanted it to). Why would the same
"shell" around appropriate code on other platforms produce windows
which do? Especially since the character of the windows mentioned
above on any of the X based systems is already encapsulated largely
by the desktop manager they are running.

Quote:

>     But there are a bunch of OpenGL-friendly libraries like GLUT, MUI,
> PUI, GLUI, Tk, fltk, Forms, etc. which offer portable windowing
> abstractions and toolkits of several types. Some are layers on the
> native GUI which let you construct OpenGL "widgets" of some type, and
> some are built on top of OpenGL itself. If you just want to do basic
> OpenGL stuff or have only modest 2D GUI needs, GLUT with one of the
> widget libraries like GLUI is great; for more aggressive interfaces look
> at something like Tk or Forms.

        No argument. I have used several of these alternative with
varying degrees of success to provide windows for OpenGL on various
platforms.

Quote:

>     Jon Leech
>     SGI

--

        Jon, I am sorry if I seem argumentative - that is not my
intent. You have indeed provided some insight into the decision.
Part of my "rant" has more to do with the shift in markets for
3D interactive programming. Once upon a time, all of us were asked
to port our IrisGL progs over to OpenGL so some mucky muck could
see the product viz on his windoze box. Suddenly I was up to my
elbows in windoze code (SDK/MFC), which after a few years of the
sensibilities of IrisGL/Performer/Inventor/X11/Motif/etc... seemed
arbitrary, unnecessarily difficult, and just plain badly done.
        I have just been looking through some old IrisGL code and
finding that it only took a handful of lines (often two) to open
and make a useable window:

        prefsize(900,900);
        winopen("example");

To replace that with the MFC (or even Motif) equivalent, was a
real pain (see the three page microsoft example for "hello world").
Yes, the appearance of crossplatform GUI toolkits that work and
seem to be staying around for a while, has helped considerably. But
back when this decision was made few of these existed, fewer were
stable, and most have already gone the way of such things.

        In the end, I wrote the code, got it working, encapsulated
it myself, put it in a library, and hoped I would never have to
see it again, and went went on to write the code I was being paid
to write in GL.

Mark Lasersohn
Aztech Design

http://www.aztechdesign.com
Don't let the cows fool you!
330-569-7492

 
 
 

Has anyone ported IRIS GL to Opengl?????

Post by Jon Lee » Sat, 10 Jul 1999 04:00:00




Quote:>    I don't understand why adding a windowing system then
>requires that you *have* to have a windowing system for other
>portions of OpenGL to work.

    One of the core principles - one that on balance has been quite
successful - of OpenGL design was "no subsetting".

Quote:>>     For those platforms which do have some sort of window system, you
>> would be doing all the work of writing yet another WS which doesn't have
>> the platform's native look and feel, may not semantically map well onto
>> the native WS, and certainly won't encompass every last capability
>> specific to that WS.

>   I certainly don't want that. I am still wondering why it was
>not provided with an encapsulation of the windowing system native
>to that platform. Thereby, if on motif - it looks like motif, if
>on NS it looks like NS - etc...

    I'm thinking more of the window system input model (polled? event
driven? callbacks?), the visibility / persistence model for windows, and
so on. IrisGL predated X and IIRC there were some aspects of the
window/event model that just didn't work that well on X (although I may
be conflating it with HP's Starbase, another graphics library developed
before X which had similar problems moving to X).

Quote:>   Jon, I am sorry if I seem argumentative - that is not my
>intent. You have indeed provided some insight into the decision.
>Part of my "rant" has more to do with the shift in markets for
>3D interactive programming.

    I'm going to weasel out of this and confine myself to the insights,
since I wasn't at SGI when any of this happened :-) It might well in
retrospect have been a good idea to standardize something like AUX or
GLUT early on, so they could have been more widely used, but it's moot
now.

    Jon

 
 
 

Has anyone ported IRIS GL to Opengl?????

Post by John Rosasc » Sat, 10 Jul 1999 04:00:00


Depending on how sophisticated the interface to your app is, MFC
may not be necessary.  Porting X11 code to Win32 is a much more
natural migration than to MFC.  MFC can really do a number on
the cross platform compatibility possibilities of the apps life in the
future.  Another * port would be required to go to say Linux
if that were desirable if you port it to MFC.

There are many Ogl/Win32 examples around.


> I am trying to port IRIS GL to Opengl on the Windows environment.
> If someone has done that before, please give me some tips.

> some codes myself.  Then do I have to use MFC to port X programming part?  I
> want to contact an expert about this porting job.
> Please any expert who can help me????

--
_____________________________________________________________________________
John Rosasco | Silicon Graphics Inc - CPD | (650) 933-7730 | FAX  932-0318
 
 
 

Has anyone ported IRIS GL to Opengl?????

Post by Ruud van Ga » Tue, 13 Jul 1999 04:00:00






>>        Actually, this brings up one of the strangest decisions
>>SGI ever made: when they made IrisGL it had much of the windowing
>>capabilities encapsulated. In order to make it "Open" these were
>>removed. This did make GL usable across platforms (meaning in
>>Windoze) but it also forced the exposure of the windowing code
>>in all the OpenGL programs - thereby making the actual porting
>>of OpenGL programs much more difficult.

>>        Would it not have made a lot more sense to leave the
>>windowing functions in GL, and rewritten those (for an appropriate
>>licensing fee) for each new platform that wanted onboard? That way,
>>GL programmers getting in the windoze world would be insulated
>>from the bizare details of Wondoze SDK/MFC. I imagine that even
>>seasoned Windites would've enjoyed being able to open and use
>>a graphical window in a line or two of code. In addition, a simple
>>recompile would've moved that program - unchanged, from one
>>platform to another.

>>        Does anyone here have any insight into that decision?

>    Adding a windowing API to OpenGL means that you have to *have* a
>window system on any target platform, which is an unreasonable
>constraint on e.g. embedded or small-footprint or dedicated devices.

Well, the thing he was suggesting rather was to have an OpenGL and an
OpenWS library.
The bad thing he was suggesting to use the GL syntax for the virtual
OpenWS. I've done a little GL programming and love the quick & dirty
programming capabilities.

"main(){ winopen("hello world"); } "

Ouch, that's cool, but unfortunately it is a much to narrow look in
windowing systems. That's one thing.
The other thing is perhaps naming. Typing 'man v' results in the v3f()
type of functions. It seems design focused a lot on typing. These
days, with many many API's around, its better to have more verbose
commands like 'PushVertex3f()' because it looks a bit too much like
shorthand, GL.

Besides, I don't even have a C compiler anymore on the SGI's. Only
C++, and that's the way to go (I mean: object-oriented) for bigger,
better apps. By better I mean maintainable, expandable. The more
abstract you can get, the better actually.

GL is just too much of a hacking language, assuming a lot of default
situations which begin to work against you if the app gets big. Its
structure is outdated. Putting RGBmode(); gconfig(); after a
winopen();? These functions seem unrelated when just looking at it at
first glance. The least you could do is win->SetRGBMode();
win->DoConfig().

GLUT is nice for GL-type of things. Perhaps naming it OpenWS would
have gained more 'power' to the name. ;-)

Well, this all is just my opinion. I constantly create bigger and
better classes so my latest application goes like:
#include <zlib/mcapp.h>
void main()
{
  app=new ZMCApp("testApp");
  app->Create();
  app->Run();

Quote:}

Which comes up with a lot of default features as well, but in a
controllable way and more structured than GL's functions here & there.

Ruud van Gaal
MarketGraph / MachTech: http://www.marketgraph.nl
Art: http://www.marketgraph.nl/gallery

 
 
 

1. Porting IRIS GL code to OpenGL

My current IRIS GL application has more than 20K lines of Fortran but
makes very limited use of GL facilities: in fact it does nothing much
beyond plotting text and polylines. To use callback routines however the
whole program would have to be rewritten so I'm looking in particular
for interfaces that emulate qtest, qread and charst.

The intention is to port the application to Windows NT whilst retaining
an SGI capability. I can live with C/C++.

Steve Loch

2. Strange icon

3. Port of IRIS-GL charstr() to OpenGL

4. SavePicture after StretchBlt

5. Iris/Open GL and Iris Performer...

6. listserver that might deal with PS

7. X server for NT supporting OpenGL/IRIS GL?

8. converting IRIS GL to OpenGL on Mac

9. Equivalent functionality from IRIS GL to OpenGL

10. How OpenGL differs from the IRIS GL

11. IRIS GL vs. OpenGL

12. Iris GL or OpenGL?