What does GLFW acronym stand for? http://www.glfw.org/ is the main website, but I cannot find any clue there. Evenhere on SO it has a tag but in the description the acronym is not explained.
Apparently, it used to stand for OpenGL FrameWork--link. I think I prefer some of the alternative interpretations given on the wiki, though.
Wikipedia states "Graphics Library Framework". This makes sense, as GLFW is no longer an OpenGL focuses library, but also supports Vulkan.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
Borrowed a book from the Uni Library. It wasn't what I was hoping for...
Hi, I am a student and over the summer I borrowed the OpenGL Programming Guide, for version 4.3, which was the only version my University seemed to have in the main library.
I already know a little bit about using OpenGL with SFML, SDL and glut. I borrowed the book to help me extend my knowledge.
Unfortunately I have found the 4.3 book very heavy going and difficult to follow. I was sure I had read a similar book (an older version, when it used to be called "redbook") and found it much easier to follow.
I was able to borrow the Version 2.1 book, and I am fairly sure this was the one I had read parts of. So far I have found it much easier to follow. It is certainly much better suited to non-experts and people with less experience.
Please don't close this question...
This might be the sort of question which gets poor reception, and gets voted to close, but please don't do that - I would like an answer to my question. I think this is a programming question, and would be helpful to others like myself. As I explain later, I am looking to buy the book for Version 2 or Version 2.1, and would like some advice.
TLDR? Question starts here:
Basically I would like to know what the main differences are between OpenGL Version 2 and Version 2.1. As far as I can tell, there is a book for Version 1.0 or something like that, then 2.0, 2.1, and then 3 or 3.5 or something. Why is there a whole new book for a version increment of 0.1: As in from Version 2.0 to 2.1. I am assuming some major changes were made or extensions and functionality added in the 2.1 release?
Reason for asking is I liked the book (Version 2.1) so much, I thought I should buy it! (Madness, no?) Anyway, I want to know what extra stuff is in Version 2.1, or what has changed, so I can made a decision about if spending extra is worth it.
This is probably not the answer you were hoping for, but: don't bother learning OGL < 3.0. All of OpenGL is well documented and everything you need to know can be found on the internet. Also note the redbook is entirely free on the internet, at least the relevant parts (as far as I'm aware). Anyway, it heavily focuses on the older, deprecated functionality, I wouldn't consider it worth reading anymore.
OpenGL 3.0 introduced the deprecation mechanism, thus most of OpenGL 2.x features were deprecated. This includes client side memory, fixed pipeline, built in lighting calculation etc. OpenGL 2.x does include programmable pipeline features and server side buffers, but I would still strongly recommend using modern OGL. Simply because you can't be cautious enough. OpenGL 2.x invites you to use older functionality, as it is terribly easy to use, but possibly a felony.
The programmable pipeline, server side buffers and all the goods from OpenGL 3.x and up are perhaps hard to learn about. But once you're able to proficiently use these features, you will be blown away by its power. In your comment you mentioned particles, it is so much more fun to experiment with particles if you have the ability to use transform feedbacks, compute shaders, geometry shaders, instanced rendering and so on. The truth is that modern OpenGL is hugely supperior to older OpenGL, it is much, much faster and designed for modern hardware.
I don't know why each minor version has a new book, people have an addiction to books I suppose. But OpenGL 3.x and up really deserves a new book. It is entirely different from previous APIs - at least its usage is. Now I personally dislike books, but that's just me. A great starting point to learn about OpenGL 3.x and up on the internet would be:
http://www.arcsynthesis.org/gltut/index.html
http://ogldev.atspace.co.uk/
http://www.opengl-tutorial.org/
The first link is a great source for getting to know the pipeline, I strongly recommend reading it all. I really like the second link, it has a bunch of small tutorials on a range of subjects, it is also a great source to get to know more complex algorithms. The third link is a more beginner style tutorial in case you get stuck.
Also this one has all the information and detailed documentation you could ever wish for, keep track of it regardless of what source you're going to use:
http://www.opengl.org/wiki/Main_Page
You also mentioned you want to experiment on a linux environment. Make sure to update your OpenGL drivers (do this on any OS actually). Now according to the website Mesa only supports up to OpenGL 3.1. I would recommend using proprietary drivers just so you can use all of what your GPU has to offer (personally, I'm running OpenGL 4.2 on linux mint using AMD drivers), this includes things like geometry shaders, tesselation and similar.
One last note, OpenGL ES 2.0+ is easier to convert to/from newer OpenGL versions. OpenGL ES 2.0+ does not use fixed pipeline, nor client side memory and alike. And a similar API runs on the web, even the web has moved on, so should you :P
Now get out there and start OGL'in!
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
OpenGL or DirectX?
I've been looking on the internet for some time now, I've even read this post: OpenGL or DirectX?
but it either doesn't really tell me exactly what the difference is or people just post "what they think they know" about it.
I really want to know exactly what is the difference between them so that I can at least try and make my own judgement on which API to use when create my games.
As the comments have pointed out DirectX is mainly tied to windows. OpenGL will give you portability. However there is another major difference. DirectX is a full game programming library as it caters for graphics, networking and sound programming to name a few. OpenGL is just a graphics library it does not provide you with sound and network capabilities for example. However graphics wise OpenGL is probably going to give you better performance as you can really tweak it.
You use DirectX when you want to restrict yourself to Windows and XBox. You use OpenGL when cross-platform viability matters.
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 :)
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).
I got the book "Programming Role Playing Games with DirectX 2nd edition" and I notice there are things in the book that are now considered deprecated. There is a whole Section on DirectPlay. And as much as I would like to avoid this section, I am afraid it might screw up the entire engine he is trying to build.
So I was just curious to know even though DirectPlay is considered deprecated by XNA, and directX10. Is it possible to use it still in DirectX 9 ??
Sure you can use it. You can write your entire game in DirectX 3 if you want. DirectX 9 includes ALL previous releases. The only issue you will have is finding the headers.
TBH, though, you'd be best off ditching it and learning sockets programming instead. Sockets will NEVER go away. They aren't particularly difficult either.
At least you wont be learning an unsupported, no-longer documented API.
Its also worth noting that there was a reason nobody used Direct Play in the first place ;)
DirectPlay is considered deprecated long before DirectX10. Direct3D was the only meaningful construct in DX9 for the vast majority of people. DX10 offers more, like with D2D.
You should check out Introduction to Game Programming in DirectX9:A Shader Approach by Frank Luna. That's a 9.0c book (and doesn't use any old features) and there's D3D10 as well.
You can use it in DX9, but you will probably have to set it up to use the same DX version as the the book is using rather than the interfaces in DX9. (There is a #define for this somewhere, hopefully described in your book.) I agree with the other poster about learning sockets, but you can do that after you finish the game in the book.