Sign in to follow this  
Chaosenemy

OpenGL OpenGL and APIs on Linux/Mac OS X confusion

Recommended Posts

Chaosenemy    152
Hey guys. I've been working on a game engine for the last few months and up until now it's only been running on Windows. But now I'm interested in getting this thing running on Linux and perhaps Mac OS X at some point. (Don't have a Mac though...) I'm confused about a few things though so I was hoping you guys could help me out.

First of all, all the components in my engine are cross-platform except for the Windows API of course. So here's where my confusion lies - what API should I use for Linux and Mac? Should I use X11 with GLX? That would be compatible on Linux, Mac, and other Unix systems right? Or am I wrong on that one? I also took a look at Gtk+ and Gtkmm (with a GL extension) for Linux, but those basically wrap X11 code right? So would Gtk APIs be slower than X11? And if I used Gtk for Linux, what would I use for Mac?

Sorry, a lot of questions, I know. But if someone could give me some direction, I'd really appreciate it. Thanks.

Tl;dr version - What GUI API/OpenGL specification should I use for Linux and Mac?

Share this post


Link to post
Share on other sites
jyk    2094
Quote:
I need something faster and more flexible than SDL. Same goes for GLut or other wrappers like that.
Define 'faster and more flexible'. How exactly would this supposed API be faster or more flexible than SDL, SFML, or any similar API?

Share this post


Link to post
Share on other sites
Chaosenemy    152
Quote:
Original post by jyk
Quote:
I need something faster and more flexible than SDL. Same goes for GLut or other wrappers like that.
Define 'faster and more flexible'. How exactly would this supposed API be faster or more flexible than SDL, SFML, or any similar API?


SDL just wraps the Win API, X11, etc. I need more direct access to those low level APIs. I'm just not sure which ones I'm supposed to use for Linux and Mac.

Share this post


Link to post
Share on other sites
jyk    2094
What do you need more direct access for? And what, specifically, do you think is going to be 'faster' is you can access the underlying APIs directly?

I'm not saying there's no reason one might want to write this sort of low-level code oneself; I've certainly run into cases with SDL where I wanted lower-level access. But I think it would help if you could be more specific regarding what you need exactly. Specifically:

1. What is it that you need to be 'faster'?

2. What flexibility do you need that APIs such as SDL and SFML don't offer?

Share this post


Link to post
Share on other sites
Chaosenemy    152
Quote:
Original post by jyk
What do you need more direct access for? And what, specifically, do you think is going to be 'faster' is you can access the underlying APIs directly?

I'm not saying there's no reason one might want to write this sort of low-level code oneself; I've certainly run into cases with SDL where I wanted lower-level access. But I think it would help if you could be more specific regarding what you need exactly. Specifically:

1. What is it that you need to be 'faster'?

2. What flexibility do you need that APIs such as SDL and SFML don't offer?


In all honesty, I have never used SDL. The way I look at it is: how many professional games do you see being written with libraries like SDL?

And I imagine speed is sacrificed when wrapping lower level code into convenient libraries like that. Just seem logical. As for flexibility, well I've already got the Win API portion of my engine working just the way I want it, so I would just prefer to keep the other platforms' code just as low level and specific to keep everything streamlined and consistent.

Share this post


Link to post
Share on other sites
swiftcoder    18432
Quote:
Original post by Chaosenemy
The way I look at it is: how many professional games do you see being written with libraries like SDL?
Most professional games use a abstracted windowing layer, such as SDL - particularly when porting to Mac/Linux.
Quote:
And I imagine speed is sacrificed when wrapping lower level code into convenient libraries like that. Just seem logical.
It isn't logical at all. Toolkits such as SDL take care of input and window management, but rendering is still handled by the underlying API (OpenGL). If either input of window management is a bottleneck, you are doing something horribly wrong...

Share this post


Link to post
Share on other sites
jyk    2094
Quote:
In all honesty, I have never used SDL. The way I look at it is: how many professional games do you see being written with libraries like SDL?

And I imagine speed is sacrificed when wrapping lower level code into convenient libraries like that. Just seem logical. As for flexibility, well I've already got the Win API portion of my engine working just the way I want it, so I would just prefer to keep the other platforms' code just as low level and specific to keep everything streamlined and consistent.
Well, it kind of sounds like you're basing your conclusions on guesses and assumptions rather than on actual data or direct experience with the APIs in question, which seems like kind of a questionable way to go about things, IMO. But, that's just my view on it.

Anyway, regarding how many professional games have been made with SDL or similar libraries, that by itself isn't a particularly good metric for a library's usefulness, IMO. Of more interest, I think, is whether the library would meet *your* needs. If it does, and if it's stable and gets the job done, why not use it?

In any case, SDL has in fact been used for commercial projects. I think most game development studios tend to favor their own internally developed frameworks or to use existing game engines, but frameworks such as SDL are used occasionally. (Here is a list of games that use SDL. Note that there's at least a couple successful commercial titles in there, e.g. World of Goo.)

Regarding performance, where exactly is the performance loss going to come from? And will it be measurable? Once you've set up your window, etc., SDL really doesn't have much to do, I don't think. It processes events when requested, etc., but under normal circumstances it will do very little during your game's main loop. I don't have any hard evidence to support this, but I'm doubtful there would be any noticeable performance difference between a game that used SDL and one that used (e.g.) WinAPI directly. SDL is a *very* thin wrapper over the underlying APIs, so I'm not sure where you're expecting this performance loss to come from exactly.

Note that I'm not advocating SDL specifically (or any other library); I'm just questioning your assumptions. To answer your specific question though, I don't know that much about Linux, but for OS X I believe it would be Cocoa that you'd be dealing with primarily.

Here's one other thing to consider. If you write multiple versions of your low-level engine code targeting Windows, OS X, and Linux, you're basically going to be duplicating the work that's already been done by the authors of libraries such as SDL and SFML. Presumably you'll want at least *some* degree of abstraction in your engine (for example, a common 'event' class that wraps the API-specific events for each target platform), which means that you'd essentially be wrapping the low-level code after all, presumably incurring the same performance loss that you're concerned about with SDL.

To be clear, I'm not saying writing your own framework is a bad idea; I've considered it myself, simply so I could gain complete control over the behavior of the application. But not wanting to use SDL because you think your own code is going to be 'faster' seems a bit dubious.

Share this post


Link to post
Share on other sites
gabereiser    246
More to the point.... On Mac OS X, jyk is correct that you would be dealing with Cocoa directly (and it's own OpenGL contexts constructs).

For Linux you have a few different options because on Linux there is no single window manager. You have GNOME (in which you would use gtk+) and KDE (Tk/Qt frameworks) as well as others or you could go with straight X11/xorg... This is why things like SDL exist, to abstract the differences away so all you have is a unified platform API. I personally use GLUT (freeglut) along with some other libs that allow me to access window and input across multiple platforms.

Share this post


Link to post
Share on other sites
codelogician    100
Linux uses GLX/X11 natively and Mac uses Cocoa natively (NSOpenGL classes). X11 works under both Linux and Mac, but making native calls is a requirement if you need a fast windowing system.

An existing library that provides at least example code for a lot of this information was posted here in September: http://www.gamedev.net/community/forums/topic.asp?topic_id=583305.
One of the problems mentioned in that thread is that it doesn't support native fullscreen (xf86vidmode under linux) and I noticed that he doesn't support profiles and he turns off bad context creation notifications entirely when that really should only be done for anti-aliasing, so I would just use that as reference code. The project does however, support raw mouse motion under both Windows (why not raw key presses...) and Linux (using Xinput2), sharing contexts, and OpenGL 3.+, which sets it apart.

I've been working on using XCB, which is lighter than X11 for Linux, to make my personal windowing system faster, supporting GLX_robustness to for context notifications, and providing further configuration by giving access to as many context initialization properties as possible.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Similar Content

    • By ZeldaFan555
      Hello, My name is Matt. I am a programmer. I mostly use Java, but can use C++ and various other languages. I'm looking for someone to partner up with for random projects, preferably using OpenGL, though I'd be open to just about anything. If you're interested you can contact me on Skype or on here, thank you!
      Skype: Mangodoor408
    • By tyhender
      Hello, my name is Mark. I'm hobby programmer. 
      So recently,I thought that it's good idea to find people to create a full 3D engine. I'm looking for people experienced in scripting 3D shaders and implementing physics into engine(game)(we are going to use the React physics engine). 
      And,ye,no money =D I'm just looking for hobbyists that will be proud of their work. If engine(or game) will have financial succes,well,then maybe =D
      Sorry for late replies.
      I mostly give more information when people PM me,but this post is REALLY short,even for me =D
      So here's few more points:
      Engine will use openGL and SDL for graphics. It will use React3D physics library for physics simulation. Engine(most probably,atleast for the first part) won't have graphical fron-end,it will be a framework . I think final engine should be enough to set up an FPS in a couple of minutes. A bit about my self:
      I've been programming for 7 years total. I learned very slowly it as "secondary interesting thing" for like 3 years, but then began to script more seriously.  My primary language is C++,which we are going to use for the engine. Yes,I did 3D graphics with physics simulation before. No, my portfolio isn't very impressive. I'm working on that No,I wasn't employed officially. If anybody need to know more PM me. 
       
    • By Zaphyk
      I am developing my engine using the OpenGL 3.3 compatibility profile. It runs as expected on my NVIDIA card and on my Intel Card however when I tried it on an AMD setup it ran 3 times worse than on the other setups. Could this be a AMD driver thing or is this probably a problem with my OGL code? Could a different code standard create such bad performance?
    • By Kjell Andersson
      I'm trying to get some legacy OpenGL code to run with a shader pipeline,
      The legacy code uses glVertexPointer(), glColorPointer(), glNormalPointer() and glTexCoordPointer() to supply the vertex information.
      I know that it should be using setVertexAttribPointer() etc to clearly define the layout but that is not an option right now since the legacy code can't be modified to that extent.
      I've got a version 330 vertex shader to somewhat work:
      #version 330 uniform mat4 osg_ModelViewProjectionMatrix; uniform mat4 osg_ModelViewMatrix; layout(location = 0) in vec4 Vertex; layout(location = 2) in vec4 Normal; // Velocity layout(location = 3) in vec3 TexCoord; // TODO: is this the right layout location? out VertexData { vec4 color; vec3 velocity; float size; } VertexOut; void main(void) { vec4 p0 = Vertex; vec4 p1 = Vertex + vec4(Normal.x, Normal.y, Normal.z, 0.0f); vec3 velocity = (osg_ModelViewProjectionMatrix * p1 - osg_ModelViewProjectionMatrix * p0).xyz; VertexOut.velocity = velocity; VertexOut.size = TexCoord.y; gl_Position = osg_ModelViewMatrix * Vertex; } What works is the Vertex and Normal information that the legacy C++ OpenGL code seem to provide in layout location 0 and 2. This is fine.
      What I'm not getting to work is the TexCoord information that is supplied by a glTexCoordPointer() call in C++.
      Question:
      What layout location is the old standard pipeline using for glTexCoordPointer()? Or is this undefined?
       
      Side note: I'm trying to get an OpenSceneGraph 3.4.0 particle system to use custom vertex, geometry and fragment shaders for rendering the particles.
    • By markshaw001
      Hi i am new to this forum  i wanted to ask for help from all of you i want to generate real time terrain using a 32 bit heightmap i am good at c++ and have started learning Opengl as i am very interested in making landscapes in opengl i have looked around the internet for help about this topic but i am not getting the hang of the concepts and what they are doing can some here suggests me some good resources for making terrain engine please for example like tutorials,books etc so that i can understand the whole concept of terrain generation.
       
  • Popular Now