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
Related
I've recently started learning OpenGL (> 3.3) & I've noticed a lot of examples & tutorials use both freeglut & glew, but don't really explain the difference at all. The best description I've found, after googling & reading ad nauseum, has been this OpenGL Related toolkits and APIs but found it lacking. I've even read the tag info on SO.
As someone really new to OpenGL I'm still trying to get a grasp of the different concepts. I've gotten to the stage of creating a basic program that uses glew, create context (on windows, VS2010), & draw really basic shapes, all without the need for explicitly including freeglut. So I don't understand why I would need it.
So my question then is, what's the difference between:
-freeglut
-glew
-(& glfw)
What can one do that the other can't?
The OpenGL Extension Wrangler (GLEW) is used to access the modern OpenGL API functions(version 3.2 up to latest version).If we use an ancient version of OpenGL then we can access the OpenGL functions simply including as #include <GL/gl.h>.But in modern OpenGL, the API functions are determined at run time, not compile time. GLEW will handle the run time loading of the OpenGL API.About GLEW see here
GLFW or freeglut will allow us to create a window, and receive mouse and keyboard input in a cross-platform way. OpenGL does not handle window creation or input, so we have to use these library for handling window, keyboard, mouse, joysticks, input and other purpose.
GLFW and freeglut are alternative for us according to our need we can choose any one but GLEW is different from them which is used for run time loading of the OpenGL API.
I'm using both of them for some work at my university.
GLEW is a "cross-platform open-source C/C++ extension loading library" (from its website), while freeglut is a window manager that replaces the default OpenGL Utility Toolkit (GLUT) library.
So, as you see, both different have different purposes. The point of using freeglut is that it's still maintained, while the default GLUT isn't, so if you want bug fixes and new features you should use it :)
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.
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.
I need a cross-platform GUI toolkit with OpenGL support. I also need to be able to draw on a canvas or panel from an image buffer. The candidates I've chosen so far are FLTK (it can do OpenGL windows -- I don't know about canvases), Qt, and wxWidgets.
Any idea which would be the best?
Thanks!
I would say Qt. But that might be argumentative question...
Hey Deep, XVT support openGL. It's a GUI cross-platform toolkit for C and C++ www.xvt.com
For simple things I would suggest GLUT or something similar. But for anything above a simple window into which you render some OpenGL, I strongly recommend Qt. But as tibur said, its probably a matter of taste.
Checkout the Ecere SDK. It's a feature rich cross-platform GUI toolkit, and it supports a variety of graphics driver (e.g. GDI, X11, OpenGL, Direct3D). It has a built-in 3D engine, but you can mix it with your own OpenGL code as well, there are samples showing you how to do just that. It was originally designed as a GUI system for in-game menus, so it supports full screen mdoe as well as windowed mode, but is now a general purpose SDK.
I have a simulation software (C++) that runs on the command line. It is platform independent (currently compiling and running on Windows, MacOS X and Linux). When the simulation ends, I visualize the result with SDL; it is a very basic 2d view, mainly color squares next to each other.
I would like to have a user interface on top of the simulation so that I can start and pause the simulation, and change the parameters on the fly. Something pretty simple I guess. Well, ideally I will also add a grapher somewhere to see the evolution over time of some parameters.
Now, I am wondering what direction I should go.
Should I try to use one of the UI libraries for SDL ?
Or maybe wxwidget in conjunction with SDL ?
Or simply wxwidget and get rid of SDL ?
Do you have any experience with this ?
Thanks in advance
Barth
PS: I tried to use AGAR, a SDL UI library. It seemed very promising but I couldn't get it working. Not even the helloworld.
It may be worth you time to look into Qt. It is generally the most mature free Gui framework available. It is cross platform. And it has hardware accelerated rendering if your drawing needs some speed.
Here is a comparison posted on WxWidgets site.
In the end if your windowing needs are minimal you should choose the framework you are most comfortable with.
Probably using wxWidgets without SDL would be the easiest way to go. SDL is a media layer -- it's supposed to allow cross-platform media application development. As you only need graphical display, you only need wxWidgets -- and it will be a lot easier too!
You would benefit from SDL if:
you'd need very fast blitting of very large amount of surfaces (we're talking the 60fps range here)
you'd use RLE, color keying or other graphics operations
you'd use other media (sound, advanced real-time input, etc)
you'd need to run the software on embedded systems (handheld consoles, etc)
If the answer to all 4 is "no", then you won't benefit from SDL, and using wx alone will be much easier.