![[de]](/mwf/flags/de.png "Germany")
If you really think about to change to git, then there's just a small step using the Qt libraries (or even the complete SDK) when you want to work with the GUI.
Wikipedia article
Download Page
Wikipedia article
Download Page
![[gb]](/mwf/flags/gb.png "United Kingdom")
When you look at this page you will see, that Qt projects use git, too.
A lot of projects do. What makes Qt special? Do they provide a nice Git GUI, possibly? Hm, apparantly there's something called QGit...
Just take the module QtOpenGL, for example. It can be used as OpenGL wrapper for windows systems that doesn't support OpenGL. This means you just have to add this module and don't need to think about the DirectX software mode anymore.
The link you gave is for a python library. Even if it were available for C++, the whole engine would have to be changed to use that library instead of OpenGL. I'd rather use something like GLDirect then.Generally, I am not a believer of huge "do-it-all"-frameworks. They tend to bring lots of dependencies and cause trouble whenever you want to use other libraries that are not part of the framework. I prefer using smaller libraries that are limited to the job you want to use them for.
Really? How would it support GLSL shaders on platforms that don't have OpenGL? And OpenGL already is pretty portable and easy to use, so I don't really see a reason to abandon it.
When you're using the QtOpenGL module you don't abandon OpenGL, you encapsule it inside the QtFramework.
And yes, there are two classes that support GLSL shaders:
QGLShader is used for compiling, and QGLShaderProgram is used to link and use your Shaders.
After you encapsuled your whole OpenGL code part by part, then the QtFramework will wrap it to the platform-dependent API, in case of Windows it's WGL.
But Sven2 said wise words, too: If you use this quick & dirty way, you get a software renderer in just no time, while "dirty" means a lot of depencies that would make more trouble than you like. (For hardware rendering you have to wait until Qt 5 will be released.)
And yes, there are two classes that support GLSL shaders:
QGLShader is used for compiling, and QGLShaderProgram is used to link and use your Shaders.
After you encapsuled your whole OpenGL code part by part, then the QtFramework will wrap it to the platform-dependent API, in case of Windows it's WGL.
But Sven2 said wise words, too: If you use this quick & dirty way, you get a software renderer in just no time, while "dirty" means a lot of depencies that would make more trouble than you like. (For hardware rendering you have to wait until Qt 5 will be released.)
The linux kernel uses git too (source) so we should really think about building an own kernel on top of Clonk when we have git!
There is one reason, why you should use Qt as soon as possible: platform-independence.
Now, the OpenClonk-Engine supports pure OpenGL (plus the help of the GLEW-library), that looks like this:
Now, the OpenClonk-Engine supports pure OpenGL (plus the help of the GLEW-library), that looks like this:
If you were using Qt (e.g. because a graphics driver doesn't support OpenGL 1.3.), it would look like this:
Wait, for what application are you suggesting Qt? The console mode?
Qt is a pure graphics library, so it's for GUI-mode only. It helps, that a menu screen looks the same on every platform like Java Swing does, too. But other than Swing that can be used with Java only, Qt can be used with C++ natively or other programming languages by using special bindings. With the scripting language QML it's even possible to make a web version of the game. There is also a project that helps to port Qt programms on Android, called Nessecitas.
When using Qt, there is no need to make a DirectX-Version for Windows or a GTK-Version for Linux only. But there's one problem, on Linux and Mac you can dynamically link the Qt library to your game, on Windows you have to statically link it, which means, you have to put the dlls into your game folder. And I still didn't manage myself to integrate Qt on Eclipse on Windows. On Linux there's no problem to do that.
When using Qt, there is no need to make a DirectX-Version for Windows or a GTK-Version for Linux only. But there's one problem, on Linux and Mac you can dynamically link the Qt library to your game, on Windows you have to statically link it, which means, you have to put the dlls into your game folder. And I still didn't manage myself to integrate Qt on Eclipse on Windows. On Linux there's no problem to do that.
>Qt is a pure graphics library
Not from what I know. Qt::String would f.e. not be needed for a pure graphics library. Qt is a lot more (localization etc.).
Also I have no idea why we should use Qt instead of f.e. Ogre3D.
I believe even though your intentions are good, you are either firing at the wrong target or with the wrong gun. :)
> But there's one problem, on Linux and Mac you can dynamically link the Qt library to your game, on Windows you have to statically link it, which means, you have to put the dlls into your game folder.
what
To be more specific, when you're using a Linux distribution, especially those that are using KDE, Qt is used as a shared library. So every programm, that needs Qt, can use that version that is already installed. This means "dynamically linked". In case of those distributions, these libraries will be updated, when the distributor "thinks" it's necessary. So every Qt-programm is usually up to date.
On Windows (and even on mobile devices), Qt isn't installed, usually. So every programm, that needs Qt, has to install the libraries by itself in it's own folder. In case of Windows these are dll-files. This means "statically linked". The only problem in this case is, that the included dll-files can be out of date and the maintainer of the programm has to look for a newer version by himself.
On Windows (and even on mobile devices), Qt isn't installed, usually. So every programm, that needs Qt, has to install the libraries by itself in it's own folder. In case of Windows these are dll-files. This means "statically linked". The only problem in this case is, that the included dll-files can be out of date and the maintainer of the programm has to look for a newer version by himself.
OpenGL calls aren't translated into DirectX calls on Windows.
Seriously, graphics? I guess you are also making these kinds of videos... Anyway, I'm still wondering what kind of objective you have.
You forgot to include the SDL port. Anyway, patches welcome: An additional Qt port alongside the Win32, GTK, SDL, Cocoa ports wouldn't make maintenance significantly harder, so there's no reason to reject it. It could then compete on its merits.
At first, it should be possible to use some kind of wrapper, just to test, if it works. That would help those users, whose graphic cards doesn't support OpenGL 1.3. Searching through the internet, I found 2 OpenGl to DirectX wrapper, one for Windows 8 RT only, which is in alpha status, and one for older Windows versions. Problems are: They are freeware, so modifications aren't allowed, and they are a help for Windows users only.
A universal OpenGL to Qt wrapper, which would be helpful for Windows, Mac and Linux users, doesn't exist, but as I mentioned some posts before, there is a special module inside the Qt library. So you can think, what I've read in most forums about such a wrapper: Do It Yourself!
A universal OpenGL to Qt wrapper, which would be helpful for Windows, Mac and Linux users, doesn't exist, but as I mentioned some posts before, there is a special module inside the Qt library. So you can think, what I've read in most forums about such a wrapper: Do It Yourself!
> A universal OpenGL to Qt wrapper
I think you have a major misunderstanding about what the QtOpenGL module does. Namely, it wraps OpenGL, not the other way round.
E: also it doesn't implement software rendering for OpenGL the way e.g. Mesa does. So I'm not sure how Qt would help with GPUs which don't support OpenGL 1.3.
Yes, there is a misunderstanding, because of the word 'universal'. On Linux you maybe know the ndiswrapper, that you need especially for Fritz!-WLAN-Sticks. Because AVM offers Windows drivers for their sticks only, ndiswrapper is used as a "translator" between the Linux Kernel and the Windows driver.
With universal I didn't mention, the OpenGL/Qt-Wrapper has to translate the graphical output from OpenGL to Qt and vice versa. I meant, the wrapper should translate from OpenGL to Qt only, and, because it should be an application for its own, it has to work with other programs that use OpenGL only, too.
With universal I didn't mention, the OpenGL/Qt-Wrapper has to translate the graphical output from OpenGL to Qt and vice versa. I meant, the wrapper should translate from OpenGL to Qt only, and, because it should be an application for its own, it has to work with other programs that use OpenGL only, too.
What do you even want us to do? You're proposing to use Qt because something about a wrapper for people whose GPUs don't support OpenGL 1.3, but Qt doesn't help here in the slightest. Or maybe I'm still misunderstanding and you're asking us to write a translator from OpenGL calls to QPainter? Yeah no that's not going to happen because the OpenGL spec is huge and to be honest it's a massive waste of time because other people have already implemented an OpenGL software driver. Qt wraps the platform specific GL setup code, which is nice, but that's also a minuscule part of the code that's required to render a scene.
There's also https://code.google.com/p/angleproject/, which would require a port to OpenGL ES first, but that'd be useful anyway. GL2DX looks far too incomplete.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
