Jump to content

  • Log In with Google      Sign In   
  • Create Account

How portable is OpenGL?


Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.


  • You cannot reply to this topic
15 replies to this topic

#1   Members   -  Reputation: 122

Like
Likes
Like

Posted 24 October 2001 - 09:13 AM

Im playing with the thought of learning myself OGL, and I read that it is portable to other platforms. So now I''d like to know to what extend is OGL portable to other platforms? Are there any limitations, i.e. if you are a C programmer do you have to stick to the ANSI standard to keep it portable and stuff like that?? *PredeX*

#2   Members   -  Reputation: 1087

Like
Likes
Like

Posted 24 October 2001 - 09:59 AM

quote:
Original post by PredeX
Are there any limitations, i.e. if you are a C programmer do you have to stick to the ANSI standard to keep it portable and stuff like that??


That''s portability of the language, not OpenGL.

quote:
Original post by PredeX
Im playing with the thought of learning myself OGL, and I read that it is portable to other platforms. So now I''d like to know to what extend is OGL portable to other platforms?


OpenGL is portable to many platforms including: Linux/BSD/Unixes, MacOS (old and new), Windows, BeOS, any many more (some not-so-officially). GLU should be supported by the same platforms. Now, WGL, GLX, and other such libraries aren''t 100% portable. Same with the Win32 API and XLib, they aren''t portable. To get around this you can use a library like SDL or GLUT.

[Resist Windows XP''s Invasive Production Activation Technology!]

#3   Members   -  Reputation: 874

Like
Likes
Like

Posted 24 October 2001 - 06:36 PM

you can use OpenGL with fortran.... that should tell you something.......

#4   Members   -  Reputation: 348

Like
Likes
Like

Posted 25 October 2001 - 04:09 AM

I''m not entirely sure what that tells me, but I don''t think I like it.

Uuuuuulrika-ka-ka-ka-ka-ka

#5   Members   -  Reputation: 127

Like
Likes
Like

Posted 25 October 2001 - 04:44 AM

its as portable as that niftly little biro

#6   Members   -  Reputation: 122

Like
Likes
Like

Posted 25 October 2001 - 08:49 AM

It is portable on all the supported platforms. www.opengl.org should have a list.

What is portable about OpenGL. Take this example...

glPushMatrix();
glBegin(GL_TRIANGLE)
glVertex3f(2.0, 1.0, 7.0);
glVertex3f(5.0, 5.0, 7.0);
glVertex3f(3.0, 6.0, 7.0);
glEnd();
glPopMatrix();

The above calls are all OGL methods. If you where to take this snipet of code and paste within your Win32, Mac, Linux and other C compilers and press build it would compile. Of course you would have to setup you compiler to link the OGL libs for that platform. Also for different languages like mentioned Fortran, VB etc... The conventions will be different.

As for the base OS calls needed. You can either use GLU or code your own OS calls like: message loops, event handlers etc...

#7   Members   -  Reputation: 122

Like
Likes
Like

Posted 25 October 2001 - 01:18 PM

GLU sucks ... (from personal experience) ... write generic C code, then alter per platform as is necesary

#8   Members   -  Reputation: 122

Like
Likes
Like

Posted 25 October 2001 - 01:31 PM

quote:
Original post by ANSI2000
As for the base OS calls needed. You can either use GLU or code your own OS calls like: message loops, event handlers etc...


quote:

GLU sucks ... (from personal experience) ... write generic C code, then alter per platform as is necesary



I think you guys mean GLUT.

quote:

If you where to take this snipet of code and paste within your Win32, Mac, Linux and other C compilers and press build it would compile.

Actually it wouldn''t compile, since there is a semicolon missing and GL_TRIANGLE should be GL_TRIANGLES (I know, typos, I just had to point it out, sorry ).


#9   Members   -  Reputation: 1087

Like
Likes
Like

Posted 25 October 2001 - 01:31 PM

quote:
Original post by Shag
GLU sucks ... (from personal experience) ... write generic C code, then alter per platform as is necesary


Do you mean GLUT? I personally prefer SDL, it handles a lot more than GLUT making it a lot easier to port.

[Resist Windows XP''s Invasive Production Activation Technology!]

#10   Members   -  Reputation: 122

Like
Likes
Like

Posted 25 October 2001 - 01:44 PM

BUT SURELY ANY EXTRA LAYER ADDS OVERHEAD!

I''m just saying that in order to be compatible, refrain from using OS specific calls ... but do it internally in code!

Forget these libraries which claim to do it all ... in favour of performance

#11   Members   -  Reputation: 476

Like
Likes
Like

Posted 25 October 2001 - 01:50 PM

Yes, of course any extra layer adds overhead. But then again, so does using C when you could use Assembly language.

~~~~~~~~~~
FreeBSD.org - worship the Daemon!

#12   Members   -  Reputation: 122

Like
Likes
Like

Posted 25 October 2001 - 02:01 PM

ABSOLUTELY ... THAT'S MY POINT!!!!

We all accept that a good engine is written in assembly ... right?


NO ... with the right compilers it doesn't matter (much)

But by trying to include the overhead for each OS, you are not doing yourself a favour! Target your system for a specific sytem, then re-write the OS stuff!

Edited by - Shag on October 25, 2001 9:03:56 PM

#13   Members   -  Reputation: 1087

Like
Likes
Like

Posted 25 October 2001 - 02:23 PM

quote:
Original post by Shag
NO ... with the right compilers it doesn't matter (much)


Exactly, which the right interoperability wrapper it doesn't matter (much). SDL is meant for games, you think they'll make it slow on purpose? I haven't noticed any loss of speed yet.

[Resist Windows XP's Invasive Production Activation Technology!]

Edited by - Null and Void on October 25, 2001 10:00:24 PM

#14   Members   -  Reputation: 122

Like
Likes
Like

Posted 25 October 2001 - 02:50 PM

quote:
Original post by Shag
But by trying to include the overhead for each OS, you are not doing yourself a favour! Target your system for a specific sytem, then re-write the OS stuff!


Why include the overhead of OpenGL when you could write directly to the card? Target your game for a specific graphics card, then re-write the card specific stuff to support other graphics cards.

It''s all a matter of trade-offs.

#15 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 25 October 2001 - 09:52 PM

quote:
Original post by Dactylos
Why include the overhead of OpenGL when you could write directly to the card? Target your game for a specific graphics card, then re-write the card specific stuff to support other graphics cards.

It''s all a matter of trade-offs.


But wouldnt that be much more work since theres a whole bunch of cards which are used by gamers??

Let''s say i want to program a game for Windows and Linux, could i use GCC (DJGPP) with OGL and just compile under both platforms(preferably) without any changes?



#16   Members   -  Reputation: 122

Like
Likes
Like

Posted 26 October 2001 - 12:47 AM

AP lacks the ability to understand sarcasm

But the answer to the question is yes an no. Once you have the rendering context, you can write code that won''t change OS to OS, but you will have to abstract GLX, WGL or AGL (are there any others now).

My library compiles under GCC (Cygwin - not DJGPP as thats DOS and OpenGL support would have to be through Mesa) for Windows and Linux. Programs that use it compile to Windows & Linux without changes.

There is -negligable overhead-. You are only making virtual function calls on OS specific stuff, not OGL stuff. Virtual functions aren''t so slow anyway out of inner loops, especially when it is only for resizing windows, etc that you don''t do often.

So, yes, OpenGL is portable. (Hey, is there really any competition anyway? What else can you use for 3D on Linux - DirectX via Wine?!


~~~
Cheers!
Brett Porter
PortaLib3D : A portable 3D game/demo libary for OpenGL
Community Service Announcement: Read How to ask questions the smart way before posting!




Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.




PARTNERS