RAGE: A PROGRAMMABLE SHADER-BASED OPENGL RENDERER AND SCENE GRAPH A Project Presented to the faculty of the Department of Computer Science California State University, Sacramento Submitted in partial satisfaction of the requirements for the degree of MASTER OF SCIENCE in Computer Science by Raymond L. Rivera Albaladejo SPRING 2017 © 2017 Raymond L. Rivera Albaladejo ALL RIGHTS RESERVED ii RAGE: A PROGRAMMABLE SHADER-BASED OPENGL RENDERER AND SCENE GRAPH A Project by Raymond L. Rivera Albaladejo Approved by: ________________________________, Committee Chair V. Scott Gordon, PhD ________________________________, Second Reader Pinar Muyan-Ozcelik, PhD ________________________________ Date iii Student: Raymond L. Rivera Albaladejo I certify that this student has met the requirements for format contained in the University format manual, and that this project is suitable for shelving in the Library and credit is to be awarded for the project. ___________________________, Graduate Coordinator ________________________ Jinsong Ouyang, PhD Date Department of Computer Science iv Abstract of RAGE: A PROGRAMMABLE SHADER-BASED OPENGL RENDERER AND SCENE GRAPH by Raymond L. Rivera Albaladejo Computer applications are generally constrained to working only on specific platforms because they are engineered to rely on their services directly. The complexities of computer games only magnify and propagate this problem into different domains. To avoid limitting computer games to specific platforms, such as Microsoft Windows or GNU/Linux, an intermediate service framework is proposed to decouple the game applications from their host operating systems. While such frameworks already exist, they are almost exclusively built for the professional software engineer. This often makes their scope, licensing, complexity, and cost, prohibitive factors in the context of a single semester for an undergraduate course. The purpose of this report is to describe a new framework, called RAGE1, that is based on current technology, significantly simpler than professional suites, freely available with a freedom-respecting license, compatible with Microsoft Windows and GNU/Linux, and promotes student access, contributions, and collaboration. 1 RAGE has several meanings such as Raymond's "Awesome" Game Engine and, recursively, RAGE replAces saGE, among others. v Although instructors have a framework developed in-house, called the Simple Adaptable Game Engine (SAGE), it relies on deprecated technology, is bound to the Microsoft Windows platform, and is released under a proprietary license, which prevents direct student access to the original source code –limiting their ability to study, modify, and share the code itself. RAGE, however, supports both Microsoft Windows and GNU/Linux platforms and is itself released under a libre/free-software license, granting everyone the right to access, study, modify, and share the source code, all of which are expected to make a positive impact for interested users –especially for students and their educational experience. _____________________________, Committee Chair V. Scott Gordon, PhD _____________________________ Date vi DEDICATION To the one and only true God, who always keeps his word. “Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee whithersoever thou goest.” –Joshua 1:9 (KJV) ✝ I dedicate my master's project to my mother, Elsa N. Albaladejo � � � , who taught me the value of education, wisdom, and knowledge from a very early age and encouraged me to always work my way toward greater goals. I could not have gotten this far without her infinite amount of support –or an interest in games that can be traced all the way back to the 8-bit NES console she got me as a Christmas gift when I was 5 years old, which continues to work to this day � . She had no idea it would have serious and irreversible side-effects, such as game engine development... � , but I am forever grateful. I also dedicate this project to my sister, Frances J. Rivera � � �, with whom I played many games for countless hours including Super Mario Kart for SNES, Command and Conquer: Red Alert Retaliation for PS1 with a cross-over cable for our first proper "LAN Party", and her all-time favorite NES title, Bubble Bobble, one of several games that came to be the digital embodiment of the word "rage", with 100 traps levels that will trick you into getting stuck so that vii you are forced to commit seppuku while it continues to play cute tunes in the background, and that, as its final act of hate, would also refuse to reveal it's "true" ending unless it was completed in two-player mode... � � While contemplating the prospect of moving to California several years ago, she was one of the persons I spoke to. At one point during that conversation she said "I'd do it". It is, in part, her fault that you are reading this now � I also dedicate this work to my immediate family and close friends who have supported me over the years, including those who participate in the LAN Parties I have been hosting every year at home for over a decade. Thank you and keep gaming � � � � viii ACKNOWLEDGEMENTS I thank my advisor, Dr. Scott Gordon, for his support in this project, and particularly for his feedback on early drafts of this report and associated presentation slides. His help clarifying some of the transformation matrices early on, as well as his time, which we sometimes spent on extended discussions, was greatly appreciated. I am also thankful for his support of my choice of software license for RAGE and its associated documentation. I thank my secondary reader, Dr. Pinar Muyan-Ozcelik, for reviewing a draft of this report and providing feedback. Her comments and suggestions were helpful in improving its overall clarity, particularly in early, more introductory, chapters. I thank my sister, Frances J. Rivera, for reading early drafts and checking for typos, formatting, and consistency issues. I also appreciate my friend, Hector I. Nieves, for his time and feedback on early versions of the presentation slides, and particularly for smoothing out the hard shadows in the last slide's image. My GIMP-fu will never be as strong as his Photoshop-fu. I also thank users Sven Gothel, Xerxes Rånby, and jmaasing for some of the help I received in the forums while coming to grips with some aspects of JOGL and for accepting my tessellation shader feature request and merging my test case contributions into the main tree. Finally, I thank the StackOverflow, GameDevelopment, Math, and ComputerGraphics sub-communities of the wider StackExchange network for their assistance in some of the questions I had during the course of this project. ix TABLE OF CONTENTS Page Dedication....................................................................................................................................vii Acknowledgements........................................................................................................................ix List of Tables...............................................................................................................................xvi List of Figures.............................................................................................................................xvii List of Code Listings...................................................................................................................xxi Chapter 1. INTRODUCTION......................................................................................................................1 1.1. Games as Regular Applications.........................................................................................1 1.2. Operating System Considerations......................................................................................1 1.3. Hardware Considerations..................................................................................................2 1.4. The Problem with Variation...............................................................................................2 2. GENERAL DESIGN GOALS....................................................................................................4 2.1. Loose Coupling Between Components..............................................................................4 2.1.1. Decoupling Game Clients from Scene Management................................................6 2.1.2. Decoupling Scene Structure from its Contents.........................................................7 2.1.3. Decoupling Scene Management from Rendering.....................................................8 2.1.4. Decoupling Assets, Loading, and Management........................................................9 2.1.5. Uniformity Across Asset Managers and Loaders....................................................10 2.1.6. Improving Asset Management Efficiency..............................................................10 2.1.7. Decoupling Assets and Scene Objects from States.................................................11 2.1.8. Replacing Hard-Coded Paths for Configuration Files............................................12 x 2.2. Singleton Objects without the Singleton Design Pattern.................................................12 2.2.1. Global Objects are No Better than Global Variables..............................................12 2.2.2. Global Data is Prone to Race Conditions...............................................................13 2.2.3. Dependencies Among Objects Not Reliably