I read something from here that said using GLUT is considered unprofessional. Swiftless has a fair amount of tutorials and I would consider him among NeHe as "go to OpenGL examples and tutorials". I have used GLUT in several languages in a few projects, though mostly for school projects. I find it very easy to make cross platform OpenGL apps with it.
Is using GLUT unprofessional? If so why?
GLUT is no longer under active development, that's one reason not to use it.
Another is that other wrappers (GLFW, SDL) are not only under active development, but generally more powerful.
Also the callback-oriented API of GLUT is usually not considered very usable. I mean, it works and it is certainly possible to use it, but both GLFW and SDL want you to write the main loop of your program yourself (SDL also has platform-independent yet explicit message handling) which, at least in my opinion, results in MUCH more clear and flexible code.
My conclusion: using some platform independent wrapper for OpenGL is certainly better than, say, WinAPI, but GLUT is probably not the best choice among the wrappers which are available.
No, it is not unprofessional. Use whatever is easiest and fits your requirements. I find freeglut better then glut (different license, and provides better flexibility), but it should be fairly easy to switch from glut to qt or sdl.
I can only argue for it being unprofessional on one point only: it may not be so portable to other platforms (such as Bada OS).
Related
I've checked numerous posts and tutorial about using OpenGL and C++. There is one thing that still bothers me. In each tutorial you have some additional library like GLFW, GLU, GLUT, WIN32 and so on (mostly used for window creation). Although I was unable to find some tutorial using only OpenGL. The only clue is this answer syaing that you need to use some library for this.
Can someone explain how it really is? How it looks when I want to use code on different operating systems? Is application code written with OpenGL 100% portable?
You can't have a tutorial which uses only OpenGL just because it's an API which doesn't provide such functionality.
OpenGL is not meant to create a graphical context in an operating system and use it, it is meant only to work directly with the GPU through a set of defined functions.
So the main point is that what you are asking resides outside the purpose of OpenGL, which defines just a standard interface to graphical operations.
But many more or less complete libraries exist to handle this problem and you also quoted some, for example GLFW or SDL, which takes care of initializing the context and manage also additional issues (for example controls or sounds).
The product will be portable if a set of constraints is respected:
you are using a library which manages different OS for handling the graphical context (eg GLFW)
you are using an OpenGL profile which is supported by all the GPUs you mean to make your code work on
in case of portability between OpenGL and OpenGL ES you must ensure additional constraints since the latter managed certain things differently
I'm currently in the process of writing a game engine which is about to go through a major rewrite. First off, I'm considering what library to use in conjunction with the engine. Obviously, I'm going with OpenGL here and am going to do what I can to make it forward as well as backward compatible.
The main issue, though, is that from most of my research, I've found that great libraries like SDL (except for 1.3 - which, I don't believe is stable? I may be wrong about this) only support up to OpenGL 3 and not 4.2. FreeGlut, however, does support the latest and greatest, and seems like a good way to go for the basics of an engine.
The only thing, however, is setting up something such as Keyboard I/O and sound input audio, along with other things. Thus, I'm considering to see whether or not it's possible to use glut to initialize opengl and use opengl with it, and then have SDL do window management along with keyboard I/O, sound, etc.
Of course, there's always the option of using Qt with OpenGL, but I'd like to definitely have control over my main loop if possible (is this possible with Qt and OpenGL?).
I've heard of SFML, too, but ultimately I'd like to stick with libraries written in C as I plan to write a C library to take care of most of the primitive rendering (for the sake of pure speed and memory management, procedurally).
Thus, I'm at a loss as what to do here. IS Qt a good choice for this, or is there another C-like alternative (such as FreeGlut) which allows main-loop control (like SDL) and offers the necessary customization I'm looking for?
The main issue, though, is that from most of my research, I've found that great libraries like SDL (except for 1.3 - which, I don't believe is stable? I may be wrong about this) only support up to OpenGL 3 and not 4.2. FreeGlut, however, does support the latest and greatest, and seems like a good way to go for the basics of an engine.
Your research is lacking.
First, FreeGLUT should never be used for anything that you would call an "engine". Whatever you mean by that, FreeGLUT is not the tool for the job. It's designed for creating demos, which is why it owns the main loop. I understand that FreeGLUT does have a way to allow you some control over the main loop, but the standard way to use FreeGLUT doesn't do that.
Second, you are correct that SDL 1.2 is not capable of creating an OpenGL 3.2+ core context. However, you don't have to be able to create a core context to use GL 3.2+; compatibility contexts work just fine at those versions. The only platform that has no compatibility context is MacOSX's 3.2 support. So I wouldn't worry about it.
You could try GLFW. It's sort of like FreeGLUT only more game-centric. It gives you control of the render loop and so forth. It provides better input handling than FreeGLUT, as well as some light image loading functions (only TGA files). It even has a threading API (though I wouldn't suggest using these functions. GLFW 2.0 will drop them since both C++11 and C11 have native thread APIs).
However, it has no systems in place for audio.
I've heard of SFML, too, but ultimately I'd like to stick with libraries written in C as I plan to write a C library to take care of most of the primitive rendering (for the sake of pure speed and memory management, procedurally).
I'm going to ignore the fallacy about C++ not having the "pure speed and memory management;" that's a common canard that I'll ignore. The important point is this: SFML, as far as your rendering code is concerned, exists solely to create and manage the window. Your rendering code doesn't even have to talk to it. You call some SFML functions, create a couple of SFML objects, and your "C library" OpenGL code won't even have to know those C++ objects are there.
However, if you absolutely cannot work in C++ at all, you can always use Allegro version 5. It has a C API, and it provides support for OpenGL core contexts, input, audio, and most of what SFML does. It also has pretty decent documentation, and is modular (though in a different way from SFML).
I've had much experience writing in Java, python, C#, and C, mostly for hobby. In all of the applications I've coded that involve displays (simulations, graphers, etc.), I've always just used the stock "Canvas" class of whatever framework I'm using (Swing Canvas, .NET Canvas, pygame once for python).
The downside of this is that all of these have slightly different paradigms in drawing.
I'm starting a project in C++ and was wondering what the best solution is for cross-platform drawing. OpenGL is obviously very low level, but some sort of library on top of OpenGL would be good. I've heard of/read about things like Cairo, SDL, etc., but don't yet know what to go with. I'm already using wxWidgets for interface, but would prefer to use something more standard instead of just a wxWidgets canvas. Obviously, the ability to draw lines and shapes is important, not just display pictures or whatnot.
Thanks for any direction!
I would consider using Qt, and notably its Graphics View framework. (Qt works on Linux, Windows, MacOSX).
SDL is SimpleMedia Direct Layer, which is basically a common interface to interface with the framebuffer and audio devices. If you wanted to create windows and such, it doesn't have general purpose constructs that work cross-platform.
Cairo is for drawing graphics, but still operates at a level that's lower than what WxWidgets provides.
C++ doesn't provide anything standard, so either you go with some platform specific, or you use a cross platform library like Qt (already mentioned by Basile) or stick with wxWidgets. Both are popular and widely used, though Qt is probably much more well-known and used (though that is just opinion). I've used Qt for work and it is very much cross platform and pretty easy to use (but very extensive, so prepare to read a lot of documentation). Luckily it also has a lot of documentation and many examples available.
Plus, both wxWidgets and Qt have bindings in many languages, so you could take the knowledge with either and use it with many other languages.
Open Frameworks is very easy to use and comes with a lot of examples...
it's platform independent and somehow reminds me of processing
I need some specific and some general advice. I'm a fairly proficient Java programmer and a very experienced web programmer, but I would like to get into software development and I've been tackling C++. I have a great idea for a game I'd like to do, and I realize it will be a huge undertaking--but I'm looking at it more for an opportunity to learn C++, wrapping, really whatever I run into in the dev process...
But I can't get my foot in the door conceptually! I can handle the C++ aspect fine, it's just setting up the graphics, the RIGHT way, that's confusing me. I've run through a bunch of tutorials for OpenGL with C++ that all say the different things, none of which I can really get to work...
Some say to use GLUT and GLEW. Some say GLUT is dead and that FreeGLUT is the thing now. Some ignore those entirely and use a bunch of files like "glaux.h" that I can't seem to find--and other tutorials devoted to AVOIDING "glaux.h"... Most tutorials I've found come with the caveat in the comments that their version of OpenGL is dated and I should be using newer libraries-- and still others with 3rd party libraries like Ogre and Aurora.
I've been looking through a bunch of books and tutorials that ALL have an almost completely different setup for using OpenGL with C++. I realized there is probably not one right way of doing it, per se, but I'm looking for the way that is the most current, most popular, and will maximize the usefulness of the project as far as my learning... Any links to tutorials or advice in general is much appreciated.
BTW, I'm using Visual Studio Express 2010 (good idea?). My game won't be too graphically intense (isometric 2d) but will require a TON of logic and a TON of data, which is why I want to speed things up by using C++. Any other insights on better ways of doing it than using c++ for login AND graphics (from an industry perspective) are also very valuable to me! Thanks in advance!
Assuming you're learning OpenGL as a learning experience, I would recommend you this:
Use GLEW, no argument. Just do it, everyone does
Code only to the core profile. By default, OpenGL accepts old command (eg fixed function pipeline) that will later disappear, and you don't want to waste your time on that. Specifically: learn about VBO's, texture's, and, most of all, learn about shaders.
Forget about glaux and glut. Freeglut is a good and very standard option. A less obvious choice would be qt, but it's QGLWidget allows you to easily make gl calls, and not worry about context creation and all that. And it's dead easy to add gui options, which is always very nice to have when programming graphics.
To actually learn OpenGL, I would recommend http://duriansoftware.com/joe/An-intro-to-modern-OpenGL.-Table-of-Contents.html. Nehe has that problem where more than half of the stuff is useless to learn, and there's a lot of fluff (window creation et al) around it.
But, I wouldn't really recommend OpenGL as a way to learn real-time graphics programming. Your alternatives are not limited to DirectX. I learned a ton of graphics coding from working with Ogre3D. You still have all the concepts at your disposal that you need to know (working low level with Vertex and Index buffers, Textures, shaders), and implements tons of stuff to make your life easier. You might not learn the ins and outs of a specific API, but you will learn all you need to know conceptually. When I became a graphics programmer, I hadn't written a line of DirectX code, but I got to grips with our engine really swiftly. I learned the actually calls very easy after that. Know the hardware, and the concepts. The actual implementation changes over time anyway.
Oh, and just in case I haven't repeated it enough. LEARN SHADERS
The best tutorial around is (arguably, as anything "best") Nehe opengl tutorial. At least, this tutorial has been suggested for many years.
Also since you come from a Java background you might prefer C# bindings for opengl from frameworks such as Tao, but the actual setup might be harder than say, downloading samples and running them.
It's easy to see where the variety of choices available for OpenGL with C++ would be a bit bewildering. For the most part, Java gives two a pretty clear-cut choice between two possibilities (do you want a scene graph or not?)
The situation with C++ is certainly more complex.
Glut: This is basically an OpenGL-oriented application framework. It was apparently written primarily to allow examples to be short, but still work. The original implementation has some pretty well-known bugs, and hasn't been updated in over a decade. I would only use it in roughly the originally-intended context: short samples/examples/demos.
glaux: The story here is sort of similar to GLUT. It has some memory leaks that have been known but unfixed for over a decade now. It was never portable in any case. I'd avoid this one completely.
GLEW/GLEE: These allow relatively easy use of the functions added in newer versions of OpenGL from OpenGL implementations (e.g., Microsoft's) that haven't been updated to include headers/libraries to provide access to them directly. I prefer Glee by a small margin because it initializes itself automatically, but both work fine.
FreeGLUT: This has been updated more recently, and some of the bugs expunged. It still hasn't done much to improve the basic design of GLUT though. Probably a better choice for short demos/samples, but still not (IMO) suitable for much serious use.
Ogre3D: This is much bigger than any of the preceding libraries. It's a full-blown scene graph library, with texture loading, defined file format, etc. A solid library, but be aware that if you use it, you won't normally use OpenGL directly at all (e.g., on Windows, it can render via either OpenGL or Direct3D without changing the source code at all).
OpengSceneGraph: More often used for scientifically-oriented applications, but most closely comparable to Ogre3D.
FLTK: a small, lightweight GUI library that runs on top of OpenGL.
GLFW: In the same general spirit as GLUT, but it's been updated much more recently, doesn't have nearly as many bugs, and is (IMO) a nicer design -- minimal but still suitable for "real" use.
You should be using OpenGL if you want to write portable 3D applications. Windows, Linux and Mac OS X supports it.
You might want to take a look at NeHe tutorials. It's one of the best OpenGL tutorials available on the web.
My understanding is that if you want simple support for a recent version of OpenGL you'll have to leave Windows-land, so try take it in stride when getting started is ... complicated.
I think OpenGL is probably the right choice. You might also want to consider DirectX (which is better supported on Windows), but I'm personally not a big fan of it. You could also learn C# and use XNA, but if you want to learn C++ it just defeats the purpose. (I also can't help mentioning there's a good chance you could make it fast enough without C++)
I have to agree with the others that NeHe's tutorials are pretty much classic. You might also want to consider the OpenGL Red Book, but that costs money.
Regarding the 3rd paragraph, GLUT is old (and for that matter so is GLU), but if you see a good tutorial that uses them, I don't see anything wrong with them. Once you have your feet wet you might want to consider ditching GLUT and using SDL which I believe is a lot more 'alive'.
As far as GLEW goes, I've used it with success and it's nice if you want to do something fancy like shaders on Windows. However, I would say don't worry about it at first, because it will increase your setup time and keep you from getting to the fun stuff :)
My main experience is with C && C++, so I'd prefer to remain with them. I don't want to use anything like QT, GTK, or wxWidgets or any tool kits. I'd like to learn native programming and this sort of defeats the purpose. With that in mind I'd also like to avoid Java.
I understand gnome and xfce and KDE and such are all Desktop Environments for Linux, and the base installed typically is X (Xorg). When coding for Linux, do you code for X, or for the desktop environment? Is there a standard Linux header for this (like win32 has windows.h) for Linux? or is it different coding methods for every desktop environment?
any help is greatly appreciated.
X is a hideous layer to program for and, despite your intent to avoid Java, QT or any of the excellent UI abstraction layers, you'll be doing yourself a disservice by coding to that level. I've done it (a long time ago when Motif was in its infancy on the platform we were using) and I would not do it again if there was an easier way.
Your use of the phrase "native programming" confuses me a little. If you want to learn native programming, it's to the APIs that you choose to call. Using similar reasoning, you shouldn't be coding in C either, instead opting for assembler (or direct machine code) since C provides an abstraction to the hardware.
If you want to learn X programming, that's fine. You'll end up with a lot more control over your interface but almost everyone else will be out-performing you in terms of delivery of software. Myself, I'd prefer to code to a higher-level API that I can use on many platforms - it gives me both faster delivery times and more market potential.
You don't build a house out of atoms, you build it out of bricks. My suggestion is to use the tools, that's what they're there for.
I don't want to use anything like QT, GTK, or wxWidgets or any tool kits. I'd like to learn native programming and this sort of defeats the purpose.
No you don't. Back in an early version of X11, like R1 or R2, I coded a complete "Hello, world" program in Xlib alone.
Roughly 700 lines of C.
You don't want to go there.
I guess you could write C code directly against Xlib, but you'd end up recreating all the functionality that GTK+ or QT provide that X doesn't alone.
Unix (and by extension, Linux) doesn't actually define anything to do with GUIs. X, which is commonly used, doesn't define anything to do with widgets or styles or anything of that nature - it's concerned mostly with drawing primitives and event handling. Essentially, if you wanted to write in pure X, you'd be defining the shape and behaviour of every element on screen. If you were crazy enough to abandon X, you'd be working at the graphics framebuffer level...
You're better off using some toolkit - if you're looking for light-weight, why not try FLTK?
GTK, QT and wx are toolkits that build on X to provide a friendlier API.
If you don't use an existing toolkit you'll need to write things at a very low level - directly handling mouse and keyboard events. If you want a button or a textbox you'll have to write it yourself using the low level xlib primitives.
Before trying this you're probably better off picking the toolkit of your preferred desktop environment and starting with that.
There is simply no such thing as "native" in this case. Windows and OS X just have an official option, while X does not.
The "native" interface for Linux & most other Unix-like OSs is Xlib, the lowest-level C API for X11.
GTK, Qt & others are all (so far as I know) implemented in terms of Xlib at their core. As others have said, Xlib gives you maximal control but you'll have to work for it (and others may run circles around you in terms of delivering a product).
As a point of reference, I personally implemented a fairly feature-rich & modern (i.e. flowable) cross-platform (Win32 + X11) GUI library in C++. Total count is about 29 KLOC of C++, of which about 2500 lines each was required for the X11 & Win32 shimming. The rest is for platform-neutral Widget implementations. Unless you're prepared to make a commitment like that, I strongly recommend going with one of the higher level libraries (Qt would probably be my choice, though I can't stand the preprocessor approach).
BTW, a big plus for Xlib is its raw portability--any Unix box with a screen will have it, and it can be made to work on Windows & OS X as well.
I feel it necessary to counterpoint the unanimity of the other answers here. X11 is indeed low level. But to "truly" understand what's going on, you should have some familiarity with how X11 works. Since all the toolkits work on top of X, you're using it whether you like it or not. There is nice tutorial online somewhere that I'm too lazy to search for. It guides you through building a simple Hello World. To do it, you'll have to learn how to create a window, request events, map the window, and process events in a loop. You could even go so far as to order some used books on Amazon. The O'Reilly vols 1 and 2 (for now get the cheapest editions, but nothing earlier than X11R4) are essential for reference and to get the full story of how the pieces work together. For learning, however, the best book is X Window Applications Programming by Eric Johnson and Kevin Reichard.
At some point along this journey, as everyone else says, you will find you've had enough. Two pages of code just to select a visual, and then you still have to populate a colormap before you can paint your custom bitmap. And then two days of rewriting and debugging to realize that it all does work; you just forgot to XFlush()!
The struggle is important, because you'll appreciate the toolkits more once you find the one you like.
I would suggest lesstif/motif as well. It also builds on top of X and the learning curve is, in my opinion, isn't as steep as GTK or Qt. The UI's you build with it aren't going to be as sophisticated as ones you could build with GTK or Qt though. More information can be found here.
As others have mentioned you probably don't want to X it's a pain.
Why not choose one among, say, Qt, wxWidgets and GTK and learn its internals, rather than its API? I do not mean just for the sake of it, but with the aim of contributing to the parts you find most appealing. In this way you'd fulfill your goal and get to do something useful, for you and also for others. I think this would be more rewarding than assigning yourself the rather artificial task of building an application with what amount to the wrong tools.
oh yeah, there is such "native" things:
FBUI, svgalib, directfb, exa(kdrive), SDL, Allegro..+Wayland, although not mainstream.
http://home.comcast.net/~fbui/
http://www.svgalib.org/
http://directfb.org/
http://xorg.freedesktop.org/wiki/ExaStatus
+
http://wayland.freedesktop.org/