I want to install some libraries, namely MonoGame, on my Windows10 computer. There appear to be a WindowsDX and WindowsGL (or DesktopGL). What is the basic difference between references to WindowsDX and GL. Thanks.
I assume WindowsGL refers to the Windows implementation of OpenGL. OpenGL is an open, industry standard library and interface for using/programming graphics hardware.
WindowsDX probably refers to Windows DirectX. DirectX is a suite of libraries for multimedia programming in general, including D3D for interfacing with graphics hardware, in particular.
The capabilities are comparable, but the interfaces differ.
Windows supports both, with OpenGL possibly being handled by translating commands into their DirectX equivalents at some level of the driver stack. I don't think any non-Windows platforms support DirectX.
Related
I'm currently working on building Chess in C++ for a school project. It's coming along really well, and I'm going to need to implement graphics pretty soon. Although I'm going to implement the graphics in X11, I was wondering how I might do it with WebAssembly, specifically which libraries are most similar to X11 that I could use. The GraphicsDisplay would just be an Observer to my Game class.
You cannot program in X11 with WebAssembly, you need graphics frameworks.
Currently the only GUI framework that officially support WebAssembly is Qt. Have a look at its official documentation on WebAssembly. I recommend learning Qt Widgets in a common desktop environment (Linux, Windows, Mac...) then try to port it in WebAssembly.
The other way to implement graphics with WebAssembly is using frameworks for game. Emscripten (C/C++ to WebAssembly toolchain) has a strong support for OpenGL-based games. You probably want to look at SDL.
Basically I have a windows system that does not have a graphics card, and I am trying to execute a .jar file in cmd, which gives the following output:
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\shattered>java -jar test.jar
Exception in thread "LWJGL Application" com.badlogic.gdx.utils.GdxRuntimeException: OpenGL is not supported by the video driver.
I am only somewhat tech literate but the takeaway I got from that was that I needed to get OpenGl. So I did some research and found a few mentions of OpenGl software mode or something but I have no idea of how to go about doing so. Any help would be greatly appreciated, cheers!
And before it is mentioned, I have tried updating the video driver.
First on the "what":
OpenGL is a application programming interface (API) between the graphics facilities of the operating system (which in broad term covers everything between putting windows to the screen down to placing single pixels) and individual programs. The main purpose of OpenGL is providing access to accelerated graphics infrastructure optimized for rasterizing graphics primitives most suitable for 3D image generation.
Now to the "how":
The typical OpenGL implementation ships as part of the drivers of 3D graphics accelerator processors (GPUs). However since (a very old) version of OpenGL, namely OpenGL-1.1, has been specified as part of the Win32 API every version of Windows since Windows 95B and Windows NT-4 includes a fallback software implementation that can be used in case no accelerated OpenGL version is available. However if any version beyond OpenGL-1.1 is required this fallback does not provide it.
However you can substitute the standard OpenGL interface with an advanced software rasterizer implementation: The Mesa project provides a version of their software rasterizer that provides even modern core profile OpenGL. The usual recommendation is to place these substitute opengl32.dll besides the .exe file of the program that requires it; in fact on modern Windows systems with system file protection it's actually impossible to replace the original DLLs without jumping a few hoops. The MSys2 project offers prebuilt versions of substitute DLLs.
Current (as of writing this):
64 Bit version: https://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64/mingw-w64-x86_64-mesa-17.0.0-1-any.pkg.tar.xz/download
32 Bit version: https://sourceforge.net/projects/msys2/files/REPOS/MINGW/i686/mingw-w64-i686-mesa-17.0.0-1-any.pkg.tar.xz/download
XZ archives can be unpacked with 7-zip.
Default VGA/VESA driver is also used for gfx card without propper driver. Such cards usually emulate EGA/VGA/VESA until initialized so windows default driver works for them.
So during boot freeze the screen and look at the PID/VID table of installed devices. from that numbers you can detect which gfx card you really have and look for drivers.
In rare case you really got just EGA/VGA/VESA (which I doubt) in the old MS-DOS times there were OpenGL software drivers even for those. What you need is find OpebGL DLL for your platform like (opengl32.dll) and place it either directly to your executable or into known path like system32 ... In such case you should get at least OpenGL 1.0 support in SW rendering mode
btw if my memory serves well in the old times of win3.11 and win9x this OpenGL32.dll was a part of windows instalation and we got the OpenGL screen savers running on VESA cards natively.
I recently moved the rendering part of a program of mine from GDI+ to OpenGL.
Now I'm wondering: are there any downsides to doing so?
For example, are there any versions of Windows (XP or later) that support GDI+ but not OpenGL?
Or, for example, is it possible for a lack of drivers (or poor drivers), or a lack of a graphics card, etc. to make OpenGL rendering impossible on a system on which GDI+ works fine?
(I understand the OpenGL might need to resort to software rendering on less capable systems, but aside from slowness, I'm wondering if it would ever simply not work correctly in a situation in which GDI+ would.)
It depends on the OpenGL version/profile you're using. Up to, inclusing Windows XP OpenGL-1.1 is available by default without additional drivers. Since Windows Vista the minimum available OpenGL version is OpenGL-1.4.
However if you need anything more than that, you're relying on the user installing the drivers that come from the GPU vendor; the drivers installed by default in a standard Windows installation don't cover OpenGL (for not perfectly sane reasons).
Programs and libraries that strongly depend on OpenGL-ES have resorted to incorporate fallbacks like ANGLE.
There are some idiosyncrasies, as for example: you cannot create a transparent OpenGL window, if transparency is disabled (which means, not at all, under XP). Otherwise, as datenwolf notes, there's ANGLE, but even that does not always work. Another option might be mesa3d compiled for the windows target, with software rendering enabled. This option might be the safest one and faster than the software OpenGL 1.1 implementation from Microsoft.
What is the Direct3D? It is an API, is not it? Is it implemented by Windows or by graphics cards?
If the graphics cards implement the Direct3D API, why can not other operating systems use Direct3D resources from the graphics card?
If Direct3D is implemented by Windows, it has to use graphics card resources, such as OpenGL or OpenCL. If Direct3D calls are not directly to the graphics card, it would be slower due to intermediate calls.
Please, help me to understand what the Direct3D is.
What is the Direct3D? It is an API, is
not it? Is it implemented by Windows
or by graphics cards?
Yes, Direct3D is an API. It is implemented (mostly) by Windows itself. However, Windows will offload a considerable part of the actual work to the drivers of the graphics card and ultimately to the gfx card itself, so one can also say that a gfx card "implements" D3D.
If the graphics cards implement the
Direct3D API, why can not other
operating systems use Direct3D
resources from the graphics card?
They can, and they do, but only a relatively small (but often critical part) of D3D functionality is implemented directly by the card's hardware, so a lot more work in software is required to implement D3D.
If Direct3D is implemented by Windows,
it has to use graphics card resources,
such as OpenGL or OpenCL.
No, that's a misunderstanding. OpenGL and OpenCL are also APIs, and only partially implemented by the gfx hardware (just like D3D). The gfx hardware usually has a (proprietary) "native" API, which is what the gfx drivers (both for D3D and OpenGL) use.
If Direct3D calls are not directly to
the graphics card, it would be slower
due to intermediate calls.
There are not necessarily any "intermediate calls" - the D3D driver uses the cards native API, as explained above.
Direct 3D is a graphics API created by Microsoft. Its similar in function to opengl. OpenGL is a competing 3D graphics API created as a open standard. D3D doesn't need OpenGL to function.
Card manufactorers decide which APIs they want to implement; most always include DirectX (which includes Direct3D) and possibly OpenGL.
There is indirection as it doesn't go directly to the card, the cards D3D in turn calls the drivers, but this typicially is insignificant.
Direct3D is an API developed by Microsoft designed to help developers render 3D graphics. OpenGL and Direct3D are two separate APIs, but they must both interface to the video card using the drivers developed by the companies who manufacture the video cards. Both APIs (Direct3D and OpenGL) must both go through the driver in order to access the video card, and their speeds are dependent upon their design and their implementation in the video card drivers.
OpenCL is something different -- it's designed to help developers write programs which perform general-purpose computing on the GPU (not just for graphics). OpenCL is comparable to CUDA, but the latter in only supported on NVIDIA cards. Using CUDA instead of OpenCL may have some advantages, depending on your target system, since NVIDIA can make new features available to the CUDA API before they are accepted into the OpenCL API. However, even OpenCL and CUDA must interface to the driver in order to get anything done on the GPU.
As you already know, Direct3D only works on Microsoft and on Wine (for the most part), but its structure as an API is vastly different from that of OpenGL. Direct3D makes use of structures and includes more OOP elements in its API, while OpenGL acts as a state machine, lacking any structures or OOP features. Direct3D can often progress a little faster than OpenGL in terms of the features which it claims to officially support in its API because it is not designed for maximum compatibility with a wide range of devices; on the other hand, OpenGL has typically exhibited more inertia when it has come to adopting new features because of the inherent difficulty in adding new features to its API (the Khronos Group is influenced heavily by the CAD industry as well as many others, so it must cater to a wide range of needs). The time it took for the Khronos Group to finally adopt asynchronous API calls in the OpenGL is testament to this fact, and caused many people to lose faith in OpenGL.
However, OpenGL is cross-platform, endorsed by Apple, and it works on all operating systems on which it is implemented. You can easily use it with many popular window toolkits (Qt, SDL, FreeGLUT, JogAmp, gtk, etc.) and have confidence that your application will compile on other operating systems if you wrote it properly. The OpenGL API, unlike Direct3D, is an open-source industry standard.
As far as performance goes, it's still debatable as to which one is faster: depending on how you structure your program or batch your calls, this could change. However, performance should not really be a consideration for which API you use unless you have tested your application and have evidence that the choice of API is the cause of your bottleneck.
From Wikipedia:
Direct3D is a Microsoft DirectX API
subsystem component. The aim of
Direct3D is to abstract the
communication between a graphics
application and the graphics hardware
drivers. It is presented like a thin
abstract layer at a level comparable
to GDI (see attached diagram).
Direct3D contains numerous features
that GDI lacks.
Direct3D is an Immediate mode graphics
API. It provides a low-level interface
to every video card 3D function
(transformations, clipping, lighting,
materials, textures, depth buffering
and so on). It also had a higher level
Retained mode component, that has now
been officially discontinued.
Lazarus Ide can use several gui libraries. I am on Windows. I wonder what are difference among them...
It is clear that lcl is most stable.
Why would anyone use Qt and fpgui once they will be of good quality?
LCL is the abstraction. IOW the core part of the LCL works on all platforms. It's a bit Windows centric since it derives base principles (and compatibility) from Delphi's Windows centric VCL.
Under Windows, the LCL typically uses the win32/64 GDI API layer as backend, but it can also use others, most notably QT and GTK2 (though these are more in testing stages)
If you have majorly invested in making a complex GUI app under Linux, and have used QT specific functionality, the LCL-with-QT backend would e.g. allow you to more easily port this code over.
IOW using anything but win32/64 (GDI) on Windows is only in interesting specific purposes, with codebases that go beyond the LCL from non Windows origin.
FPGUI is a one man mission to create an own (owner drawn) widgetset. The LCL port was planned, but never delivered. Typically these kind of GUIs are used in embedded POS environment where the application essentially runs fullscreen.
It probably also works on Windows since it's ownerdrawn and probably requires only a few basic primitives to get it working, and porting it to windows eases development.