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?

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.

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?

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.

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?

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.

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.

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.