Porting C++ OpenGL Game to iPad - c++

We have a game, developed in C++ and OpenGL for Windows and Mac.
Now we want to port the game to iPad. Is there a better way than writing the entire program in Objective-C to make our game work on iPad?
Now I am an iPhone/iPad noob, so pardon if the question is dumb.

You probably need to write only a small part in Obj-C that deals directly with iOS(creating a gl surface, input etc). Rest should work fine. You just need to make sure you will be using only the subset of OpenGL that is in OpenGL ES.

I hear DragonFire SDK lets you develop in C++ for iOS, on Windows.

Related

Use Unity3D as GUI to a Win32 c++ with OpenGL app

I have a Win32 app written in C++ that uses a lot of OpenGL code.
Right now we render all the GUI using OpenGL code, but I think using Unity3D as an interface layer would really simple things for us:
Is it possible to use our own c++ classes with OpenGL under a Unity3D app (in Windows?)
You should consider an alternative UI library that is capable of rendering directly to an OpenGL texture without imposing the burden of integrating with the entire Unity system.
I've played with QML, CEGUI, or libRocket.
QML is the most well designed of these three, although it's support for rendering directly to OpenGL textures is relatively recent, so there are some minor gotchas, but in general it's easy to use and the limitations can be worked around.

C++ graphic interface frameworks/libraries

I need to program a game, it's a card game actually, and I must make it with graphic interface, but I don´t know about C++ graphic interface libraries.
Is there something for C++ similar to Python's Tkinter or Pygame (I don´t know if there are others).
If there are libs, are they suited for building a simple card game?
The most common cross-platform GUI toolkit is Qt, I'd go with that for any C++ GUI application. Especially easy on Linux, all distros have packages for it, but Windows has binary installers too for different compilers.
You can use Netbeans, but I'd really go with Qt Creator for Qt programming.
For a card game with Qt, QGraphicsView is probably easiest, if you want animated card movement etc. For a more static UI, QWidget based one would be very easy. For a modern visually rich UI, QML (but then GUI part is not C++) would work very well.
Achilles heel of Qt for game development is real-time game sound effects, but you can mix Windows-specific sound stuff easily if you do not care about cross platform stuff, and card games don't need much there anyway, if anything. Also, I think Qt5 may actually have improvements for sound, making pure Qt good enough for games.
If it is a game, you may consider SDL
Fun fact: pygame is backed by SDL.
BTW, if you want to have GUI controls in your game( http://www.tayloredge.com/utilities/vbapps/gui.GIF ) , you will need a GUI library. Otherwise, a game library, like SDL, is more suitable for you.

OpenGL and Windows Programming C++

If I want to begin learning OpenGL and am not concerned about portability at the moment, would it be unwise to use OpenGL and Windows Programming together? (I am developing on Windows)
Not at all. If you already know the Windows API/message pump, adding the OpenGL context management bits won't be too much of a problem.
If you're new to both Windows programming AND OpenGL, I'd recommend starting with GLUT or similar frameworks that will let you focus on the OpenGL bits without worrying too much about interacting with the window system.

Cross platform hardware-native OpenGL library, possibly with multimedia?

I am looking for the ability to open OpenGL contexts and draw native OpenGL in windows, macOS, linux distros with X, android and iOS
I don't want to rely on the "native" device framework for the actual UI, I don't need to use native components, all I want is an OpenGL context to natively draw in OpenGL. Many of the cross platform SDKs like Marmalade and MoSync focus on making use of the native UI components and stuff like that, all I need is an OpenGl context to draw as I intend to, absolutely no native UI functionality is required, however, access to native hardware features like microphone, camera and other sensors is desired if possible, as well as access to audio/video/network.
I don't want to use QT, I want to do something that is closer to the hardware to work on the low level. The general idea is to make a lightweight cross platform hardware accelerated GUI, written on a level low enough to be truly hardware native, without relying on any native software framework. I know for android I may have to use a java wrapper to launch the native code, but the idea is to have this wrapper minimized, with very little modifications needed to deploy the low level and thus hopefully TRULY cross-platform code, that is only dependent on OpenGL hardware and OpenGL context for it to work wit.h
So I need a bare minimum solution to avoid using non-cross platform features as much as possible.
At the time the only library that comes to my mind is SDL, but I am not sure it supports android and iOS property, so besides library recommendations, more information on how SDL handles android and iOS devices and their hardware is welcomed too.
How about:
GLFW
SDL
GLUT (FreeGLUT or OpenGLUT)
Blender's GHOST framework?
Essentially they open a window, create a OpenGL context on it, deliver you the input events and leave the rest up to you.
What you want is nothing more than a platform-specific OpenGL context setup (which is quite simple and well documented: the NeHe OpenGL tutorial provides code for many environments that does just this here (the explanation is Windows specific, scroll down for the code on different OSes).
Once you have the OpenGL context, nothing prevents you from creating a full GUI with all OpenGL elements.
If you want, you could use Qt to only set up an OpenGL context (ie don't use any QWidgets or anything, other than the window showing you your OpenGL scene). It takes care of the whole setup process, but for only that, Qt becomes a huge dependency, as it only really replaces at most 100 lines of code per platform.
With regards to SDL+Android, have you checked the README?
And for iOS check the same file here.

C++ and Mac OSX

In just about all books I read it mentions windows APIs(e.g. DirectX) when talking about C++ and game programming.
What APIs are for Mac when using C++ or what can be used for multi-platform development?
I want to create games using C++ and am currently on a Mac. I have no problem switching between Unix and Windows if it is needed.
What is recommended for C++ game development and will programming for mac be a drawback?
Or should I just go with C++ and OpenGL and use it for all platforms? :P
I would recommend SFML and OpenGL. SFML is a more modern, C++ oriented, cross platform framework that allows you to write common code for window, keyboard and mouse handling. You would then write the bulk of your game using OpenGL, which is cross platform anyway.
I am using SFML and OpenGL myself to target Mac OS X, Linux and Windows, primarily developing on Mac (I can triple boot into any of the three OSs to develop on them).
EDIT: I've had a change of heart on this as I am a bit spooked by the Mac support in SFML; I am now going to use Qt as it is better supported, provides better tools, better documentation and better examples.
You can use OpenGL wich is cross platform, and use GLUT or SDL for handling input and windows and stuff or use just SDL. (I would go with mixing OpenGL and SDL and because its easier to manage input that way and is still cross platform. Unless your making a 2D game, then use SDL as SDL is for making 2D games).
Ohh and one addition thing about OpenGL on Mac is the header for OpenGL is a little different from most tutorials:
#include <OpenGL/OpenGL.h>
Don't spend hours on that like I did...
Oh, and if you plan to use glut:
#include <GLUT/glut.h>
If you're making a 2D game I would also recommend you try SFML; it's a fairly young library that has the same scope as SDL. It's pure C++ (as opposed to SDL which is just C) so development should be somewhat easier for you, if you like OOP.
It would also appear that SFML is significantly faster than SDL:
► http://www.sfml-dev.org/forum/viewtopic.php?t=43