Jason McKesson avatar Jason McKesson committed 83b655d

Start on Getting Started.

Comments (0)

Files changed (6)

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>There are two ways to go about it: you can use the framework provided in the download, or
+        you can use whatever tools you wish.</para>
+    <section>
+        <?dbhtml filename="Started Tutorial Framework.html" ?>
+        <title>Tutorial Framework</title>
+        <para>If you intend to use the tutorial framework, the process is relatively simple.</para>
+        <para>The framework is intended to only be used in the directory it was downloaded into. So
+            if you want to use it in a project, you will need to make a new directory under the base
+            tutorial directory. Let us call this directory <filename>Project</filename>.</para>
+        <para>In the <filename>Framework</filename> directory, there is the file
+                <filename>empty.cpp</filename>. This file contains all of the functions that the
+            framework expects you to define. Copy this file to your <filename>Project</filename>
+            directory and rename it however you want. For the purpose of this example, let us call
+            it <filename>project.cpp</filename>.</para>
+        <para>In order to build this file, you will need to use Premake; therefore, you will need to
+            use a Premake build script. You will need to create a <filename>premake4.lua</filename>
+            file in the <filename>Project</filename> directory. This is a text file that contains
+            the following:</para>
+        <example>
+            <title>Solution Premake Build Script</title>
+            <programlisting>dofile("../framework/framework.lua")
+
+SetupSolution("Project")
+dofile("tutorials.lua");</programlisting>
+        </example>
+        <para>You can replace the <quote><literal>Project</literal></quote> with whatever name you
+            wish. This will be the name of the solution file (for those build tools that have
+                <quote>solution</quote> files).</para>
+        <para>Next you must make a <filename>tutorials.lua</filename> file, in the
+                <filename>Project</filename> directory. It should contain the following:</para>
+        <example>
+            <title>Tutorial Premake Build Script</title>
+            <programlisting>SetupProject("Project", "project.cpp")</programlisting>
+        </example>
+        <para>You can again replace the <quote><literal>Project</literal></quote> with whatever name
+            you wish. This is the name of the executable, as well as the name of the project build
+            file (again, for build tools that have <quote>project</quote> files). Lua allows for
+            arbitrary numbers of arguments. Following the project name can be any number of files
+            that will be included with the project. Premake even allows wildcards, so
+                    <quote><filename>*.cpp</filename></quote> would include every C++ source file in
+            this directory. You can include non-buildable files like shaders as well, but you have
+            to specify the directory for that.</para>
+        <section>
+            <title>Using the Framework Library</title>
+            <para>At this point, you should be able to build and run the project. The framework
+                includes a number of extra facilities, like shader loading, mesh loading, and so
+                forth.</para>
+            <para>All of the framework library headers should be included <emphasis>after</emphasis>
+                including the GLLoad header.</para>
+            <para>Shaders and mesh files are assumed to come from a subdirectory of the current
+                directory called <filename>data</filename>. When you call
+                    <function>Framework::LoadShader</function>, it will look in the
+                    <filename>data</filename> directory for the file. If it is not there, then it
+                will look in the <filename>data</filename> directory just off the root of the
+                tutorial distribution; this is used for common shaders that are used across multiple
+                tutorials.</para>
+            <para>Here is a quick runthrough of the available tools in the framework library.</para>
+            <formalpara>
+                <title>framework.h</title>
+                <para>Contains functions to load shader files. It also has functions for converting
+                    degrees to radians.</para>
+            </formalpara>
+            <formalpara>
+                <title>Mesh.h</title>
+                <para>Contains the <classname>Framework::Mesh</classname> class. This class loads
+                    meshes in an XML format, and it can be used to render them. The XML format can
+                    define named variations of the mesh, which represent different sets of vertex
+                    attributes. The particular named set can be rendered with the
+                        <function>Mesh::Render</function> function. Note that it will only load
+                    meshes from the <filename>Project/data</filename> directory.</para>
+            </formalpara>
+            <formalpara>
+                <title>MousePole.h</title>
+                <para>Contains the <classname>Framework::MousePole</classname> class. This is used
+                    to allow mouse-based movements to control the camera. This control allows
+                    rotating the view around a point in the world: the look-at point. The
+                    constructor takes a <classname>Framework::RadiusDef</classname> object, which
+                    defines the limits for how the distance from the look-at can change, as well as
+                    the initial distance. They must be given the input from FreeGLUT's mouse and
+                    keyboard callbacks; the tutorials show how to set this up.</para>
+            </formalpara>
+            <formalpara>
+                <title>ObjectPole.h</title>
+                <para>Contains the <classname>Framework::ObjectPole</classname> class. This is used
+                    to allow mouse-based movements to control an object. This control allows
+                    rotating the object in space. Again, many tutorials show how to set this
+                    up.</para>
+            </formalpara>
+            <formalpara>
+                <title>Timer.h</title>
+                <para>Contains the <classname>Framework::Timer</classname> class. The timer is used
+                    to keep accurate time. The <function>Timer::Update</function> function must be
+                    used to advance the time since the last time it was used. You should only do
+                    this once per frame. There are three kinds of timers: looping timers, single
+                    timers, and infinite timers. Looping and single timers have a set duration, and
+                    they return the time as a value on the range [0, 1] from
+                        <function>Timer::GetAlpha()</function>, depending on how far towards the
+                    duration they are. The duration starts the first time the update function is
+                    called. Infinite timers should use <function>Timer::GetDuration()</function>,
+                    which returns the time in seconds since the first update call.</para>
+            </formalpara>
+            <formalpara>
+                <title>MatrixStack.h</title>
+                <para>Contains the <classname>Framework::MatrixStack</classname> class. The use of
+                    this class is well documented in Tutorial 7.</para>
+            </formalpara>
+            <para>All of the other parts of the framework library are probably too advanced,
+                special-case, or cumbersome to use.</para>
+        </section>
+    </section>
+    <section>
+        <?dbhtml filename="Started Nature of OpenGL.html" ?>
+        <title>The Nature of OpenGL</title>
+        <para/>
+    </section>
+    <section>
+        <?dbhtml filename="Started Necessary Tools.html" ?>
+        <title>Necessary Tools</title>
+        <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.</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 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 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. 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 useful in serious applications.</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 SDL (Simple Directmedia Layer) and SFML
+                (Simple and Fast Multimedia Library). 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, 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>Allegro 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>
+        </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>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>
+</appendix>

Documents/Positioning/Tutorial 07.xml

                 <title>Mismatched Attributes and Programs</title>
                 <para>You may be wondering what happens if there is a mis-match between the
                     attributes provided by a VAO and the vertex shader inputs. For example, we could
-                    use the position-only vertex shader, which takes attribute 0) with a mesh that
-                    provides attributes 0 and 1, with 0 being the position and 1 being the
-                    color.</para>
+                    use the position-only vertex shader with a mesh that provides attributes 0 and
+                    1, with 0 being the position and 1 being the color.</para>
                 <para>OpenGL is actually very lenient about this sort of thing. It also goes through
                     some effort to fully define what information the vertex shader gets in the event
                     of a mismatch.</para>
             buffer object. You can bind it to the <literal>GL_ARRAY_BUFFER</literal> and use it for
             vertex data, you can use it for indexed rendering with
                 <literal>GL_ELEMENT_ARRAY_BUFFER</literal>, and many other things that buffer
-            objects can be used for.</para>
+            objects can be used for. Now granted, that doesn't mean that you should, only that you
+            can.</para>
         <para>The example <phrase role="propername">World with UBO</phrase> uses a uniform buffer
             object to store the camera and perspective matrices.</para>
         <section>
                     <function>glGetUniformLocation</function> will return -1. It's actually legal to
                 set a value to a location that is -1, but no data will actually be set.</para>
             <para>If a uniform block is marked with the <quote>std140</quote> layout, then the
-                ability to disable uniforms in a block is entirely removed. All uniforms must have
-                storage, even if this particular program does not use them. This means that, as long
-                as you declare the same uniforms in the same order within a block, the storage for
-                that uniform block will have the same layout in <emphasis>any</emphasis> program.
-                This means that multiple different programs can use the same uniform buffer.</para>
+                ability to disable uniforms in within that block is entirely removed. All uniforms
+                must have storage, even if this particular program does not use them. This means
+                that, as long as you declare the same uniforms in the same order within a block, the
+                storage for that uniform block will have the same layout in <emphasis>any</emphasis>
+                program. This means that multiple different programs can use the same uniform
+                buffer.</para>
             <para>The other two alternatives to <quote>std140</quote> are <quote>packed</quote> and
                     <quote>shared</quote>. The default, <quote>shared,</quote> prevents the uniform
                 optimization, thus allowing the block's uniform buffer data to be shared among
                     something about your intended use of a buffer object based on what target you
                         <emphasis>first</emphasis> use to bind it. So by allocating storage for this
                     buffer in <literal>GL_UNIFORM_BUFFER</literal>, we are signaling something to
-                    OpenGL, which can change where it allocates storage for the buffer.</para>
+                    OpenGL, which can change how it allocates storage for the buffer.</para>
                 <para>However, OpenGL is <emphasis>not</emphasis> allowed to make any behavioral
                     changes based on this. It is still legal to use a buffer allocated on the
                         <literal>GL_UNIFORM_BUFFER</literal> target as a
                 context. The uniform buffer is bound to one of those slots. Therefore, when you
                 render with that program, the uniform buffer that is in the slot specified by the
                 program will be where the program gets its uniform data from.</para>
-            <para>Therefore, to use a uniform buffer, one first must tell the program which binding
-                point in the context to find the buffer. This association is made with the
+            <para>Therefore, to use a uniform buffer, one first must tell the program object which
+                binding point in the context to find the buffer. This association is made with the
                     <function>glUniformBlockBinding</function> function.</para>
             <programlisting language="cpp">glUniformBlockBinding(data.theProgram, data.globalUniformBlockIndex,
     g_iGlobalMatricesBindingIndex);</programlisting>
                     <function>glBindBufferRange</function>.</para>
             <programlisting language="cpp">glBindBufferRange(GL_UNIFORM_BUFFER, g_iGlobalMatricesBindingIndex,
     g_GlobalMatricesUBO, 0, sizeof(glm::mat4) * 2);</programlisting>
-            <para>This functions similarly to glBindBuffer; in addition to binding the buffer to the
-                    <literal>GL_UNIFORM_BUFFER</literal> target, it also binds the buffer to the
-                given uniform buffer binding point. Lastly, it provides an offset and range, the
-                last two parameters. This allows you to put uniform data in arbitrary places in a
-                buffer object. You could have the uniform data for <emphasis>several</emphasis>
-                uniform blocks in several programs all in one buffer object. The range parameters
-                would be how to say where that block's data begins and how big it is.</para>
+            <para>This functions similarly to <function>glBindBuffer</function>; in addition to
+                binding the buffer to the <literal>GL_UNIFORM_BUFFER</literal> target, it also binds
+                the buffer to the given uniform buffer binding point. Lastly, it provides an offset
+                and range, the last two parameters. This allows you to put uniform data in arbitrary
+                places in a buffer object. You could have the uniform data for
+                    <emphasis>several</emphasis> uniform blocks in several programs all in one
+                buffer object. The range parameters would be how to say where that block's data
+                begins and how big it is.</para>
             <para>The reason this is better than directly binding a buffer object to the program
                 object can be seen in exactly where all of this happens. Both of these functions are
                 called as part of initialization code. <function>glUniformBlockBinding</function> is

Documents/Tutorial Documents.xpr

     </meta>
     <projectTree name="Tutorial%20Documents.xpr">
         <folder name="Appendices">
+            <file name="Getting%20Started.xml"/>
             <file name="History%20of%20Graphics%20Hardware.xml"/>
             <file name="Optimization.xml"/>
         </folder>

Documents/Tutorials.xml

     </part>
     <!--<xi:include href="Optimization.xml"/>-->
     <xi:include href="History of Graphics Hardware.xml"/>
+    <xi:include href="Getting Started.xml"/>
 </book>
+/***********************************************************************
+This file contains all of the functions you need to implement, as well as
+when/why they are called. You can copy this file and simply implement
+these function.
+***********************************************************************/
 
-#include <string>
-#include <vector>
-#include <iostream>
-#include <sstream>
-#include <glloader/gl_3_2_comp.h>
+#include <glload/gl_3_3_comp.h>
 #include <GL/freeglut.h>
-#include "../framework/framework.h"
 
 
-GLuint CreateShader(GLenum eShaderType, const std::string &strShaderFile)
-{
-	GLuint shader = glCreateShader(eShaderType);
-	const char *strFileData = strShaderFile.c_str();
-	glShaderSource(shader, 1, &strFileData, NULL);
-
-	glCompileShader(shader);
-
-	GLint status;
-	glGetShaderiv(shader, GL_COMPILE_STATUS, &status);
-	if (status == GL_FALSE)
-	{
-		GLint infoLogLength;
-		glGetShaderiv(shader, GL_INFO_LOG_LENGTH, &infoLogLength);
-
-		GLchar *strInfoLog = new GLchar[infoLogLength + 1];
-		glGetShaderInfoLog(shader, infoLogLength, NULL, strInfoLog);
-
-		const char *strShaderType = NULL;
-		switch(eShaderType)
-		{
-		case GL_VERTEX_SHADER: strShaderType = "vertex"; break;
-		case GL_GEOMETRY_SHADER: strShaderType = "geometry"; break;
-		case GL_FRAGMENT_SHADER: strShaderType = "fragment"; break;
-		}
-
-		fprintf(stderr, "Compile failure in %s shader:\n%s\n", strShaderType, strInfoLog);
-		delete[] strInfoLog;
-	}
-
-	return shader;
-}
-
-GLuint CreateProgram(const std::vector<GLuint> &shaderList)
-{
-	GLuint program = glCreateProgram();
-
-	for(size_t iLoop = 0; iLoop < shaderList.size(); iLoop++)
-		glAttachShader(program, shaderList[iLoop]);
-
-	glLinkProgram(program);
-
-	GLint status;
-	glGetProgramiv (program, GL_LINK_STATUS, &status);
-	if (status == GL_FALSE)
-	{
-		GLint infoLogLength;
-		glGetProgramiv(program, GL_INFO_LOG_LENGTH, &infoLogLength);
-
-		GLchar *strInfoLog = new GLchar[infoLogLength + 1];
-		glGetProgramInfoLog(program, infoLogLength, NULL, strInfoLog);
-		fprintf(stderr, "Linker failure: %s\n", strInfoLog);
-		delete[] strInfoLog;
-	}
-
-	return program;
-}
-
-GLuint theProgram;
-
-const std::string strVertexShader(
-								  "#version 330\n"
-								  "layout(location = 0) in vec4 position;\n"
-								  "void main()\n"
-								  "{\n"
-								  "   gl_Position = position;\n"
-								  "}\n"
-								  );
-
-const std::string strFragmentShader(
-									"#version 330\n"
-									"out vec4 outputColor;\n"
-									"void main()\n"
-									"{\n"
-									"   outputColor = vec4(1.0f, 1.0f, 1.0f, 1.0f);\n"
-									"}\n"
-									);
-
-void InitializeProgram()
-{
-	std::vector<GLuint> shaderList;
-
-	shaderList.push_back(CreateShader(GL_VERTEX_SHADER, strVertexShader));
-	shaderList.push_back(CreateShader(GL_FRAGMENT_SHADER, strFragmentShader));
-
-	theProgram = CreateProgram(shaderList);
-}
-
-const float vertexPositions[] = {
-	0.75f, 0.75f, 0.0f, 1.0f,
-	0.75f, -0.75f, 0.0f, 1.0f,
-	-0.75f, -0.75f, 0.0f, 1.0f,
-};
-
-GLuint positionBufferObject;
-GLuint vao;
-
-
-void InitializeVertexBuffer()
-{
-	glGenBuffers(1, &positionBufferObject);
-
-	glBindBuffer(GL_ARRAY_BUFFER, positionBufferObject);
-	glBufferData(GL_ARRAY_BUFFER, sizeof(vertexPositions), vertexPositions, GL_STATIC_DRAW);
-	glBindBuffer(GL_ARRAY_BUFFER, 0);
-}
-
-const char *g_strTestFloats = " \n-10.0 10.0 23.4\n4.32 -4 -5 ";
-Framework::Mesh *g_theMesh = NULL;
-
 //Called after the window and OpenGL are initialized. Called exactly once, before the main loop.
 void init()
 {
-	try
-	{
-		g_theMesh = new Framework::Mesh("mesh.xml");
-	}
-	catch(std::exception &except)
-	{
-		g_theMesh = NULL;
-		printf(except.what());
-	}
 
-	InitializeProgram();
-	InitializeVertexBuffer();
-
-	glGenVertexArrays(1, &vao);
-	glBindVertexArray(vao);
 }
 
 //Called to update the display.
 //If you need continuous updates of the screen, call glutPostRedisplay() at the end of the function.
 void display()
 {
-	glClearColor(0.0f, 0.0f, 0.0f, 0.0f);
-	glClear(GL_COLOR_BUFFER_BIT);
-
-	glUseProgram(theProgram);
-
-	if(g_theMesh)
-		g_theMesh->Render();
-/*
-	glBindBuffer(GL_ARRAY_BUFFER, positionBufferObject);
-	glEnableVertexAttribArray(0);
-	glVertexAttribPointer(0, 4, GL_FLOAT, GL_FALSE, 0, 0);
-
-	glDrawArrays(GL_TRIANGLES, 0, 3);
-*/
-
-	glDisableVertexAttribArray(0);
-	glUseProgram(0);
 
 	glutSwapBuffers();
 }
 //This is an opportunity to call glViewport or glScissor to keep up with the change in size.
 void reshape (int w, int h)
 {
-	glViewport(0, 0, (GLsizei) w, (GLsizei) h);
+
 }
 
 //Called whenever a key on the keyboard was pressed.
 //exit the program.
 void keyboard(unsigned char key, int x, int y)
 {
-	switch (key)
-	{
-	case 27:
-		delete g_theMesh;
-		glutLeaveMainLoop();
-		break;
-	}
+
 }
 
-
+//Called before FreeGLUT is initialized. It should return the FreeGLUT
+//display mode flags that you want to use. The initial value are the standard ones
+//used by the framework. You can modify it or just return you own set.
+//This function can also set the width/height of the window. The initial
+//value of these variables is the default, but you can change it.
+unsigned int defaults(unsigned int displayMode, int &width, int &height) {return displayMode;}

framework/empty.cpp

 
 }
 
-
+//Called before FreeGLUT is initialized. It should return the FreeGLUT
+//display mode flags that you want to use. The initial value are the standard ones
+//used by the framework. You can modify it or just return you own set.
+//This function can also set the width/height of the window. The initial
+//value of these variables is the default, but you can change it.
+unsigned int defaults(unsigned int displayMode, int &width, int &height) {return displayMode;}
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.