I thought this should be easy, but... geesh! A vendor gave me a fairly simple demo program meant to showcase some trivial icon animations. The target platform is an embedded system (MX51) with accelerated OpenGL ES 2.0/OpenVG and EGL support.
Unfortunately, the demo also has an annoying dependency on a few Qt utility classes (e.g., QImage). If not for this dependency, I would compile/run the thing on the target. But I don't relish the thought of cross-compiling Qt just to run this little demo---even if there were enough room for it on the embedded board.
I hoped I might be able to run the app on a standard(ish) Ubuntu 10.04 VM, and started following these directions to make it happen. And I actually managed---like, 10 hours later---to compile everything and get a runnable binary of the demo program. However, when I run it, I see the following error:
eglCreateWindowSurface: egl error "EGL_BAD_CONFIG" (0x3005)
Sigh. Not what I wanted to see after all that effort. This seems way more difficult than it should be.
Is the embedded GL landscape really such a ghetto that I have to run even trivial programs on the target using some vendor-supplied BSP? Judging from the lack of responses to this guy's question, I'm thinking the answer might be yes. But I don't even care about acceleration (yet). I just want to run the stupidest of OpenGL ES 2/OpenVG programs on a desktop PC and get an idea of how it looks. (It doesn't matter to me whether the PC is running Linux or Windows.) How do people do this sort of thing?
There are several OpenGL ES 2.0 emulators, such as:
For ARM Mali GPUs
For PowerVR GPUs
Also very recently, AMD has posted drivers that expose OpenGL ES 2.0 on desktop.
More recently, OpenGL 4.1 exposes the GL_ARB_ES2_compatibility extension, which makes OpenGL 4.1 drivers GL ES 2.0 compatible.
For OpenVG, you can use AmanithVG GLE.
Qualcomm's OpenGL ES emulator includes OpenVG support. You can download it from http://developer.qualcomm.com
Related
Qt5 can use the OpenGL driver or the DirectX Driver by using ANGLE. As we cannot depend on an installed OpenGL driver, we need to use the ANGLE backend. Unfortunately, this doesn't solve all deployment problems especially on Windows virtual machines without hardware acceleration. On these systems, we're getting an error message saying that the creation of an OpenGL context failed.
Screenshot: Failed to create OpenGL context for format QSurfaceFormat
We're deploying all required libraries (libEGL.dll libGLESv2.dll libeay32.dll msvcp110.dll msvcr110.dll d3dcompiler_46.dll) but we're still getting this error message.
How do you deploy a QML application that needs to run on end user machines without OpenGL driver and on (virtual) machines without Direct3D Acceleration?
There is a page on the Qt wiki mentioning this problem, but that's not very helpful for solving it.
Update for Qt 5.4.0:
My findings so far are:
Setting QT_ANGLE_PLATFORM=warp -> creates a windows without content.
Setting QT_ANGLE_PLATFORM=d3d9 -> same error dialog, as expected.
Setting QT_ANGLE_PLATFORM=d3d11 -> same error dialog, as expected.
Setting QT_OPENGL=desktop -> same as QT_ANGLE_PLATFORM=warp.
Setting QT_OPENGL=angle -> same error dialog, as expected.
Setting QT_OPENGL=software + opengl32sw.dll (mesa for windows) -> unpredictable: May run, may crash, may show the error dialog.
Update for Qt Quick 2D Renderer
Although, Mesa seems to be a partial solution, the configration seems to be very crash often in Qt 5.4.0 .
Another fallback could be the Qt Quick 2D Renderer, but unfortunately this crashes too.
Copying softwarecontext.dll into /scenegraph + Setting QMLSCENE_DEVICE=softwarecontext -> crash
Update after some user experience:
Angle
Has some render bugs on some systems
Does not work reliable on all systems
Angle with Warp
Not reliable
Desktop OpenGL
The default implements OpenGL 1.1, which is too old.
Not reliable, even if the OpenGL version is ok.
Has render bugs, if used by Qt
QtQuick2dRenderer
Has some major render issues
Crashes, Freezes
Works on systems without HW acceleration
Mesa OpenGL Backend
Seems to be quite reliable at the moment
quite slow in general, very slow on some systems.
Heavy Deployment weight
Conclusion: there is still no real solution for these systems
Update for Qt 5.5
Anno 2015: Broken graphics drives are still broken.
My conclusion for the moment is:
Use QtQuick2dRenderer if possible.
Use Mesa backend otherwise.
Skip Angle, skip Desktop OpenGL, skip Warp.
QT 5 has huge compatibility issue with opengl on some hardware configurations
Combination of Intel HD3000 driver and Nvidia/ATI card won't work on Windows 10.
https://bugreports.qt.io/browse/QTBUG-42240
Intel drops support for this card but their drivers has bug that leads to crash.
You cannot rely on hardware opengl if you want to support customers with HD3000.
Under Windows, opengl32.dll is the default OpenGL driver. It implements OpenGL 1.1 (really old version).
ANGLE has a baseline of OpenGL ES 2.0 and needs DirectX 9/11 installed to map the calls into.
So if you got a video card that doesn't have an OpenGL driver installed, an OpenGL driver less than 2.0, and/or DirectX 9/11 not installed, your app is not going to work.
In regards to virtualization and 3D acceleration, these maybe worth a read:
Why does Qt Creator 3.0.0 Welcome Mode not work in VM?
https://bugreports.qt.io/browse/QTBUG-34964
Also, if you run a multi monitor Windows environment under VirtualBox, 3d acceleration will be disabled.
I re-checked this to see if these problems have been fixed by the latest release of QT 5.12.2, but no they have not. The function described in the QT wiki entry OP referenced
https://wiki.qt.io/Qt_5_on_Windows_ANGLE_and_OpenGL sounds good but in practice it simply doesn't work.
I conclude avoid OpenGL on QT in any form. It's just too unreliable.
I've read places that Windows Phone 8 will not support OpenGL, and I'm unable to find anything useful in the SDK.
So am I or will I ever be able to use OpenGL (ES) in my Windows Phone 8 game? I have a game I would like not to rewrite completely to DirectX when porting.
Please cite good sources, the only thing I've found are speculations and blog posts with little to no information.
OpenGL isn't supported on WP8, but Direct 3D feature level 9_3 is supported. If you're looking to port over a game from OpenGL ES over to D3D have a look at the Angle Project. Angle Project helps bridge the gap between OpenGL ES 2.0 and D3D 9. It doesn't have WP8 targeting just yet and you'll have issues with runtime compile shaders not being supported on WP8, but Angle project is still a good first step.
Either way, for games portability with other platforms it's really best if you work with a middleware gaming framework such as MonoGame, Unity, Cocos2D, Havok, Marmalade, SharpDX, Ogre, Autodesk Scaleform or others. These engines will mostly handle cross platform support for you within their own framework (each with it's own limitations on code and assets portability).
If you already have an existing OpenGL game you want to port over to WP8, than Angle project if your best bet going forward. If you're just starting out creating a cross-platform portable game than choosing a gaming middleware framework that seems right for your game's needs is the way to go.
Marmalade does let you write OpenGL ES 2.0 code and make it work in Windows phone 8 without making you do anything
Check this for more details:
http://www.madewithmarmalade.com/windows-phone-8
Even if Windows Phone 8 supported OpenGL (which it doesn't), it would support OpenGL ES, not destkop OpenGL. Since it's for embedded platforms.
So that's no twice.
Gideros uses OpenGL and targets Windows RT/Phone graphics by means of a lightweight DX wrapper.
So, we've got a little graphical doohickey that needs to run in a server environment without a real video card. All it really needs is framebuffer objects and maybe some vector/font anti-aliasing. It will be slow, I know. It just needs to output single frames.
I see this post about how to force software rendering mode, but it seems to apply to machines that already have OpenGL enabled cards (like NVidia).
So, for fear of trying to install OpenGL on a machine three time zones away with a bunch of live production sites on it-- has anybody tried this and/or know how to "emulate" an OpenGL environment? Unfortunately our dev server HAS a video card, so I can't really show "what I've tried".
The relevant code is all in Cinder, but I think our actual OpenGL utilization is lightweight for this purpose.
This would run on windows server 2008 Standard
I see MS has a software implementation for OGL 1.1, but can't seem to find one for 2.0
Build/find some Mesa DLLs.
It will be slow.
I'm developing a cross-platform application and am not very familiar with the Mac platform. I use Qt for the GUI. I use a QGLWidget to make sure the drawing (with QPainter) is done in OpenGL.
My project built fine in XCode and runs. However, drawing is slow as hell, in situations where on Windows and Linux machines speed is not an issue. The Macbook has an Nvidia GPU, whereas the Windows machine has only onboard intel graphics.
When I look at the binary, it seems that while linking to QtOpenGL lib, it does not explicitely link to the GL lib itself.
How can I test if hardware acceleration is working or software fallback rendering is doing the job?
Shouldn't my binary link to the GL lib, or is this hidden as being a recursive dependency?
The best way to see what OpenGL implementation is using is to print the value of glGetString(GL_VENDOR) and glGetString(GL_RENDERER), this should help pinpoint the problem.
I want to learn Ocaml or Haskell and I want to do it by writing a simple game. Apparently, there's one small problem: nobody cares about Windows and I want to do it on Windows, natively.
Haskell has Cabal, which has SDL, but it doesn't build due to a trivial problem with no workarounds (order of parameters passed to gcc). Ocaml doesn't even have that, it's all in source packages, be it GLCaml or OcamlSDL or whatever.
Is there a place where I can get a working SDL for Haskell or Ocaml on Windows without fighting with a dozen versions of compilers?
The Haskell Platform comes with a binding to OpenGL which should work out of the box on Windows.
Concerning the SDL package on hackage, you can use cabal unpack SDL to get the source code and fix things yourself. To install the package with your changes, run cabal install in the unpacked directory. In any case, drop a line to the maintainer, I'm sure he'll help out.
It's not related to SDL, but you've mentioned OpenGL. There is LablGL binding for OpenGL in OCaml which works out of the box. Wiki example (http://en.wikipedia.org/wiki/Objective_Caml#Triangle_.28graphics.29) compiles and works just fine.
The best instructions I've found for getting SDL to work in windows with a the most recent Haskell platform can be found at this blog. I followed everything step-by-step and it worked perfectly, despite some configure error messages.
It isn't SDL but GLFW works on Windows with Haskell through Cabal.
My article High-fidelity graphics with OpenGL 2 (25th Feb 2008) explained how the GLCaml bindings can be used to write OpenGL-based applications in OCaml that use vertex and fragment shaders (a phong shader is given as an example). There are 9 articles in the OCaml Journal on OpenGL, albeit mostly using the older LablGL library for OpenGL 1.1.
I tried and failed to get OpenGL working from Haskell under Linux in 2007. The Haskell Platform may have changed that but I have neither had time to try it yet myself nor ever heard of anyone using it for this.
However, both OCaml and Haskell must rely upon fragile low-level bindings to OpenGL because they are standalone languages and nobody has ever managed to get any significant commercial software using them to work. As you're on Windows, F#+XNA is a far more logical choice because XNA is tried and tested and F# has a safe high-level interface to it. A Google fight gives you a good idea of what a pioneer you'll be: +haskell +opengl gives 437 hits on Google and +ocaml +opengl gives only 347 hits.