Lab 8 practical: A simple particle system. Download from: http://jon.drtomato.org/assignments/052312L-lab8-particles.zip

A shader to demonstrate some basic physics on the GPU.

File at http://jon.drtomato.org/assignments/052312L-Lab7-BounceFurther.rfx

View the proposal for Assignment 2 over at http://fang.jeremywong.name/exercise/week-6-assignment-2-proposal

Download Lab 6 - Ogre Shaders from http://jon.drtomato.org/assignments/052312L-Lab6-PHSOgre.zip

Submission for Assignment 1 - Rendering engine. Download from http://jon.drtomato.org/assignments/052312L-PHS-Assignment-1-grafikengine.zip

Today’s lesson covered the basics of setting up GLSL to work with an OpenGL program, some basic syntax of GLSL, and a few shader samples. The shader samples were on toon shading and brick shading, as found in the OpenGL Shading Language guide.

Lab assignment: http://jon.drtomato.org/assignments/052312L_toon_n_brick_shading.zip

C++ for Game Programmers by Noel Llopis

Published 2003

Charles River Media

Looks can be deceiving. At first glance, C++ for Game Programmers seems to be yet another of those beginner’s introductions to C++, with a game project thrown in to entice the beginner. Delve deeper, however, and you will find that the phrase “Do not judge a book by its cover” is indubitably true.

While hardly an introduction to C++, the book is also not about creating games, nor is it about the latest advanced techniques in real-time graphics programming. Instead, C++ for Game Programmers is about using C++ effectively to write game code. This is not a book to introduce programmers to game programming, but a book to introduce game programmers to better programming practices.

The book is divided into three parts: Tapping the Power of C++, Performance and Memory, and Special Techniques. In the first part, the author covers the major features that differentiate C++ from C, such as classes, inheritance, constness, templates and exception handling. The author takes a look at how these features are used, how they are implemented internally, and what their tradeoffs are. To quote the author, “Knowing when not to use a specific feature is just as important as knowing the mechanics of how to use it.”

For instance, the book does a cost analysis of using virtual functions. Beginner game programmers are too often obsessed with the speed of their code that they tend to over-react when talking about virtual functions. Here, the author analyses the implementation of virtual functions and suggests best practices for using them.

The second part of the book deals with performance issues and memory management. Topics covered include inlining, data caches, and memory alignment. The book also includes a detailed examination of a custom memory manager, teaching readers how to create their own. Apart from that, there are two chapters devoted to the Standard Template Library (STL), where the author goes through the common uses of the containers and algorithms within. He also spends some time on the age-old debate on whether to use the STL, providing the pros and cons of the STL.

Finally, the book covers some special techniques used in game programming, such as abstract interfaces, plug-ins, run-time type information, and object serialisation. These chapters provide an in-depth look at some important skills needed to implement the necessary features of games and their tools. For example, the chapter on plug-ins shows how to architecture programs to use plug-ins, as well as how to create plug-ins. This is extremely useful in the context of game tools, and can be extended to work with games as well.

Overall, C++ for Game Programmers is a must-read for any game developer, as it gives the reader a firm understanding of some very important concepts in the field of game creation. The book has provided me with new insight and enabled me to further enhance my skills in programming. Although the book may be lacking in length and newer topics, it nevertheless makes up for it with its quality and insightful discussion. Read it once, and you will find yourself referring to it often.

Having already come up with the bird’s eye view of the design for the rendering engine, I thus began coding based on the UML diagrams. For this assignment, I decided to go with a test-driven approach. According to Wikipedia, “Test-Driven Development (TDD) is a software development technique consisting of short iterations where new test cases covering the desired improvement or new functionality are written first, then the production code necessary to pass the tests is implemented, and finally the software is refactored to accommodate the changes.” The idea is to allow rapid feedback after a change is made.

In my case, I first created a test case: a program to initialise the rendering engine and then quit when the user presses the ‘Esc’ key. This test case will ensure that throughout the entire development process, the initialisation and behaviour of the rendering engine remains unchanged.

Of course, the test case did not compile at first. The next step was to write the startup code for the rendering engine. The aim is to allow the test case to compile and run without any errors. Once this is done, one can proceed to writing the next test case.

So far, I have written three test cases for the rendering engine. One to initialise the rendering engine on its own, another to test some code that will make initialisation easier, and one test to load a simple mesh and draw it. So far, the rendering engine has passed the first two tests, and I am now working on passing the third test case. Once done, I will then proceed to add on the test to load a texture and render the mesh with a texture.

Our first assignment for the module on hardware shaders is to create our own rendering engine. The typical naïve approach would be to start out coding immediately. However, such rash actions tend to produce haphazard results and a lot of wasted effort. For a project such as an engine or framework, the results could be an inflexible design that is horrible to work with.

Hence, the need for planning. Most software projects start out with documents detailing the requirements of the client, the code structure of the software, and so on. In many occasions, the above documents are written in the Unified Modeling Language (UML). So, as part of my preliminary design for the rendering engine, I drew out some UML diagrams.

Firstly, I came up with some use cases for the rendering engine, as shown below:

Next, I drew up a list of classes that I felt I would need and their relationships based on the use case diagram. Here is the class diagram for the rendering engine:

The next step was to think about the interaction between the client application and the rendering engine. I came up with a simple sequence diagram to show the rendering process:

And that sets the groundwork for my rendering engine. And the name of the engine? GrafikEngine.

References:

1.  Unified Modeling Language (UML) Tutorial - http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/
2. UML Demystified, Paul Kimmel

All UML diagrams were drawn using UMLet 7.1, the ’Free UML Tool for Fast UML Diagrams’, available at http://www.umlet.com/

In the second lesson on hardware shaders, we went through the basics of the 3D rendering pipeline to lay the groundwork for future lessons on shaders. Basically, geometrical data in the context of three-dimensional space is passed to the graphics hardware. The graphics hardware then has to transform the data into geometry that can be drawn into a two-dimensional viewport.

There are many coordinate systems that the geometry data can be stored in. Firstly, there is object space, where the coordinate system is local to a particular mesh. Then there is world space, which is the global coordinate system that relates all meshes in the scene. Before the object is rendered, it has to be transformed to camera space (or eye space), the space in which the x and y axes are aligned to the display and the z-axis is parallel to the viewing direction.

After transforming all data to camera space, the graphics hardware applies a projection transformation on the geometry, putting them in homogeneous clip space. This clip space is where graphics primitives are clipped to the boundaries of the viewport. The vertices in this space are described with four-dimensional homogeneous coordinates.

Finally the geometry data undergo a viewport transformation that places them in window space. This transformation maps the homogeneous coordinates to the actual range of pixel coordinates covered by the viewport.

During this process, per-vertex data supplied to the graphics hardware is interpolated across the area of the primitive. This includes surface normals, colours and texture coordinates.

Once the transformation process is done, the graphics hardware fills in the pixels belonging to each primitive. This process is known as rasterization. The depth, colour, and interpolated texture coordinates are calculated for each pixel. This information, combined with the location of the pixel, is known as a fragment. The fragment then has to pass through a series of calculations and tests before it can finally be output to the framebuffer.

In working with shaders, the two portions of the pipeline that we will be modifying are the per-vertex and per-fragment operations. These sections are changed according to our desires through vertex and fragment shaders. There is a third type of shader, called the geometry shader, that allows the modifying of graphics primitives that have been sent to the graphics hardware. However, geometry shaders are still new to consumer hardware, so, as of writing, there is a lack of hardware support, and we will not be covering them.

References:

1. Mathematics for 3D Game Programming & Computer Graphics, 2nd Ed., Eric Lengyel, Charles River Media