Skip to content

Latest commit

 

History

History
313 lines (230 loc) · 8.71 KB

lecture04.adoc

File metadata and controls

313 lines (230 loc) · 8.71 KB
Raw

Programming Tips and Representing the World (a little)

Overview

  • Some programming tips

  • Representing our "World"

  • Simulation

Accessing data from other functions

  • Our game loop should be calling other functions

    • How do those functions access the data they need

link:examples/myFirstSprite/main.cpp[role=include]

What data ?

  • What data does each need access to?

    1. process_input ??

    2. update ??

    3. render ??

  • Should we limit the data that these functions can access?

    • discuss …​

  • Should they be able to change that data?

What data? 2

  1. process_input

    • game control state

  2. update

    • world representation

  3. render

    • world representation

Ways of providing access to data?

  • How can we let our functions access the data they need?

Ways of providing access to data? 2

  • How can we let our functions access the data they need?

    1. pass pointers/reference to the data??

    2. pass the values of the data??

    3. make the data global??

Separating parts of Game Loop

  • The three main parts of our Game Loop should each only do some things

process_input

  • process_input should only process input

    • it should set controller state - what has happened in the world

      • abstract things, rather than low-level events

      • e.g. "jump", not "button X pressed"

    • it shouldn’t change the world state

    • it shouldn’t render anything

Update Simulation

  • AKA stepSimulation (take a simulation step)

  • update should only update the world state

    • according to the world state and controller state

    • and how long to simulate for (duration)

    • it shouldn’t render anything

    • it shouldn’t handle input

Render

  • render should only render

    • according to the world state

    • it shouldn’t change the world state

    • it shouldn’t handle input

Limiting access and influence

  • You could use C++ features to limit what each of these functions can do

    • e.g. render could be passed a constant reference to the "World"

      • so that C++ won’t let render change the World state

      • attempting to change would be a compile-error

Function/method signatures and reading the documentation!!

  • The function/method signature tells you what you need to give the function, or order to use it

  • Good documentation should explain what the function/method does and how to use it

  • Many libraries provide only C interfaces, even if we’re using C++

    • e.g. SDL and OpenGL

SDL_RenderCopy signature

int SDL_RenderCopy(SDL_Renderer*   renderer,
                   SDL_Texture*    texture,
                   const SDL_Rect* srcrect,
                   const SDL_Rect* dstrect);

  • What is each parameter?

    • What do they control?

  • What does the const do?

SDL_GetWindowSize signature

void SDL_GetWindowSize(SDL_Window* window,
                       int*        w,
                       int*        h);

  • How does this return data??

    • the function returns void !!!

SDL_GetWindowSize example use

Example
SDL_Window window* SDL_CreateWindow( "title",
  SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED,
  800, 600,
  NULL);

int width;
int height;
SDL_GetWindowSize(window, &width, &height);
SDL_assert(width == 800);
SDL_assert(height == 600);

Representing our "World"

  • So far our "World" consists of merely a single Sprite

    • things will get more complex and larger

  • What can we control about this Sprite at the moment?

    • ??

    • Or what properties does it have??

Our lonely Sprite

  • Position - where on the screen

    • in what coordinate system

  • Size

    • in what coordinate system

  • Texture

What do need to able to do with our Sprite?

  • ???

What do need to able to do with our Sprite 2

  • Move it

    • at what rate? (velocity?)

  • Render it?

  • Animate it?

  • Do some kind of collisions with it?

  • …​

Classes for things

  • We’re using C++, so we should have classes for our objects

    • to encapsulate data

    • to allow functions on that data

    • these don’t have to be the same classes …​

      • perhaps contrasting with "normal" OOP

Class inheritance

  • You could use an inheritance model with your classes

    • but DON’T use multiple-inheritance - there be dragons

blue dragon ii

Entity-Component-Systems

  • There are many ways to use classes for programming Games

    • especially with regards to efficiency and flexibility

  • The Entity-Component model is an alternative to inheritance

    • Composition vs. Inheritance

Entities

  • Each type of thing is an Entity - e.g. a Dragon

  • Entities have no logic

  • Each Entity has a set of components that belong to it, or each entity refers to

    • Position

    • Texture

    • Velocity

Components

  • Each component holds data

    • the data needed for some behaviour, such as rendering

System

  • Each "system" processes through a certain set of entities

    • such as all those with a Position and Velocity, and updates the positions

    • such as all those with a Position and Sprite, and renders them

Entity-Component-Systems

  • Could be overkill for within this module

    • So might an inheritance heirarchy with more than 2 levels

  • The separation of Data and Logic allows for significant performance enhancements

  • See Recommended Reading

C++

  • Make CLASSES !!!!

  • Make class hierarchies if/when appropriate

Multiple files in your project

  • You presently only have one source file - main.cpp

  • Your present CMakeLists.txt file only try to make an exe out of that single file

link:examples/myFirstSprite/CMakeLists.txt[role=include]

Multiple files in your project 2

  • You should make new classes in new files (generally)

    • with a .h and a .cpp, usually

  • You’ll need to tell cmake to compile those files into your program also

    • add them to list of files in add_executable

  • What should you add?

Multiple files in your project 3

  • Here’s an example

    • there are other ways of doing this

project(ConanTest)
cmake_minimum_required(VERSION 2.8.12)

include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
conan_basic_setup()

add_executable(conanTest main.cpp myClass.h myClass.cpp)
target_link_libraries(conanTest ${CONAN_LIBS})

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
set_property(DIRECTORY PROPERTY VS_STARTUP_PROJECT "conanTest")

Globbing in CMake

  • Listing all the source files for executable might become a list annoying

  • CMake supports globbing and recursive globbing

    glob

    match files names according to a pattern. e.g. *.txt

  • We could generate a list of files to add to our executable with a glob

    • WARNING: the CMake people recommend AGAINST this practice.

file(GLOB source_list "*.cpp" "*.h")
add_executable(conanTest ${source_list} )
target_link_libraries(conanTest ${CONAN_LIBS})

Making new files in Visual Studio

  • WARNING: Visual Studio will by default put new items in project’s root

    • in your build folder [frown o]

  • REMINDER: Everything in your build folder should be considered temporary

    • you want to be able to remove the entire folder do get a clean system

Making new files in Visual Studio 2

  • IF you use "Add New Items" (or equivalent) in Visual Studio

    • REMEMBER to change the path where it creates the new file

    • to the root of your project (e.g. gamesProgramming)

    • REMEMBER to add the files to your CMakeLists.txt file also

      • Your project will still build without this

      • BUT only until your rerun CMake (e.g. when you moves machines)

  • You could choose to make a src folder at this point, to collect all your source code

    • to make things more organised

    • you’ll need to update your CMakeLists.txt files to match the new locations