Emerging Technologies for Games Module Overview

1
Emerging Technologies for GamesModule Overview

• CO3303
• Week 1, Part 1

2
Module Outline

• 23 weeks
• Plus 1 revision session
• Topics overlap and extend Games Dev 2
• 1 Assignment
• 3 hour written exam

3
3rd Year Project Essentials

• First 2 weeks
• Key topics needed by those starting programming
  projects
• Also needed to understand advanced code samples
  for later material
• Will use commercial grade code from here on

4
Advanced Graphics

• Animation
• Quaternions, (S)LERP
• Animation storage and compression
• Character animation physics
• Inverse Kinematics (IK)
• Scene post-processing
• Bloom, depth-of-field, motion blur
• Advanced lighting
• Spherical harmonics, High dynamic range

5
Scene/Entity/Gfx Interface

• Extends basic scene/entity management from Games
  Development 2 module
• Space partitions
• Portals, BSP trees
• Quad Oct-trees
• E.g. for graphics culling, priority queuing of
  entities and further game/gfx integration
• Instancing

6
Optimisation

• When to optimise (rarely)
• Performance profiling
• Optimisation techniques
• Algorithmic methods
• Optimising memory use
• Cache coherency
• Language considerations
• Balancing optimisation requirements

7
Console Development

• Console tools and techniques
• Working with development kits
• Dealing with custom hardware
• Low-level optimisations
• Concurrent programming
• Needs of next-gen hardware
• Multi-core threads, mutexes, etc.
• Asset management for games development

8
Emerging Technologies for GamesProject
Essentials 1

• CO3303
• Week 1, Part 2

9
Todays Lecture

• Project Organisation
• Concrete Classes
• Macros for Error Handling

10
Project and File Organisation

• Organise your files, both in VS and real folders
• Use a consistent code convention
• Variable names iCount or count
• Constants kSpeed or SPEED
• Classes, structs CVector or Vector, SType or
  Type
• Consistent layouts for functions, classes etc.

11
Project and File Organisation

• Try to use classes to encapsulate each distinct
  process or element in your program
• Draw a UML architecture update it as necessary
• Include all the diagrams and rationale for each
  change in your project report
• One class per .h/.cpp file sensible file names

12
Project and File Organisation

• Wrap all your code in a namespace of your own
• Prevents clashes with other libraries
• TL-Engine uses namespace tle ...
• More advanced projects might justify several
  sub-namespaces for different sections
• E.g. render, scene, ai
• Organise your files by namespace
• Can use elements from an external namespace
• tleNew3DEngine( kIrrlicht )

13
Part 2 Common Types

• Several small reusable built-in types in C
• int, float, char
• Often need further simple types
• Date, time, vector, matrix, complex number
• Would like
• Simplicity of use
• Efficiency memory and speed
• Why not use a struct?
• struct SVector float x, y, z

14
Too much coding

• Get code like this
• SVector v 10.0f, 20.0f, 30.0f
• float length v.xv.x v.yv.y v.zv.z
• length sqrt(length)
• v.x v.x / length v.y v.y / length
• v.z v.z / length
• SVector w 30.0f, 10.0f, 20.0f
• float dot v.xw.x v.yw.y v.zw.z
• Too much code
• More code more errors
• More code cache inefficient slow code
• Writing common functions would help, but what
  about OO

15
Concrete Class

• Isnt this better?
• CVector v( 10.0f, 20.0f, 30.0f )
• CVector w( 30.0f, 10.0f, 20.0f )
• float dot Dot( w, v.Normalise() )
• Just create a simple class
• class CVector
• float x, y, z
• public
• Cvector( float inX, float inY, float inZ )
• CVector Normalise()
• float Dot( const CVector a, const CVector b )
• This is called a concrete class
• Simple reusable class type like a struct with
  functions

16
Advantages

• Code is much simpler
• Less error prone
• All code in one place
• Only write each operation once
• Easy to locate errors, and errors wont be
  repeated
• Less code is more cache efficient
• Much faster programs
• More scope for overloading operators
• v w cout ltlt v
• Test which of these is only possible using a
  class?

17
Disadvantages

• Need more preparation to use concrete classes
• 1st example coding straight away
• Only a benefit to a hacky or lazy coder
• Dont use this logic at the start of your project
• private access to data overkill?
• Need v.GetX() or v.X(), not just v.x
• Compiles to same code, so not inefficient
• But makes code slightly less readable
• Could use public if data will never change, and
  has only one reasonable representation
• E.g math types (but changing from float to
  double?)

18
Watch out

• Concrete classes dont need a separate interface
• Expose the full concrete class definition to all
• Easy to write a very fat interface
• Huge number of member functions
• Can be useful, or might be overkill
• See maths classes in lab and decide for yourself
• Generally, dont inherit from a concrete class
• Use of virtual functions will reduce efficiency
• Better to use the concrete class for a member
  variable of the new class

19
Part 3 Macros always bad ?

• These macros are bad
• define MAX_ENTITIES 100
• define Min(a,b) (((a) lt (b)) ? (a) (b))
• These are the good definitions
• const int kMaxEntities 100
• template ltclass Cgt
• inline C Min( const C a, const C b )
• return ((a lt b) ? a b)
• Better control over types, debugging etc
• Can macros ever be good ?

20
Exception Handling

• Consider this function
• float AverageList( CFloatList myList )
• try
• return myList.Sum() / myList.Size()
• catch(...) // Unexpected exception
• UsefulErrorMsg()
• Catching unexpected exceptions is useful
• Aids debugging
• But reduces readability considerably

21
Good Macros?

• Unexpected exception handling for all functions?
• Same code sequence appears everywhere
• Further worsening readability
• Cant use functions to do this task
• But we can use macros for text substitutions
• define GUARD try
• define ENDGUARD catch(...)
  UsefulErrorMsg()
• float AverageList( CFloatList myList )
• GUARD
• return myList.Sum() / myList.Size()
• ENDGUARD

22
Good Macros!

• Is this a good idea?
• Easy to add
• Good readability
• Only targets unexpected exceptions but could
  easily add more specific handling if we needed
• The error handler can ouput the call stack, file
  name and line number of the exception
• Greatly aiding debugging
• Still, some people dont like this use of macros
• Prefer to add explicit code in all cases

23
More Debugging Macros

• Likely problem in this function is empty list
• float AverageList( CFloatList myList )
• GUARD
• return myList.Sum() / myList.Size()
• ENDGUARD
• Causes divide by zero possible exception
• Use assert function or macro to flag this
  clearly
• define ASSERT( condition, msg )\
• if (!(condition)) ThrowKnownException(msg)
• Note use of \ to continue a macro onto next line

24
More good macros!

• This version is more informative upon errors
• float AverageList( CFloatList myList )
• GUARD
• ASSERT( myList.Size() gt 0,Cant average empty
  list )
• return myList.Sum() / myList.Size()
• ENDGUARD
• And is still readable
• In fact the assertion highlights limitations of
  the function
• Remember, this is for unrecoverable fatal errors
• These are primarily debugging tools
• Better to recover from an error wherever possible