Yes, I hate Objective-c, plus my project will be portable, so I'd like to code as much of it in C++ as possible, ideally 100%.
So I have a regular C++ project made with Xcode, and want to open some OpenGL windows.
edit: Damn, Glut takes over the app's control with glutMainLoop() and I'll like to have more control over the loop.
Will try freeglut, although I can't find OSX binaries, and I always have such bad luck trying to compile someone else's code.
Update:
I tried yet again to link to SDL 1.3 and this time I could get it to work! yoo-hoo!
I always wanted to work with SDL, but using more than one window was mandatory, and that's a feature of version 1.3 which is under development and I never could get it working.
As it is portable to a zillion OSes, and handles 2D graphics as well as OpenGL I'm going with it. Thanks to all!
If you don't want to use objective-c you're going to have to use either the deprecated carbon libraries, X11, or another library like GLUT to create the window. If portability is a concern either go the GLUT route, or you'll need to write your own window management code for each platform you want to support.
If you don't go the GLUT route you will need to write window management code fore each operating system so I strongly suggest you bite the bullet and write the window management in objective-c++. The only thing you really need to know is that a pointer is always a pointer no matter which language it is in, so just store objective-c ids as void* and cast them back to ids, it actually works out pretty easy.
i guess NeHe tutorials could help;
GLUT works fine for your stated purpose, although you will probably wish for a nice C++ wrapper for it. I ended up hacking my own, and although GLUT isn't friendly to wrapping, it was doable.
EDIT: Since you have a problem with glutMainLoop(), you may be trying to do more than GLUT was designed to do -- it is mainly intended for hacks, one-off projects and opengl demos. And freeglut doesn't compile OOB on the mac, at least that was my experience.
For a portable, fuller featured app, Qt may be the way to go for you. Otherwise, design your C++ for portability and use a thin GUI layer on each platform. If getting something running on each platform is most important, go for the former. If the best user experience on each platform is most important, go for the latter. You may find that "thin" is not the most descriptive term for what is involved.
I found this demo to be useful for getting a simple Cocoa/OpenGL window working, even though the code has a number of ridiculous bugs: http://developer.apple.com/library/mac/#samplecode/CocoaGL/Introduction/Intro.html
This question has been asked over 3 years ago, yet remain quite fresh. I just recently went through similar exercise for planning school curriculum, and trying to figure out what's the best portable library to work with on Mac/Windows/Linux/mobile with OpenGL projects. Perhaps my notes will help someone make a decision. I only mention the main options that I've considered.
Higher level APIs, for window management plus additional goodies, like sprites, fonts, sounds, event handling, etc:
SFML and github repo: nice&tidy, C++, object oriented library that integrates with OpenGL natively. Portability for managing windows and OpenGL 3.3 contexts out of the box on MacOS, Win and Linux. Mobile support provided in the 2.2 branch (github).
SDL2: all major platforms, including mobile, supported. The OpenGL context needs to be manually managed somewhat, so use of GLEW for example comes really handy (see below). A bit lower level than SFML.
Lower level APIs, mostly for window and OpenGL context management:
GLWF: This is pretty much a GLUT replacement for modern OpenGL. Rather low level, but portable across: Win, OSX, Lin. In active development.
GLEW: I only mention it for completness. It doesn't manage windows, but helps managing OpenGL contexts and you might use it together with GLWF or SDL for example.
Others:
Freeglut: Open source continuation of GLUT. Suitable for small demo projects. I have not used it myself, but seen good docs and demo code. In active development.
GLUT: old one, discontinued. Legacy demos and code around the net.
Related
GNOME has chosen to not support server-side decorations under Wayland. That's okay, but I'm making a game in SDL, and I'd like first-class Linux support, including supporting running natively in Wayland (with SDL_VIDEODRIVER=wayland) under the biggest desktop environments (including GNOME).
Currently, when I run my game with SDL_VIDEODRIVER=wayland, no decorations are drawn. How am I supposed to integrate with the rest of the system? What's the story for non-GTK/Qt applications in practice?
The SDL2 developers are working on this right now: https://github.com/libsdl-org/SDL/pull/4068 So while there isn't an easy solution as of now, the good news is that you'll probably not really need to do anything than wait a few more months and then just use latest SDL2.
In general, the situation for non-Qt/GTK stuff is like this:
GNOME is currently not willing to introduce the decoration code into GNOME's compositor Mutter mostly from what I can tell are technical reasons: GNOME's decorations are GTK+-based, but Mutter has apparently zero GTK+ code right now so it's apparently not as easy to integrate as one would hope.
So non-GTK/Qt applications have three options: 1. they can manually implement it, or 2. they can use something like libdecoration as SDL2 is apparently going to do, or 3. pull in GTK+ as a dependency purely for the window and decorations which e.g. Electron/Chromium uses it for. It seems like in the medium term at least, GNOME will not fix this so these are the only options I'm aware of.
I don't know if I had gotten it all wrong, so I'm asking for directions here.
Let's take for example, back in college, when you learned C++ and used Turbo C++ or GCC to compile, you get an idea of what a low level programming language is.
Now let's say I want to make a basic 2D video game, just as a personal project, nothing fancy, and I want to develop it using C++ just because. I'd code it using Visual Studio since it's a pretty good IDE.
Is it right to say "I'm going to use MFC" for this kind of project? (Consider the fact that I'd be using OpenGL).
MFC is a C++ framework that encapsulates the core elements of the Windows API. It's primarily intended for creating standard, windowed applications that the user interacts with on the desktop.
It comes with a built-in graphics framework: GDI. The one that was introduced with Windows, revolutionary for its time because it abstracted away hardware-specific details and allowed programmers to write general code that ran on any machine Windows ran on. But it was never particularly good for games; it was designed for Windows-style business applications. It was awesome for text (and is still arguably the best option that there is—have you looked at how Direct2D renders text lately?), and handled simple graphics, but consider that before alternative graphics-specialized frameworks like OpenGL were available, most game developers stuck with DOS, where they could/were forced to interact directly with the graphics hardware at a low level.
So if you want to use MFC and OpenGL together, you can, but I don't really see the point. The only real benefit you'd be gaining from MFC is a reduction of 100-some-odd lines of code that sets up the fundamental skeleton of any Windows application. For example, considering this sample OpenGL program, using MFC would essentially allow the WinMain and the MainWndProc functions to be buried deep in the bowels of the MFC framework code, rather than appearing directly in your code. But, like I said, big deal. The majority of your code is going to be OpenGL-specific, and MFC won't help there.
The only way it might make sense for the two to interact is if you wrote the launchpad/host for the game using MFC and GDI (i.e., the part that displays windows and dialogs on screen), and then the game portion itself in OpenGL (launched once you clicked a "Start" button on the dialog interface).
And of course, even if you wanted to do this, MFC is not your only option. There are tons of C++ frameworks for writing Windows applications. Everyone has their favorite. Despite what some may tell you, there's nothing wrong with MFC if you already know it and/or are comfortable with the Windows API. But don't waste time learning it. Use WTL instead.
You would NOT use MFC simply because it is meant for general application development giving you features and classes that you will most likely never use!
A good start would be to look at SFML http://www.sfml-dev.org/ or (my personal favourite) SDL http://www.libsdl.org/. These libraries were written to develop games or at least multimedia applications using them.
Writing a Game Editor in MFC can be a good idea though!
I am looking to get started with some 3D programming in C or C++. The problem I have is that it seems like the only tutorials I can find for Mac OS use objective C and Cocoa frameworks. I want to obtain the same environment as Windows users, more or less.
If I try to use a text editor and g++ compiler, I am missing headers, but, if I try to use Xcode, I am forced to grapple with Cocoa, which is frustrating to me. I don't really see any reason why the OpenGL/GLUT that comes pre-installed on Mac should force me to use Xcode, but it seems I can't get the header files without it.
How can I get through all of the Apple 'developer friendly' interfaces to write some old-fashioned code with full cross-platform portability?
Some portion of Objective-C is inevitable if you want to use the latest benefits of the OSX/Cocoa. The easiest way to port an existing application to MacOS would be the following:
Write the "bare bones" nibless application in Objective-C. It would only be a single AppDelegate class and a little setup in the main() function
Add the custom NSGLView descendant in your window which you create in the AppDelegate's didFinishLaunching event handler
Setup the CVDisplayLink and rendering callback in the NSGLView initialization
Use your existing OpenGL rendering code in the CVDisplayLink's callback
Now for the interesting part: where to get all of this ?
Surprisingly, a good nibless application sample is the UI for OSX's port of QEMU (yes, the emulator). Also the Apple's official GLEssenstialPractices demo shows all the information you need to set up OpenGL rendering pipeline. All the rest is up to you.
The detailed and modern introduction to system-level OSX programming can be found in the "Advanced Mac OS X Programming" book by Mark Dalrymple. It explains many things and after reading all of this I've understood most of the design decisions in the OS (it really makes you accept all the "non-standard" things if you think from the performance viewpoint).
To get through the "nibless" programming I would recommend you to read the blog posts like this one http://blog.kleymeyer.com/2008/05/creating-cocoa-applications-programatically-ie-nib-less/ The google search helps a lot.
The same tricks apply to the CocoaTouch/iOS and there are a lot of questions answered on SO, like this one Cocoa touch/Xcode - generating NIB-less graphics context
If you want to create cross-platform applications you could create a project with the Command Line Tool template.
Next, import the OpenGL and GLUT framework. This will get you a "blank" C++ project with the required OpenGL and GLUT headers.
Lighthouse 3D gives you some tips about portability and how to initiate your first project.
http://www.lighthouse3d.com/tutorials/glut-tutorial/initialization/
I have created a software layer (named cocoglut) that allows the translatation of basic or essential GLUT calls to COCOA. This library allows creating/destroying windows and register callbacks from a C/C++ application, just by using GLUT calls, without the need for nib files or for XCode project files (and can be compiled from the command line). This option uses full retina display resolution. The source is on GitHub.
I want to create a C++ UI framework (something like QT or like ubuntu unity Desktop)
How is programmed , is it using OpenGL or lets take plasma ui of QT (how is this programmed )?
Direct answers , reference links anything will be helpful.
Some interesting opengl based UI I founf on the web
LiquidEngine
http://www.youtube.com/watch?v=k0saaAIjIEY
Libnui
en.wikipedia.org/wiki/Libnui
Some UI frameworks render everything themselves, and work based on some kind of clipping-window-within-the-host-systems-screen. Non-display aspects (such as input event handling) have to be translated to/from the host systems underlying APIs.
Some UI frameworks translate as much as possible to some underlying framework.
wxWidgets can do both. You can choose a native version (e.g. wxMSW if you're on Windows) and most wxWidgets controls will be implemented using native Windows controls. Equally, you can choose the wxUniversal version, where all controls are implemented by the wxWidgets library itself.
The trouble is that typical GUI frameworks are huge. If you want a more manageable example to imitate, you might look at FLTK. I haven't got around to studying it myself, but it has a reputation for being consise.
There are also some GUI toolkits that are specifically aimed at games programming, such as Crazy Eddies GUI. My guess - these are probably as idependent of the underlying API as possible, so that particular applications can implement the mapping to whichever underlying API they happen to target (OpenGL, DirectX, SDL, whatever) and can be the boss of the GUI rather than visa versa.
http://www.wxwidgets.org/
http://www.fltk.org/
http://www.cegui.org.uk/wiki/index.php/Main_Page
"no really, don't write your own wm or toolkit"
The #Xorg-devel guys on irc.freenode.org
doing one anyway means that you have to test against a wide range of more or less buggy WMs and X implementations, and that you have to frequently update to be compatible with the latest Xorg server and X protocol features (like Xinput 2.1)
understandably, the Xorg people are tired to support old, unmaintained toolkits and applications. They already have enough bugs.
The GUI frameworks are very dependant on a windows system, which dictates what is allowed and how windows are created and rendered. For example, pass a specific option to create a borderless or full-screen window.
Since you mentioned opengl and ubuntu, I guess you want to start on a linux platform. You should study xlib, for which you can find reference here.
Since the qt library is open source, you can download it and peek into it's sources.
A UI library isn't developed from scratch. It relies on the OS' windowing system, which relies on the driver from your graphics adapter, which relies on the OS kernel, which relies on... and so on.
To develop any software "from scratch", you can start by writing your own BIOS. Once you're done with that, move on to writing an OS, and then you should be just about ready to write the software you wanted. Good luck.
And this is assuming you're willing to cheat, of course, and use a compiler you didn't write from scratch.
Before you do that, it's worth that you spend one week on thinking:
1, Do you really know how to do it? I doubt that.
2, Do you really need to do it? I doubt that too.
I'm looking for a window... ugh... thing for OpenGL, I've been using SDL but more recently found that its not quite up to my needs in at least any code I've seen. I'd like to find some GUI library that allows me to develop using OpenGL (and SDL if at all possible) with a menu bar, possibly options at the side, and a working-out-of-the-box close button. Qt is the sort of thing I'm looking for, but I'd like to work with something that doesn't force me to make it open source.
A quick list of things I want, a working close button, ability to use OGL, cross platform, any licence that doesn't force me to become open source, free, and the ability to go full screen and change resolution on the fly.
I have searched myself, I'm not a lazy person really ;) I just want to get some opinions here before I dive off into anything and find its not really suitable for my needs.
Thanks in advance for any feedback.
Try wxWidgets. There's a link on using it with OpenGL here.
When Qt 4.5 comes out (later this month, I think) it will be LGPL, so if you can wait a couple weeks, you can use Qt without having to open-source your program.
GLUT (GL Utility Toolkit) comes close to what you're looking for. It's quick and easy and cross-platform, although it does not have support for menu bars. This page also has a number of GLUT-like alternatives.
For the out-of-the-box close-button enabled window, you can have GLUT, as mentionned before, and if your additional GUI needs are really simple, I think GLUT can provide you some.
You could also go for simple OpenGL rendered menus and buttons, either using NVidia Widgets or AntTweakBar.
You don't need 'support' for OGL as long as you can pass it the correct the information. On windows at least, if you have a windowing API that you can hook the HWND from, you can set up OGL to use pretty much any window you want. I've done this successfully with wxWidgets and straight win32. I can't help you with other platforms, but I suspect you can do something similar.
This works with D3D too and is a nice way of separating your rendering code from your windowing API.
SDL can create OpenGL Windows.
http://gpwiki.org/index.php/C:SDL_OGL
There are numerous rendered widget libraries such as those that rotoglup suggested. Have a peek at CEGUI and QuickGUI, they may make you happy (although CEGUI disappoints me with its abuse of XML). And here's a shameless plug: GLICT.