You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

243 lines
9.5 KiB

/*
This file is part of Magnum.
Copyright © 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018
Vladimír Vondruš <mosra@centrum.cz>
Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the "Software"),
to deal in the Software without restriction, including without limitation
the rights to use, copy, modify, merge, publish, distribute, sublicense,
and/or sell copies of the Software, and to permit persons to whom the
Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included
in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.
*/
namespace Magnum {
/** @page portability Writing portable applications
@brief How to support different platforms and different OpenGL capabilities within one codebase.
@tableofcontents
@m_footernavigation
@section portability-target Target-specific code
If Magnum is compiled with e.g. OpenGL ES 2.0 support, some features present
in desktop version are not available. It means that some classes, functions
and enum values are simply not included in headers. It is designed this way to
make porting easier --- it is better to fail at compile time on e.g. undefined
enum value than fail at runtime in some corner case because given texture
format is not supported.
If you include @ref Magnum.h, you get these predefined macros:
12 years ago
- @ref MAGNUM_TARGET_GLES if targeting OpenGL ES
- @ref MAGNUM_TARGET_GLES2 if targeting OpenGL ES 2.0
- @ref MAGNUM_TARGET_GLES3 if targeting OpenGL ES 3.0
- @ref MAGNUM_TARGET_WEBGL if targeting WebGL
Example usage:
@code{.cpp}
#ifndef MAGNUM_TARGET_GLES
Renderer::setPolygonMode(Renderer::PolygonMode::Lines);
// draw mesh as wireframe...
#else
// use different mesh, as polygon mode is not supported in OpenGL ES...
#endif
@endcode
Each feature is marked accordingly if it is not available in some targets. See
also @ref requires-gl, @ref requires-gles20 and @ref requires-gles30.
12 years ago
@section portability-compiler Compiler- and platform-specific code
Magnum is attempting to be future-proof and as intuitive for users as
possible. Many features from C++11 are used to simplify things and make them
faster and more secure, but on the other hand it requires a compiler with good
enough support of the standard. Currently Magnum is written with at least GCC
4.8, Clang 3.1 and MSVC 2015 in mind. See @ref Corrade.h for more information.
Each feature is marked accordingly if it is not available on some compilers,
see @ref SceneGraph::DrawableGroup3D for an example. It is up to you (or your
platform) which compiler your code will support, code written for e.g. GCC 4.8
will work also on Magnum compiled with support for newer compilers, although
newer compilers may catch errors that weren't spotted by earlier versions.
12 years ago
Some functionality (such as dynamic plugin loading or filesystem access) might
not be available on particular platforms. @ref Corrade.h contains defintions
which you can use for platform-aware code.
@section portability-extensions Extension-aware code
Some functionality is depending on support of a particular OpenGL extension and
thus the decision cannot be made at compile time. Header @ref Extensions.h
contains list of extensions, which you can pass to
@ref Context::isExtensionSupported() and decide based on that:
@code{.cpp}
if(Context::current().isExtensionSupported<GL::ARB::geometry_shader4>()) {
// draw mesh with wireframe on top in one pass using geometry shader...
} else {
// draw underlying mesh...
Renderer::setPolygonMode(Renderer::PolygonMode::Lines);
// draw mesh as wirefreame in second pass...
}
@endcode
You can also decide on particular OpenGL version using @ref Context::isVersionSupported(),
but remember that some features from that version might be available even if
the drivers don't fully expose that version.
On the other hand, if you don't want to write fallback code for unsupported
extensions, you can use macros @ref MAGNUM_ASSERT_EXTENSION_SUPPORTED() or
@ref MAGNUM_ASSERT_VERSION_SUPPORTED() to add mandatory requirement of given
extension or version:
@code{.cpp}
MAGNUM_ASSERT_EXTENSION_SUPPORTED(GL::ARB::geometry_shader4);
// just use geometry shader and don't care about old hardware
@endcode
Each class, function or enum value is marked accordingly if it needs specific
extension or specific OpenGL version. Various classes in Magnum are taking
advantage of some extensions and enable faster code paths if given extension is
available, but also have proper fallback when it's not, see for example
@ref AbstractShaderProgram-performance-optimization "AbstractShaderProgram",
@ref AbstractTexture-performance-optimization "AbstractTexture" or
@ref Mesh-performance-optimization "Mesh". See also @ref opengl-required-extensions.
@section portability-shaders Writing portable shaders
Shaders are probably the most painful thing to port. There are many issues to
address --- different shader syntax (@glsl in @ce / @glsl out @ce vs.
@glsl attribute @ce and @glsl varying @ce etc.), explicit vs. implicit methods
to specify vertex attribute, uniform and texture uniform locations, required
precision qualifiers in OpenGL ES etc.
Shader class allows you to explicitly specify shader version and based on that
you can decide on the syntax in your shader code. You can also use
@ref Context::supportedVersion() to conveniently select the first supported
version from a list:
@code{.cpp}
// MyShader.cpp
Version version = Context::current().supportedVersion({Version::GL430,
Version::GL330,
Version::GL210});
attachShader(Shader::fromFile(version, "MyShader.vert"));
@endcode
@code{.vert}
// MyShader.vert
#if __VERSION__ < 130
#define in attribute
#define out varying
#endif
in vec4 position;
in vec3 normal;
out vec4 transformedNormal;
void main() {
// ...
}
@endcode
It is often desirable to query extension presence based on actually used GLSL
version --- while the extension might be supported in the driver, it might not
be available in given GLSL version (e.g. causing compilation errors). You can
12 years ago
use @ref Context::isExtensionSupported(Version) const to check that the
extension is present in given version:
@code{.cpp}
if(!Context::current().isExtensionSupported<Extensions::GL::ARB::explicit_attrib_location>(version)) {
bindAttributeLocation(Position::Location, "position");
// ...
}
@endcode
See also @ref AbstractShaderProgram class documentation for information about
specifying attribute location, uniform location and texture binding unit in
various OpenGL versions.
All shaders in @ref Shaders namespace support desktop OpenGL starting from
version 2.1 and also OpenGL ES 2.0 and 3.0 (or WebGL 1.0 / 2.0). Feel free to
look into their sources to see how portability is handled there.
@section portability-applications Platform-specific application support
Your application might run on Windows box, on some embedded Linux or even in
browser --- each platform has different requirements how to create an entry
point to the application, how to handle input events, how to create window and
OpenGL context etc. Namespace @ref Platform contains application base classes
which are abstracting out most of it for your convenience.
All the classes support limited form of static polymorphism, which means you
can just switch to another base class and in many cases you won't need to
change any other code. It has its limitations, though --- some toolkits don't
support all special keys, mouse movement events etc.
As mentioned in @ref platform, all the classes, macros and CMake variables have
generic aliases, thus using different toolkit is in most cases only matter of
replacing two lines of code.
Example application, which targets both embedded Linux (using plain X and EGL)
and desktop (using SDL2 toolkit). Thanks to static polymorphism most of the
functions will work on both without changes, the main difference might (or
might not, depending what you use) be in particular event handlers:
@code{.cpp}
#ifndef MAGNUM_TARGET_GLES
#include <Platform/Sdl2Application.h>
#else
#include <Platform/XEglApplication.h>
#endif
class MyApplication: public Platform::Application {
public:
MyApplication(const Arguments& arguments);
protected:
void viewportEvent(const Vector2i& size) override;
void drawEvent() override;
void keyPressEvent(KeyEvent& event) override;
};
// ...
MAGNUM_APPLICATION_MAIN(MyApplication)
@endcode
And corresponding CMake code. Note that we need to call @cmake find_package() @ce
twice, first to get the @ref MAGNUM_TARGET_GLES variable and then again to find
proper application library based on its value:
@code{.cmake}
find_package(Magnum REQUIRED)
if(MAGNUM_TARGET_GLES)
find_package(Magnum REQUIRED Sdl2Application)
else()
find_package(Magnum REQUIRED XEglApplication)
endif()
add_executable(myapplication MyApplication.cpp)
target_link_libraries(myapplication
Magnum::Magnum
Magnum::Application)
@endcode
*/
}