I am learning OpenGL but I am a little confused about the way how variables are used. In many example codes written in C++, the variables are used as global variables. But I do not think it is desirable for us to use too many global variables in the program. So I am wondering how can I use variables without violating encapsulation? Or should I use a singleton to record all the variables such as the models?
In many example codes written in C++, the variables are used as global variables
This sound like you're reading examples written using the GLUT framework. That the variables are global is a direct result of GLUTs design to be a minimalistic framework, that's meant for simple tests and techdemos. You should not use GLUT for serious applications.
GLUT is not part of OpenGL. It's a 3rd party library and there's no requirement to use it in any way when it comes to OpenGL. In fact it's highly recommended you don't use it.
OpenGL itself can be used from encapsulated code just fine. Look for OpenGL examples that use the Qt framework. IMHO the way Qt implements OpenGL widgets and context encapsulation is suboptimal (only recently I've run into serious limitations), but if you're an beginner you'll hardly notice that.
Related
I'm developing a C++ app using Qt. The app displays some various customized widgets that are made using QML. These widgets renders values using signal/slot system.
I was wondering what could be the best way to manage:
Manage everything in qml files, including rendering and business rules.
Embedding qml files into QWidget class (QQuickWidget) and managing rendering and business rules in c++
When you want to get things up and running fast doing the buisness logic in QML is a good way to go. But things will getting complicated when adding new features. After a while we got a lot of cascade-like callbacks by depending signals-slots in your QML-files. Special when mixing view- and buisness-code in one QML-file will make your code hard to maintain.
To avoid this using some kind of MVC or MVVM-pattern to separate buisness-logic from your view-code makes sence. And of course you can do the buissness-logic in QML. Separation of concerns helps a lot to keep your code-base understandable independent from your programming language.
When you have any performance-concerns regarding your buisness-logic using C++ for it is the best way to go ( made these experiences when starting with a first prototype in QML and needed to port it to an embedded platform ). And you can use C++ for some special QML-Elements as well of course.
So it strongly depends on your problem.
Depends on how complex your core logic is. If it is small and simple, do in QML. Even if it is not that small and simple, there can be quite a lot of benefits to using QML, as prototyping there is much, much faster and easier compared to C++. You don't have to recompile, you don't get crashes but fairly useful error messages. I find QML to be 5 to 10 times faster for prototyping than C++.
You can always move things over to C++ if you want better performance or memory efficiency, and it is a seamless plug and play transition, because you can use signals and slots in both worlds. It is usually faster to develop the algorithms in QML and port to C++ than to do in C++ from scratch. The downside is you have a different toolset on the low level, in C++ you can use Qt's core classes whereas in QML you will have to use JavaScript and its programming idioms. It really depends on how much experience you have with both, but with some practice, it is quite easy to translate QML to C++.
That being said, even if you opt for QML for the logic, it is always a good idea to have it as a separate layer from the GUI.
Unless you need QWidgets for something else, there is absolutely no good reason to use QQuickWidget, thus you can avoid the entire widgets module as a dependency. You do not need widgets to do the core logic in C++.
I am a student of programming, and have programmed in many different languages.
However, I have used c++ only once and in a very non-professional way.
I have had no formal training in c++, and yes I am doing something about that, as it causes tons of confusion when things look very different from say Java, which I have had formal training in.
A lot of help I try to find recently has been so non-concrete I have gotten no where with almost all my questions, and here is a very specific one:
I wish to make a very simple game. I have never been shown concretely how to render graphics. I want to use the most basic library I can to render them, which from what I can tell (in Windows that is) is GDI. I found this page: https://msdn.microsoft.com/en-us/library/d420az6e(v=vs.110).aspx
When I try to #include or use the namespace the classes say they are a part of, errors pop up like crazy.
Why is that? How to I import these classes so I can use them?
The link you have is for GDI+, not GDI. Despite almost identical names, they are not the same thing. GDI provides the most basic access to the display, via C calls only (no classes or any other OO stuff) and dates back to Windows 2.0.
GDI+ is more modern and has some improved capabilities, but it's still a bit outdated. As mentioned in the comments to your question, that link is for the .net API, if you're writing a native C++ application you won't be able to use it.
There is a native interface for GDI+, via COM. Take a look at this link.
I am new to SDL programming. And in one of the tutorials, http://twinklebeardev.blogspot.in/2012/07/lesson-2-dont-put-everything-in-main.html it is mentioned that the SDL Window,and SDL Renderer should not be declared as global?
What is the technical underpinning behind it ?
There is no reason as far as c standard and sdl library are concerned, to not use SDL Window and SDL Renderer as global variables.
A think is more a recommendation than a mandatory order. If they are declared locally, you will structure your code better and is easier figure out where these are being used. If you declare them as global you can quickly forget what parts of your code are using it and some small change in a part of it can break everything without giving you any clue about it.
The rule of thumb is never declare any globals except if extremely necessary.
There is nothing technically preventing the use of globals, it's more a matter of taste and choice of language.
The author of the tutorial is speaking from the point of view of using SDL from the c++ language. In C++ there is a strong emphasis on object-oriented code structure, including encapsulation and abstraction (i.e. hiding the details of an implementation behind a class structure).
The author goes into more details regarding global objects and classes in tutorial 7, which might be useful to get a better understanding of their design process.
So I've fooled around with WPF a bit recently, and I must say that I really like the idea. I love the framework as a whole, from the GUI to the plumbing.
However, as much as I love managed land, I love my native code just as much. So I'm wondering what sort of libraries exists for C++ which capture the essence of various parts of WPF. I'm not looking for interop solution, nor do I want Managed C++ or C++/CLI solutions, but pure C++ solutions.
Now, I'm not expecting to find a "copy" of WPF for C++ - I wouldn't expect that to exist, nor would I need it to. Instead, I would expect that different libraries might capture a subset of the desired concepts. My particular interests are
Hardware accelerated graphics for widget based GUI's (via DirectX or OpenGL, preferably the latter)
Declarative language for GUI design (preferably an XML dialect)
Data binding
Resolution independence (less important)
To say a little about my reasoning, I would like to implement such a library myself, which captures a specific model that I have begun working out. I am in the process of finding some more inspiration and helpful resources before locking down my design. The library is intended to be cross-platform, so references to cross-platform ideas would be great, but not strictly necessary as I am usually capable of translating things into cross-platform solutions.
Lastly, although I am writing a C++ library, and C++ ideas would be great, I am open to ideas from any native language.
Thanks in advance for any help.
There isn't really anything like this. Not cross-platform at any rate. Direct2D works reasonably well, but is obviously Windows-only. And NVIDIA recently dropped this "path" extension of OpenGL that is similar in basic functionality, but it is NVIDIA-only (and not available on Mac OSX). Cairo has an OpenGL backend, but I have no idea how good it is. It can't be that good if Mozilla dumped Cairo in favor of D2D on Windows.
Many GUI toolkits have some form of language for making a GUI. Qt has one that is pre-compiled into C++.
Not that I know of. Data binding requires some form of reflection (WPF-style data binding does), and C++ has no native support for reflection. So you would need to implement reflection of some sort before you can even begin to make WPF-style data binding work.
That comes with #1. More or less, as any GPU-based renderer will be able to operate at arbitrary resolutions.
I love C++, but honestly, this sort of thing is best implemented for a higher level language. The lack of language-based reflection support will make implementing data binding a huge pain. Whereas, you could just implement the low-level "render stuff to area" and basic window/event management in C++, then expose it to a scripting language where data binding and such work. That way, you have native code speed where you need it, but the versatility and reflection of a scripting language for dealing with the GUI and its associated data.
I'm several years late, but for the benefit of anybody else reading this question: you're looking for Qt Quick / QML:
http://qt-project.org/doc/qt-4.8/qml-intro.html
http://doc.qt.io/qt-5/qtqml-cppintegration-topic.html
I have often seen the spinning gears OpenGL example ( I think originally done by SGI) but I today I have only been able to find C and Ruby implementations, can anyone point me to a c++ implementation?
What, in particular, would you be looking for in a C++ implementation that the C one doesn't provide? OpenGL is a C API, and thus a C demonstration is practical. A C++ implementation would call all the same functions in the same order and to the same effect, it would likely just wrap the implementation in an object. This doesn't really further one's understanding of the core API, and can possibly add a layer of obfuscation to those not familiar with some C++ styles and patterns.
If what you are really looking for is an example of initiating OpenGL wrapped in a C++ framework, I made a few of those a while back. You can find them here. Please note that I'm no longer actively maintaining the code or page, though.
If you want to mess around with OpenGL i strongly reccomend using OpenSceneGraph (OSG) since you can focus better on computer graphics aspects instead. It's using all the C++ magic and design patterns.