Sign in to follow this  
Chaosenemy

OpenGL OpenGL and APIs on Linux/Mac OS X confusion

Recommended Posts

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
Quote:
Original post by theprogrammer12
I would use SDL


I need something faster and more flexible than SDL. Same goes for GLut or other wrappers like that.

Share this post


Link to post
Share on other sites
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
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
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
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
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
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
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
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  

  • Forum Statistics

    • Total Topics
      627749
    • Total Posts
      2978913
  • Similar Content

    • By DelicateTreeFrog
      Hello! As an exercise for delving into modern OpenGL, I'm creating a simple .obj renderer. I want to support things like varying degrees of specularity, geometry opacity, things like that, on a per-material basis. Different materials can also have different textures. Basic .obj necessities. I've done this in old school OpenGL, but modern OpenGL has its own thing going on, and I'd like to conform as closely to the standards as possible so as to keep the program running correctly, and I'm hoping to avoid picking up bad habits this early on.
      Reading around on the OpenGL Wiki, one tip in particular really stands out to me on this page:
      For something like a renderer for .obj files, this sort of thing seems almost ideal, but according to the wiki, it's a bad idea. Interesting to note!
      So, here's what the plan is so far as far as loading goes:
      Set up a type for materials so that materials can be created and destroyed. They will contain things like diffuse color, diffuse texture, geometry opacity, and so on, for each material in the .mtl file. Since .obj files are conveniently split up by material, I can load different groups of vertices/normals/UVs and triangles into different blocks of data for different models. When it comes to the rendering, I get a bit lost. I can either:
      Between drawing triangle groups, call glUseProgram to use a different shader for that particular geometry (so a unique shader just for the material that is shared by this triangle group). or
      Between drawing triangle groups, call glUniform a few times to adjust different parameters within the "master shader", such as specularity, diffuse color, and geometry opacity. In both cases, I still have to call glBindTexture between drawing triangle groups in order to bind the diffuse texture used by the material, so there doesn't seem to be a way around having the CPU do *something* during the rendering process instead of letting the GPU do everything all at once.
      The second option here seems less cluttered, however. There are less shaders to keep up with while one "master shader" handles it all. I don't have to duplicate any code or compile multiple shaders. Arguably, I could always have the shader program for each material be embedded in the material itself, and be auto-generated upon loading the material from the .mtl file. But this still leads to constantly calling glUseProgram, much more than is probably necessary in order to properly render the .obj. There seem to be a number of differing opinions on if it's okay to use hundreds of shaders or if it's best to just use tens of shaders.
      So, ultimately, what is the "right" way to do this? Does using a "master shader" (or a few variants of one) bog down the system compared to using hundreds of shader programs each dedicated to their own corresponding materials? Keeping in mind that the "master shaders" would have to track these additional uniforms and potentially have numerous branches of ifs, it may be possible that the ifs will lead to additional and unnecessary processing. But would that more expensive than constantly calling glUseProgram to switch shaders, or storing the shaders to begin with?
      With all these angles to consider, it's difficult to come to a conclusion. Both possible methods work, and both seem rather convenient for their own reasons, but which is the most performant? Please help this beginner/dummy understand. Thank you!
    • By JJCDeveloper
      I want to make professional java 3d game with server program and database,packet handling for multiplayer and client-server communicating,maps rendering,models,and stuffs Which aspect of java can I learn and where can I learn java Lwjgl OpenGL rendering Like minecraft and world of tanks
    • By AyeRonTarpas
      A friend of mine and I are making a 2D game engine as a learning experience and to hopefully build upon the experience in the long run.

      -What I'm using:
          C++;. Since im learning this language while in college and its one of the popular language to make games with why not.     Visual Studios; Im using a windows so yea.     SDL or GLFW; was thinking about SDL since i do some research on it where it is catching my interest but i hear SDL is a huge package compared to GLFW, so i may do GLFW to start with as learning since i may get overwhelmed with SDL.  
      -Questions
      Knowing what we want in the engine what should our main focus be in terms of learning. File managements, with headers, functions ect. How can i properly manage files with out confusing myself and my friend when sharing code. Alternative to Visual studios: My friend has a mac and cant properly use Vis studios, is there another alternative to it?  
    • By ferreiradaselva
      Both functions are available since 3.0, and I'm currently using `glMapBuffer()`, which works fine.
      But, I was wondering if anyone has experienced advantage in using `glMapBufferRange()`, which allows to specify the range of the mapped buffer. Could this be only a safety measure or does it improve performance?
      Note: I'm not asking about glBufferSubData()/glBufferData. Those two are irrelevant in this case.
    • By xhcao
      Before using void glBindImageTexture(    GLuint unit, GLuint texture, GLint level, GLboolean layered, GLint layer, GLenum access, GLenum format), does need to make sure that texture is completeness. 
  • Popular Now