GMNG 4312 –Game Engines

1. GMNG 4312 –Game Engines Unit 02:Tools of the Trade Alireza Tavakkoli, Ph.D.

2. Objectives • Tools of the Trade • Version Control • Visual Studio 2010 • Profiling Tools • Memory Leaks and Corruption Detection Tools • Other Tools

3. Version Control • What is Version Control? • Multiple users to work on a project • Trace changes • Keep track of multiple modifications • Share the latest code • Avoid unintentional code corruptions • Even for one user • Keep a copy of the latest files on the repository • On multiple machines! • Version control keeps track of the history of the files! • Also called source control. • Can be used to keep track of text files and binaries as well. • Invaluable in Gaming Industry!

4. Why Using Version Control? • Reasons to use version control • Central repository • Keeping history of changes • Tagging specific code versions for retrieval • Branching off from main development for patches and updates • As mentioned source control is also useful in single engineer projects!

5. Common Version Control Systems • SCCS and RCS • Source Code Control System and Revision Control System • Oldest version control systems • Use command line interface • CVS • Concurrent Version System • Heavy-duty professional grade version control • Command-line based • Mostly in UNIX bases systems • CVSSNT (WinCVS) is the windows counterpart

6. Common Version Control Systems • Subversion • Open source version control system • Popular for individual, student, small studio projects • We use this! • Git • Open source revision control • Used for linux kernel • Make changes to files  Commit to branches • Git can roll the diff(erences) and reapply them to new bases revisions  rebasing.

7. Common Version Control Systems • Perforce • A Professional grade source control system • Change lists: • A collection of source files that have been modified as a logical unit. • Useful as a transaction processing unit • Either all changes within the list are submitted or none will. • NxNAlienbrain • A source control system for the game industry • Support very large databases • Specially for binary assets like movies, 3D models, etc.

8. Common Version Control Systems • ClearCase • Very large scale software production • A Unique UI that extends the windows explorer functionality • Expensive! • Microsoft Visual SourceSafe • Light-weight source control package

9. Subversion and TortoiseSVN • We use Subversion • It’s free • It’s nice and reliable • Easy to setup • Actually we use GoogleCode! • A number of windows and mac subversion clients • We use TortoiseSVN • Client-Server Architecture • Server contains the repository • Client connect to server to update the repository • Commits, Updates, Tags, Revisions, Branches, etc. • Let’s see how to set up our Source Version Control system.

10. Setting Up Version Control • Code.Google.Com • http://code.google.com • Setup an account • Sign in • Go to project hosting • Create a project for Google Code (or Eclipse Labs). • Set up administrative options and users. • 4GB with 200MB upload size limit

11. Setting Up Version Control • Download and install TortoiseSVN: • http://tortoisesvn.tigris.org • Using TortoiseSVN • Create folders in your local machine • Right-click and from context menu • Check out project • Use “https://” URL for checkout with commit functionality • Uset “http://” URL for read-only checkouts • URLs can be found under your “profile” after signing-in to GoogleCode • To commit you need GoogleCode password • Differenet than your google account password • Go to project  source  GoogleCode password

12. Using SVN • File Versions, Updating, Committing • Multiple programmer – Multiple files • Keep track of changes • Use a master version of all files • This is your repository! • All versions will remain in the repository! • Even deletes • You can track every thing in the repository • Even commits that “break” the build! • Each programmer has a local copy • After updating with repository • Work on your local copy • Commit the changes you made when you are absolutely certain you would want to do so!

13. Using SVN • Diffs • During a commit operation a diff is created • Changes between the repository and local version • Line by line comparison • Double click in the commit dialog to see the diffs • Can check it out on google code as well. • Non Versioned files • New files that don’t exist in the repository • Missing • The files that are deleted • Will not be removed from repository! • Are tagged as deleted.

14. Using SVN • Multiple Check Outs • Exclusive checkout • Locking items that are checked out • Ensure no simultaneous edits! • Subversion does not explicitly asks this! • Multiple checkouts • The first committed files become the latest on the repository! • Other commits must be merged with the latest version! • More than one set of diffs is generated! • Most conflicts can be resolved automatically • Editing different parts by different users! • In other cases a three-way merge is necessary

15. Using SVN • Three-way Merge • When programmers made changes to similar contents checkout (A) checkout (B) Version 1 checkout (A) Version 2 Version 1 Version 3 Checkout (A) Version 2 Version 1

16. Using SVN • Deleting Files • Deleted files are not really gone! • They are merely tagged as deleted. • The users will no longer see files in their local directory. • Use “Show Log” to see and access the deleted files. • Un-deleting the files • Recommit the latest version

17. Microsoft Visual Studio • There are many compilers for C++ • What is a compiler • How are C++ files used? • Compile + Link • MS Visual Studio • Professional • Express • http://www.microsoft.com/express/download • Visual Studio is an IDE • Source code + Machine code + debugger

18. Different Files • Source, header and translation units • Source code contains the course files. C++, C, CPP, etc. • Translation Units • Compiler translates into machine code • Header files • Contain type declaration, function prototypes, etc. • Share between translation units • Compiler doesn’t see header files • Preprocessor! • Use #include statement • Distinct from programmer’s point of view!

19. Libraries, Executables, DLLs • Object File • The translated version of a translation unit (.obj or .O) • Relocatable • Code memory addresses not determined. • Unilked • External references (to functions, etc.) have not been resolved. • Libraries • Groups of object files! • A convenience

20. Libraries, Executables, DLLs • Executables • Objects and libraries have to be “linked” into executable files. • Contain fully resolved machine code • Linkers operations • To calculate final relative addresses of all machine code • Ensure all external references are resolved properly • Global data • Reference functions • Executable is relocateable • The addresses are still relative to the base address • It is finalized when the executable is in RAM!

21. Dynamic Linked Library (DLL) • What is a DLL? • Hybrid between (static) library and executable • Acts like a library • Contains functions that can be called • Acts like an executable • Can be loaded by the OS independently • Contains startup and shutdown code! • Executables that use DLLs contain partially linked machine code • The references and data to the DLL remain unlinked! • Upon running the OS resolves the unlinked information from the DLL. • Load the DLLs in the memory and patch in the addresses! • Look for them in the bin folder .

22. Projects and Solutions • Projects • Collection of source files that compile into • Executables, libraries or DLLs • Stored in .vcproj • Are XML files • Human readable • Solutions are the collections of • Projects • Solution Explorer • Solution is the root

23. Build Configurations • Variety of Options in MSVS • Command line • C:\> cl /c function.cpp /Fo Function.obj /Wall /Od /Zi • Compile  all warnings on  no optimization  generate debugging information • This is too complicated and impractical • Use build configurations • What is a build configuration • A collection of options for preprocessor, compiler, linker, etc. • Can make different configurations for different translation units. • Two most important configurations • Debug and Release

24. Common Build Options • Preprocessor Settings • Handles • the header expansions • Type definitions • Can define preprocessor macros • Macros act like code! • Are replaced in code! • Very Efficient! • Example • _DEBUG • #ifdef _DEBUG • Some debug lines • #endif

25. Compiler Settings • Controlling debugging information • Makes executable file larger • Runs less efficiently • Can walk through your code and see values • Can reverse-engineer a project • Inline function Expansion • For optimization • How does it work? • Off Once in memory • Why is it useful? • Is inlining good? • Speed vs. Debugging

26. Compiler Settings (Continued) • Optimizations • E.G. Inline Expansion • Reorder statements • Variable manipulations • Less debuggability • In debug mode • Turn off all optimizations

27. Linker Settings • Linker is what makes the external references resolve. • Define type of output files • Executable or DLL • Which external libraries to link • Paths to find them • Common practice • Link debug libraries with debug builds and release with release builds • Debug libraries are less optimized • Controlling things like stack size, etc. • See MSVS 2010 Express

28. Typical Build Settings • Debug • Slow version • Good for debugging • Additional information, less optimization • Release • Faster version • Debugging and assertions still on • Production • Final game files • Tools • Used for conditionally build shared code to use by other tools • Ex. Expose code that’s not used by the game, and use #ifdef _TOOLS_BUILD directive.

29. Build Configurations and Testability • The more build configuration the more difficult the testing • Usually testing not done in debug • Some builds may show up some bugs that are not in other builds • Test betas and alpha! • Advantage • Keep build configurations to a minimum • Ship release build after thorough tests!

30. Project Configuration • Project properties • General • Debugging • C++ • Linker • Configuration dropdown combo box

31. Project Configuration • The General Tab

32. Project Configuration • The General Tab • Macros • Benefits • Can relocate • See a complete list

33. Project Configuration • The Debugging Tab

34. Project Configuration • The C/C++ Tab

35. Project Configuration • The C/C++ Tab

36. Project Configuration • The Linker Tab

37. Project Configuration • The Linker Tab

38. Creating A New C++ Project • Setup and Empty Project • OGRE • Make the modifications and configurations settings • Use A Wizard • Copy A Working Project • May need to make modifications to the CML .vcproj file • $(OutDIr)\MyGame.exe • $(OutDir)\(ProjectName).exe

39. Debugging Your Code • The startup project • Breakpoints • Stepping through your code • The call stack • The watch window • Data breakpoints • Conditional breakpoints

40. The Startup Project • A Solution may contain more than one project • Only one project can be debugged at a time • The Startup Project Setting • The Startup Project • Bold face in the solution explorer • “F5” debugs the startup executable!

41. Break Points • Invaluable for debugging • Stop the execution of the project for you to see all sorts of things. • “F9” toggles a break point in code • To step through your code • F10 • Single-step-over • F11 • Single-step-in

42. The Call Stack • Shows the stack (and order) of functions

43. The Watch Window • Inspect variable values • Type any expression • Call functions • Define suffixes • ,d ,x ,n

44. Data Break Points • Trigger whenever a memory address is changed • Also called hardware breakpoints.

45. Conditional Breakpoint • Evaluate a condition and if true stop for debugging • E.g. have 20 tanks but want to see the values of the 4th one! • Call conditional on the value of a class! • Or when running a loop you want to see what happens after 400 iterations • Press F5 400 times! • Or set up a hit count

46. Debugging optimization builds • Learn disassembly • Use registers to deduce variables • Inspect variables and object contents by address • Use static and global variables • Modify the code

47. Profiling Tools • Most of the time is spend by the least part of the code! • Statistical Profilers • Use CPU information for percentage of function CPU use • Instrumenting Profilers • Comprehensive profiling data • At the expense of the execution time!

48. Memory Leaks and Corruption Detection • What’s great about C++ • Pointers • What can be the source of evil in C++ • Pointers • Allocation/deallocation inconsistency • Dangling pointers • Memory leaks

49. Other Tools • Difference tools • Three way merge tools • Hex Editors

50. Questions? • Game Engine Architecture • Chapter 2