gltut / Documents / Getting Started.xml

<?xml version="1.0" encoding="UTF-8"?>
<?oxygen RNGSchema="http://docbook.org/xml/5.0/rng/docbookxi.rng" type="xml"?>
<?oxygen SCHSchema="http://docbook.org/xml/5.0/rng/docbookxi.rng"?>
<appendix xmlns="http://docbook.org/ns/docbook" xmlns:xi="http://www.w3.org/2001/XInclude"
    xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0">
    <?dbhtml filename="Getting Started with OpenGL.html" ?>
    <title>Getting Started with OpenGL</title>
    <para>Now that you understand at least the beginnings of graphics programming, it would be
        useful to discuss how to get started using OpenGL in your own projects. This discussion will
        assume that you know how to set up a build project in your build system of choice.</para>
    <para>The easiest way is to just use the <link
            xlink:href="http://glsdk.sourceforge.net/docs/html/index.html">Unofficial OpenGL
            SDK</link>. It is a well-documented collection of tools for writing simple OpenGL
        applications. It has functions for compiling shaders, the mouse-based controls we have used,
        image loading tools, and various other utilities that are vital to making OpenGL
        applications. Details for how to use it are found on the SDK's website.</para>
    <section>
        <?dbhtml filename="Started Necessary Tools.html" ?>
        <title>Manual Usage</title>
        <para>If you choose not to use the SDK, then you will have to build a set of useful tools
            yourself.</para>
        <para>In order to use OpenGL, you will need to do two things. You must create a window and
            attach an OpenGL context to it, and you must load the OpenGL functions for that context.
            There are a number of other tools you may want (vector math, model loading, image
            loading, etc), but these tools are ones you need if you aren't going to do them
            manually.</para>
        <section>
            <title>Window and OpenGL Creation</title>
            <para>Windows, displayable surfaces in GUI operating environments, are very
                platform-specific. Most Linux distributions rely on X11 for the lowest-level of
                window creation, and X11 has hooks, called GLX functions, for attaching OpenGL to
                those windows. The Win32 API is used on Windows to create windows. OpenGL can be
                attached to these windows using the WGL API.</para>
            <para>Because window creation and OpenGL attachment are platform-specific, there are a
                number of cross-platform tools that make it possible to write platform-neutral
                OpenGL code. FreeGLUT is the tool that these tutorials use, and it is included as
                part of the SDK in the source distribution. There are a number of other tools
                available. We will discuss many of the options here.</para>
            <formalpara>
                <title>FreeGLUT</title>
                <para>FreeGLUT is based on the original GLUT, the OpenGL Utility Toolkit. You should
                    never use GLUT; it is old and has not been updated in a decade. But FreeGLUT is
                    100% backwards compatible with it; any application that used GLUT can use
                    FreeGLUT with no source code changes.</para>
            </formalpara>
            <para>FreeGLUT creates and manages the window for the application. It provides callbacks
                so that the user can respond to various events. In these tutorials, the framework
                has initialized FreeGLUT and registered several standard callbacks, which each
                tutorial implements. There is a callback for when the display needs updating, when
                the user has resized the window, when the user has pressed a key, and when mouse
                input happens.</para>
            <para>FreeGLUT can create windows or full-screen displays. It also has some limited
                support for menus. This does not allow you to create a menu bar, but it does allow
                you to create a right-click context menu.</para>
            <para>FreeGLUT is a good tool for rapidly prototyping an effect. However, building a
                real application in it is problematic, particularly if you have specific timing
                needs. FreeGLUT owns the message processing loop; this limits your options for
                dealing with strict timing and so forth. FreeGLUT is good for demo programs and
                prototyping, but serious applications should avoid it.</para>
            <para>FreeGLUT does have some text rendering functions, but these do not work when using
                shader-based rendering. If you are using a core OpenGL context, these functions will
                fail. They will also fail in compatibility contexts if you have a program object
                bound to the context.</para>
            <para>FreeGLUT uses the X-Consortium license.</para>
            <formalpara>
                <title>GLFW</title>
                <para>GLFW is an alternative to FreeGLUT. Like FreeGLUT, GLFW is fairly bare-bones.
                    It provides a way to create windows or full-screen displays. It provides ways to
                    get keyboard and mouse input.</para>
            </formalpara>
            <para>The biggest difference between them is that, while FreeGLUT owns the message
                processing loop, GLFW does not. GLFW requires that the user poll it to process
                messages. This allows the user to maintain reasonably strict timings for rendering.
                While this makes GLFW programs a bit more complicated than FreeGLUT ones (which is
                why these tutorials use FreeGLUT), it does mean that GLFW would be more useful in
                serious applications.</para>
            <para>GLFW also provides more robust input support as well as </para>
            <para>GLFW uses the zLib license.</para>
            <formalpara>
                <title>Multimedia Libraries</title>
                <para>A multimedia library is a library that handles, in a cross-platform way,
                    graphics, sound, input, and other things. The impetus for all of these was
                    DirectX, a Microsoft library that handles graphics, sound, input and a few other
                    things for the purpose of improving the life of game developers. The purpose of
                    DirectX was to be hardware-independent; code could be written against all
                    graphics or sound hardware, and DirectX would sort out the details.</para>
            </formalpara>
            <para>Cross-platform multimedia libraries do this as well, but they take things
                cross-platform. They generally support the big 3 operating systems (Windows, Linux,
                MacOSX), possibly also supporting BSD or various other shades of UNIX. Unlike
                DirectX, the multimedia libraries did not create their own 3D rendering system; they
                instead simply provide a way to use OpenGL.</para>
            <para>The two biggest multimedia libraries are <link xlink:href="http://www.libsdl.org/"
                    >SDL (Simple Directmedia Layer)</link> and <link
                    xlink:href="http://www.sfml-dev.org/">SFML (Simple and Fast Multimedia
                    Library)</link>. SDL is the older, but it is still receiving updates. It is a C
                library, so if you are allergic to C-isms, you may wish to avoid it. Work is being
                done on SDL 1.3, which will apparently have support for mobile platforms. SDL uses
                the zLib license.</para>
            <para>SFML is a newer library, which has a C++ API. While SDL is one big library (and
                requires dependencies like DirectX on Windows), SFML is more of a choose-your-own
                package. The base package contains just input and the ability to create a window,
                while there are other packages that build upon this. Also SFML makes it possible to
                integrate SFML windows with other GUI toolkits (see below); this makes it easier to
                build non-gaming applications that use actual GUI tools. SFML uses the zLib
                license.</para>
            <para><link xlink:href="http://alleg.sourceforge.net/">Allegro</link> is a game-centric
                multimedia library. Version 5 has native support for OpenGL in its graphics
                subsystem. It uses a C interface. It also has a number of advanced 2D rendering
                functions. Allegro uses the <quote>giftware license,</quote> which is rather like
                the MIT license.</para>
            <formalpara>
                <title>GUI Toolkits</title>
                <para>There are a number of cross-platform GUI libraries that deal with detailed
                    window management, provide controls, and generally act like a full-fledged
                    windowing system. Most of them have support for using OpenGL in one or more of
                    their windows.</para>
            </formalpara>
            <para>Which window creation tools you use are entirely up to you; the possible needs
                that you might have are well beyond the scope of this book.</para>
        </section>
        <section>
            <title>Function Loading</title>
            <para>Once an OpenGL context has been created, one must then load OpenGL's functions. In
                a normal library, this would not actually be a step; those functions would have a
                header that you include and a library of some sort that you link to, either
                statically or dynamically. Due to various complexities around OpenGL, it cannot work
                that way on most platforms.</para>
            <para>Therefore, the user must query the context itself for the functions to load. And
                OpenGL has many functions. So the common way to handle this is to use a library to
                do it for you.</para>
            <formalpara>
                <title>GL Load</title>
                <para>This comes with the Unofficial OpenGL SDK. And while most of the SDK is not
                    intended for high-performance use, GL Load is still perfectly serviceable in
                    that capacity. After all, this is generally a one-time initialization step, so
                    performance is ultimately irrelevant.</para>
            </formalpara>
            <para>GL Load works with core and compatibility contexts equally well. GL Load uses the
                MIT License.</para>
            <formalpara>
                <title>GLEW</title>
                <para>GLEW (the OpenGL Extension Wrangler) is perhaps the most widely used
                    alternative. While it is technically intended for loading extension functions,
                    it works just as well on the OpenGL core functions.</para>
            </formalpara>
            <para>The principle downside of GLEW is that it does not work well with
                non-compatibility contexts. There is some experimental support to make this work,
                but it is experimental. GLEW uses the MIT license.</para>
            <formalpara>
                <title>GL3W</title>
                <para>GL3W is unique in that it is not technically a library. It is a Python script
                    that downloads and parses a header file, which it uses to create a library. This
                    allows it to be as up-to-date as the source file that it downloads. The downside
                    is that the format of this source file may change, and if it does, it would
                    break this tool.</para>
            </formalpara>
            <para>GL3W is intended specifically for core contexts, and it does not work with
                compatibility or older OpenGL versions. Being a Python script, it requires a Python
                2.6 environment; it is unknown if it works with later Python versions. GL3W is
                public domain software.</para>
        </section>
        <section>
            <title>Initialization</title>
            <para>Once you have selected your tools of choice, the next step is to make them work.
                After downloading and compiling them, you will need to register them with your C/C++
                build tool of choice. On Linux-platforms, you typically have some global registry
                for these things, but on Windows, things go where you put them.</para>
            <para>How to use them depends on which tools you use. But the general idea for OpenGL
                context creation tools is that there will be some series of commands to supply
                parameters to the underlying system for context creation. And then a function is
                called to use those parameters to create the context. It is only
                    <emphasis>after</emphasis> this process has successfully completed that one
                should call whatever initialization function the OpenGL function loading system
                uses. Your tools' documentation should explain this.</para>
            <para>After doing both of these, you should be able to make OpenGL calls. The specifics
                on how to swap framebuffers (which is not part of the OpenGL API) is again left up
                to the window management tool.</para>
        </section>
    </section>
</appendix>
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.