Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Save more on your purchases! discount-offer-chevron-icon
Savings automatically calculated. No voucher code required.
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Newsletter Hub
Free Learning
Arrow right icon
timer SALE ENDS IN
0 Days
:
00 Hours
:
00 Minutes
:
00 Seconds
Mastering SFML Game Development
Mastering SFML Game Development

Mastering SFML Game Development: Inject new life and light into your old SFML projects by advancing to the next level.

eBook
$15.99 $39.99
Paperback
$48.99
Subscription
Free Trial
Renews at $19.99p/m

What do you get with eBook?

Product feature icon Instant access to your Digital eBook purchase
Product feature icon Download this book in EPUB and PDF formats
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
OR
Modal Close icon
Payment Processing...
tick Completed

Billing Address

Table of content icon View table of contents Preview book icon Preview Book

Mastering SFML Game Development

Introduction

What is the heart of any given piece of software? The answer to this question becomes apparent gradually while building a full-scale project, which can be a daunting task to undertake, especially when starting from scratch. It’s the design and capability of the back-end that either drives a game forward with full force by utilizing its power, or crashes it into obscurity through unrealized potential. Here, we’re going to be talking about that very foundation that keeps any given project up and standing.

In this chapter, we're going to be covering the following topics:

  • Utility functions and filesystem specifics for Windows and Linux operating systems
  • The basics of the entity component system pattern
  • Window, event, and resource management techniques
  • Creating and maintaining application states
  • Graphical user interface basics
  • Essentials for the 2D RPG game project

There's a lot to cover, so let's not waste any time!

Pacing and source code examples

All of the systems we're going to be talking about here could have entire volumes dedicated to them. Since time, as well as paper, is limited, we're only going to be briefly reviewing their very basics, which is just enough to feel comfortable with the rest of the information presented here.

Note

Keep in mind that, although we won't be going into too much detail in this particular chapter, the code that accompanies this book is a great resource to look through and experiment with for more detail and familiarity. It's greatly recommended to review it while reading this chapter in order to get a full grasp of it.

Common utility functions

Let's start by taking a look at a common function, which is going to be used to determine the full absolute path to the directory our executable is in. Unfortunately, there is no unified way of doing this across all platforms, so we're going to have to implement a version of this utility function for each one, starting with Windows:

#ifdef RUNNING_WINDOWS 
#define WIN32_LEAN_AND_MEAN 
#include <windows.h> 
#include <Shlwapi.h> 

First, we check if the RUNNING_WINDOWS macro is defined. This is the basic technique that can be used to actually let the rest of the code base know which OS it's running on. Next, another definition is made, specifically for the Windows header files we're including. It greatly reduces the number of other headers that get included in the process.

With all of the necessary headers for the Windows OS included, let us take a look at how the actual function can be implemented:

inline std::string GetWorkingDirectory() 
{ 
   HMODULE hModule = GetModuleHandle(nullptr); 
   if (!hModule) { return ""; } 
   char path[256]; 
   GetModuleFileName(hModule,path,sizeof(path)); 
   PathRemoveFileSpec(path); 
   strcat_s(path,""); 
   return std::string(path); 
} 

First, we obtain the handle to the process that was created by our executable file. After the temporary path buffer is constructed and filled with the path string, the name, and extension of our executable is removed. We top it off by adding a trailing slash to the end of the path and returning it as a std::string.

It will also come in handy to have a way of obtaining a list of files inside a specified directory:

inline std::vector<std::string> GetFileList( 
   const std::string& l_directory, 
   const std::string& l_search = "*.*") 
{ 
   std::vector<std::string> files; 
   if(l_search.empty()) { return files; } 
   std::string path = l_directory + l_search; 
   WIN32_FIND_DATA data; 
   HANDLE found = FindFirstFile(path.c_str(), &data); 
   if (found == INVALID_HANDLE_VALUE) { return files; } 
   do{ 
       if (!(data.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)) 
       { 
          files.emplace_back(data.cFileName); 
       } 
     }while (FindNextFile(found, &data)); 
   FindClose(found); 
   return files; 
} 

Just like the directory function, this is specific to the Windows OS. It returns a vector of strings that represent file names and extensions. Once one is constructed, a path string is cobbled together. The l_search argument is provided with a default value, in case one is not specified. All files are listed by default.

After creating a structure that will hold our search data, we pass it to another Windows specific function that will find the very first file inside a directory. The rest of the work is done inside a do-while loop, which checks if the located item isn't in fact a directory. The appropriate items are then pushed into a vector, which gets returned later on.

The Linux version

As mentioned previously, both of the preceding functions are only functional on Windows. In order to add support for systems running Linux-based OSes, we're going to need to implement them differently. Let's start by including proper header files:

#elif defined RUNNING_LINUX 
#include <unistd.h> 
#include <dirent.h> 

As luck would have it, Linux does offer a single-call solution to finding exactly where our executable is located:

inline std::string GetWorkingDirectory() 
{ 
   char cwd[1024]; 
   if(!getcwd(cwd, sizeof(cwd))){ return ""; } 
   return std::string(cwd) + std::string("/"); 
} 

Note that we're still adding a trailing slash to the end.

Obtaining a file list of a specific directory is slightly more complicated this time around:

inline std::vector<std::string> GetFileList( 
   const std::string& l_directory, 
   const std::string& l_search = "*.*") 
{ 
   std::vector<std::string> files; 
    
   DIR *dpdf; 
   dpdf = opendir(l_directory.c_str()); 
   if (!dpdf) { return files; } 
   if(l_search.empty()) { return files; } 
   std::string search = l_search; 
   if (search[0] == '*') { search.erase(search.begin()); } 
   if (search[search.length() - 1] == '*') { search.pop_back(); } 
  struct dirent *epdf; 
  while (epdf = readdir(dpdf)) { 
    std::string name = epdf->d_name; 
    if (epdf->d_type == DT_DIR) { continue; } 
    if (l_search != "*.*") { 
      if (name.length() < search.length()) { continue; } 
      if (search[0] == '.') { 
        if (name.compare(name.length() - search.length(), 
          search.length(), search) != 0) 
        { continue; } 
      } else if (name.find(search) == std::string::npos) { 
        continue; 
      } 
    } 
    files.emplace_back(name); 
  } 
  closedir(dpdf); 
  return files; 
} 

We start off in the same fashion as before, by creating a vector of strings. A pointer to the directory stream is then obtained through the opendir() function. Provided it isn't NULL, we begin modifying the search string. Unlike the fancier Windows alternative, we can't just pass a search string into a function and let the OS do all of the matching. In this case, it falls more under the category of matching a specific search string inside a filename that gets returned, so star symbols that mean anything need to be trimmed out.

Next, we utilize the readdir() function inside a while loop that's going to return a pointer to directory entry structures one by one. We also want to exclude any directories from the file list, so the entry's type is checked for not being equal to DT_DIR.

Finally, the string matching begins. Presuming we're not just looking for any file with any extension (represented by "*.*"), the entry's name will be compared to the search string by length first. If the length of the string we're searching is longer than the filename itself, it's safe to assume we don't have a match. Otherwise, the search string is analyzed again to determine whether the filename is important for a positive match. Its first character being a period would denote that it isn't, so the file name's ending segment of the same length as the search string is compared to the search string itself. If, however, the name is important, we simply search the filename for the search string.

Once the procedure is complete, the directory is closed and the vector of strings representing files is returned.

Other miscellaneous helper functions

Sometimes, as text files are being read, it's nice to grab a string that includes spaces while still maintaining a whitespace delimiter. In cases like that, we can use quotes along with this special function that helps us read the entire quoted segment from a whitespace delimited file:

inline void ReadQuotedString(std::stringstream& l_stream, 
  std::string& l_string) 
{ 
  l_stream >> l_string; 
  if (l_string.at(0) == '"'){ 
    while (l_string.at(l_string.length() - 1) != '"' || 
      !l_stream.eof()) 
    { 
      std::string str; 
      l_stream >> str; 
      l_string.append(" " + str); 
    } 
  } 
  l_string.erase(std::remove( 
    l_string.begin(), l_string.end(), '"'), l_string.end()); 
} 

The first segment of the stream is fed into the argument string. If it does indeed start with a double quote, a while loop is initiated to append to said string until it ends with another double quote, or until the stream reaches the end. Lastly, all double quotes from the string are erased, giving us the final result.

Interpolation is another useful tool in a programmer's belt. Imagine having two different values of something at two different points in time, and then wanting to predict what the value would be somewhere in between those two time frames. This simple calculation makes that possible:

template<class T> 
inline T Interpolate(float tBegin, float tEnd, 
   const T& begin_val, const T& end_val, float tX) 
{ 
   return static_cast<T>(( 
      ((end_val - begin_val) / (tEnd - tBegin)) * 
      (tX - tBegin)) + begin_val); 
} 

Next, let's take a look at a few functions that can help us center instances of sf::Text better:

inline float GetSFMLTextMaxHeight(const sf::Text& l_text) { 
  auto charSize = l_text.getCharacterSize(); 
  auto font = l_text.getFont(); 
  auto string = l_text.getString().toAnsiString(); 
  bool bold = (l_text.getStyle() & sf::Text::Bold); 
  float max = 0.f; 
  for (size_t i = 0; i < string.length(); ++i) { 
    sf::Uint32 character = string[i]; 
    auto glyph = font->getGlyph(character, charSize, bold); 
    auto height = glyph.bounds.height; 
    if (height <= max) { continue; } 
    max = height; 
  } 
  return max; 
} 
 
inline void CenterSFMLText(sf::Text& l_text) { 
  sf::FloatRect rect = l_text.getLocalBounds(); 
  auto maxHeight = Utils::GetSFMLTextMaxHeight(l_text); 
  l_text.setOrigin( 
    rect.left + (rect.width * 0.5f), 
    rect.top + ((maxHeight >= rect.height ? 
      maxHeight * 0.5f : rect.height * 0.5f))); 
} 

Working with SFML text can be tricky sometimes, especially when centering it is of paramount importance. Some characters, depending on the font and other different attributes, can actually exceed the height of the bounding box that surrounds the sf::Text instance. To combat that, the first function iterates through every single character of a specific text instance and fetches the font glyph used to represent it. Its height is then checked and kept track of, so that the maximum height of the entire text can be determined and returned.

The second function can be used for setting the absolute center of a sf::Text instance as its origin, in order to achieve perfect results. After its local bounding box is obtained and the maximum height is calculated, this information is used to move the original point of our text to its center.

Generating random numbers

Most games out there rely on some level of randomness. While it may be tempting to simply use the classical approach of rand(), it can only take you so far. Generating random negative or floating point numbers isn't straightforward, to say the least, plus it has a very lousy range. Luckily, newer versions of C++ provide the answer in the form of uniform distributions and random number engines:

#include <random> 
#include <SFML/System/Mutex.hpp> 
#include <SFML/System/Lock.hpp> 
 
class RandomGenerator { 
public: 
  RandomGenerator() : m_engine(m_device()){} 
  ... 
  float operator()(float l_min, float l_max) { 
    return Generate(l_min, l_max); 
  } 
  int operator()(int l_min, int l_max) { 
    return Generate(l_min, l_max); 
  } 
private: 
  std::random_device m_device; 
  std::mt19937 m_engine; 
  std::uniform_int_distribution<int> m_intDistribution; 
  std::uniform_real_distribution<float> m_floatDistribution; 
  sf::Mutex m_mutex; 
}; 

First, note the include statements. The random library provides us with everything we need as far as number generation goes. On top of that, we're also going to be using SFML's mutexes and locks, in order to prevent a huge mess in case our code is being accessed by several separate threads.

The std::random_device class is a random number generator that is used to seed the engine, which will be used for further generations. The engine itself is based on the Marsenne Twister algorithm, and produces high-quality random unsigned integers that can later be filtered through a uniform distribution object in order to obtain a number that falls within a specific range. Ideally, since it is quite expensive to keep constructing and destroying these objects, we're going to want to keep a single copy of this class around. For this very reason, we have integer and float distributions together in the same class.

For convenience, the parenthesis operators are overloaded to take in ranges of numbers of both integer and floating point types. They invoke the Generate method, which is also overloaded to handle both data types:

int Generate(int l_min, int l_max) { 
  sf::Lock lock(m_mutex); 
  if (l_min > l_max) { std::swap(l_min, l_max); } 
  if (l_min != m_intDistribution.min() || 
    l_max != m_intDistribution.max()) 
  { 
    m_intDistribution = 
      std::uniform_int_distribution<int>(l_min, l_max); 
  } 
  return m_intDistribution(m_engine); 
} 
 
float Generate(float l_min, float l_max) { 
  sf::Lock lock(m_mutex); 
  if (l_min > l_max) { std::swap(l_min, l_max); } 
  if (l_min != m_floatDistribution.min() || 
    l_max != m_floatDistribution.max()) 
  { 
    m_floatDistribution = 
      std::uniform_real_distribution<float>(l_min, l_max); 
  } 
  return m_floatDistribution(m_engine); 
} 

Before generation can begin, we must establish a lock in order to be thread-safe. Because the order of l_min and l_max values matters, we must check if the provided values aren't in reverse, and swap them if they are. Also, the uniform distribution object has to be reconstructed if a different range needs to be used, so a check for that is in place as well. Finally, after all of that trouble, we're ready to return the random number by utilizing the parenthesis operator of a distribution, to which the engine instance is fed in.

Service locator pattern

Often, one or more of our classes will need access to another part of our code base. Usually, it's not a major issue. All you would have to do is pass a pointer or two around, or maybe store them once as data members of the class in need. However, as the amount of code grows, relationships between classes get more and more complex. Dependencies can increase to a point, where a specific class will have more arguments/setters than actual methods. For convenience's sake, sometimes it's better to pass around a single pointer/reference instead of ten. This is where the service locator pattern comes in:

class Window; 
class EventManager; 
class TextureManager; 
class FontManager; 
... 
struct SharedContext{ 
  SharedContext(): 
    m_wind(nullptr), 
    m_eventManager(nullptr), 
    m_textureManager(nullptr), 
    m_fontManager(nullptr), 
    ... 
  {} 
 
  Window* m_wind; 
  EventManager* m_eventManager; 
  TextureManager* m_textureManager; 
  FontManager* m_fontManager; 
  ... 
}; 

As you can see, it's just a struct with multiple pointers to the core classes of our project. All of those classes are forward-declared in order to avoid unnecessary include statements, and thus a bloated compilation process.

Entity component system core

Let's get to the essence of how our game entities are going to be represented. In order to achieve highest maintainability and code compartmentalization, it's best to use composition. The entity component system allows just that. For the sake of keeping this short and sweet, we're not going to be delving too deep into the implementation. This is simply a quick overview for the sake of being familiar with the code that will be used down the line.

The ECS pattern consists of three cornerstones that make it possible: entities, components, and systems. An entity, ideally, is simply an identifier, as basic as an integer. Components are containers of data that have next to no logic inside them. There would be multiple types of components, such as position, movable, drawable, and so on, that don't really mean much by themselves, but when composed, will form complex entities. Such composition would make it incredibly easy to save the state of any entity at any given time.

There are many ways to implement components. One of them is simply having a base component class, and inheriting from it:

class C_Base{ 
public: 
  C_Base(const Component& l_type): m_type(l_type){} 
  virtual ~C_Base(){} 
 
  Component GetType() const { return m_type; } 
 
  friend std::stringstream& operator >>( 
    std::stringstream& l_stream, C_Base& b) 
    { 
      b.ReadIn(l_stream); 
      return l_stream; 
    } 
 
  virtual void ReadIn(std::stringstream& l_stream) = 0; 
protected: 
  Component m_type; 
}; 

The Component type is simply an enum class that lists different types of components we can have in a project. In addition to that, this base class also offers a means of filling in component data from a string stream, in order to load them more easily when files are being read.

In order to properly manage sets of components that belong to entities, we would need some sort of manager class:

class EntityManager{ 
public: 
  EntityManager(SystemManager* l_sysMgr, 
    TextureManager* l_textureMgr); 
  ~EntityManager(); 
 
  int AddEntity(const Bitmask& l_mask); 
  int AddEntity(const std::string& l_entityFile); 
  bool RemoveEntity(const EntityId& l_id); 
 
  bool AddComponent(const EntityId& l_entity, 
    const Component& l_component); 
 
  template<class T> 
  void AddComponentType(const Component& l_id) { ... } 
 
  template<class T> 
  T* GetComponent(const EntityId& l_entity, 
    const Component& l_component){ ... } 
 
  bool RemoveComponent(const EntityId& l_entity, 
    const Component& l_component); 
  bool HasComponent(const EntityId& l_entity, 
    const Component& l_component) const; 
  void Purge(); 
private: 
  ... 
}; 

As you can see, this is a fairly basic approach at managing these sets of data we call entities. The EntityId data type is simply a type definition for an unsigned integer. Creation of components happens by utilizing a factory pattern, lambdas and templates. This class is also responsible for loading entities from files that may look a little like this:

Name Player 
Attributes 255 
|Component|ID|Individual attributes| 
Component 0 0 0 1 
Component 1 Player 
Component 2 0 
Component 3 128.0 1024.0 1024.0 1 
Component 4 
Component 5 20.0 20.0 0.0 0.0 2 
Component 6 footstep:1,4 
Component 7 

The Attributes field is a bit mask, the value of which is used to figure out which component types an entity has. The actual component data is stored in this file as well, and later loaded through the ReadIn method of our component base class.

The last piece of the puzzle in ECS design is systems. This is where all of the logic happens. Just like components, there can be many types of systems responsible for collisions, rendering, movement, and so on. Each system must inherit from the system's base class and implement all of the pure virtual methods:

class S_Base : public Observer{ 
public: 
  S_Base(const System& l_id, SystemManager* l_systemMgr); 
  virtual ~S_Base(); 
 
  bool AddEntity(const EntityId& l_entity); 
  bool HasEntity(const EntityId& l_entity) const; 
  bool RemoveEntity(const EntityId& l_entity); 
 
  System GetId() const; 
 
  bool FitsRequirements(const Bitmask& l_bits) const; 
  void Purge(); 
 
  virtual void Update(float l_dT) = 0; 
  virtual void HandleEvent(const EntityId& l_entity, 
    const EntityEvent& l_event) = 0; 
protected: 
  ... 
}; 

Systems have signatures of components they use, as well as a list of entities that meet the requirements of said signatures. When an entity is being modified by the addition or removal of a component, every system runs a check on it in order to add it to or remove it from itself. Note the inheritance from the Observer class. This is another pattern that aids in communication between entities and systems.

An Observer class by itself is simply an interface with one purely virtual method that must be implemented by all derivatives:

class Observer{ 
public: 
  virtual ~Observer(){} 
  virtual void Notify(const Message& l_message) = 0; 
}; 

It utilizes messages that get sent to all observers of a specific target. How the derivative of this class reacts to the message is completely dependent on what it is.

Systems, which come in all shapes and sizes, need to be managed just as entities do. For that, we have another manager class:

class SystemManager{ 
public: 
  ... 
  template<class T> 
  void AddSystem(const System& l_system) { ... } 
 
  template<class T> 
  T* GetSystem(const System& l_system){ ... } 
  void AddEvent(const EntityId& l_entity, const EventID& l_event); 
 
  void Update(float l_dT); 
  void HandleEvents(); 
  void Draw(Window* l_wind, unsigned int l_elevation); 
 
  void EntityModified(const EntityId& l_entity, 
    const Bitmask& l_bits); 
  void RemoveEntity(const EntityId& l_entity); 
   
  void PurgeEntities(); 
  void PurgeSystems(); 
private: 
  ... 
  MessageHandler m_messages; 
}; 

This too utilizes the factory pattern, in that types of different classes are registered by using templates and lambdas, so that they can be constructed later, simply by using a System data type, which is an enum class. Starting to see the pattern?

The system manager owns a data member of type MessageHandler. This is another part of the observer pattern. Let us take a look at what it does:

class MessageHandler{ 
public: 
  bool Subscribe(const EntityMessage& l_type, 
    Observer* l_observer){ ... } 
  bool Unsubscribe(const EntityMessage& l_type, 
    Observer* l_observer){ ... } 
  void Dispatch(const Message& l_msg){ ... } 
private: 
  Subscribtions m_communicators; 
}; 

Message handlers are simply collections of Communicator objects, as shown here:

using Subscribtions = 
  std::unordered_map<EntityMessage,Communicator>; 

Each possible type of EntityMessage, which is just another enum class, is tied to a communicator that is responsible for sending out a message to all of its observers. Observers can subscribe to or unsubscribe from a specific message type. If they are subscribed to said type, they will receive the message when the Dispatch method is invoked.

The Communicator class itself is fairly simple:

class Communicator{ 
public: 
  virtual ~Communicator(){ m_observers.clear(); } 
  bool AddObserver(Observer* l_observer){ ... } 
  bool RemoveObserver(Observer* l_observer){ ... } 
  bool HasObserver(const Observer* l_observer) const { ... } 
  void Broadcast(const Message& l_msg){ ... } 
private: 
  ObserverContainer m_observers; 
}; 

As you can gather, it supports the addition and removal of observers, and offers a way to broadcast a message to all of them. The actual container of observers is simply a vector of pointers:

// Not memory-owning pointers. 
using ObserverContainer = std::vector<Observer*>; 
Left arrow icon Right arrow icon
Download code icon Download Code

Key benefits

  • Build custom tools, designed to work with your specific game.
  • Use raw modern OpenGL and go beyond SFML.
  • Revamp your code for better structural design, faster rendering, and flashier graphics.
  • Use advanced lighting techniques to add that extra touch of sophistication.
  • Implement a very fast and efficient particle system by using a cache-friendly design.

Description

SFML is a cross-platform software development library written in C++ with bindings available for many programming languages. It provides a simple interface to the various components of your PC, to ease the development of games and multimedia applications. This book will help you become an expert of SFML by using all of its features to its full potential. It begins by going over some of the foundational code necessary in order to make our RPG project run. By the end of chapter 3, we will have successfully picked up and deployed a fast and efficient particle system that makes the game look much more ‘alive’. Throughout the next couple of chapters, you will be successfully editing the game maps with ease, all thanks to the custom tools we’re going to be building. From this point on, it’s all about making the game look good. After being introduced to the use of shaders and raw OpenGL, you will be guided through implementing dynamic scene lighting, the use of normal and specular maps, and dynamic soft shadows. However, no project is complete without being optimized first. The very last chapter will wrap up our project by making it lightning fast and efficient.

Who is this book for?

This book is ideal for game developers who have some basic knowledge of SFML and also are familiar with C++ coding in general. No knowledge of OpenGL or even more advanced rendering techniques is required. You will be guided through every bit of code step by step.

What you will learn

  • Dive deep into creating complex and visually stunning games using SFML, as well as advanced OpenGL rendering and shading techniques
  • Build an advanced, dynamic lighting and shadowing system to add an extra graphical kick to your games and make them feel a lot more dynamic
  • Craft your own custom tools for editing game media, such as maps, and speed up the process of content creation
  • Optimize your code to make it blazing fast and robust for the users, even with visually demanding scenes
  • Get a complete grip on the best practices and industry grade game development design patterns used for AAA projects

Product Details

Country selected
Publication date, Length, Edition, Language, ISBN-13
Publication date : Jan 30, 2017
Length: 442 pages
Edition : 1st
Language : English
ISBN-13 : 9781786466846
Languages :
Tools :

What do you get with eBook?

Product feature icon Instant access to your Digital eBook purchase
Product feature icon Download this book in EPUB and PDF formats
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
OR
Modal Close icon
Payment Processing...
tick Completed

Billing Address

Product Details

Publication date : Jan 30, 2017
Length: 442 pages
Edition : 1st
Language : English
ISBN-13 : 9781786466846
Languages :
Tools :

Packt Subscriptions

See our plans and pricing
Modal Close icon
$19.99 billed monthly
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Simple pricing, no contract
$199.99 billed annually
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Choose a DRM-free eBook or Video every month to keep
Feature tick icon PLUS own as many other DRM-free eBooks or Videos as you like for just $5 each
Feature tick icon Exclusive print discounts
$279.99 billed in 18 months
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Choose a DRM-free eBook or Video every month to keep
Feature tick icon PLUS own as many other DRM-free eBooks or Videos as you like for just $5 each
Feature tick icon Exclusive print discounts

Frequently bought together


Stars icon
Total $ 147.97
Mastering SFML Game Development
$48.99
SFML Game Development By Example
$54.99
SFML Blueprints
$43.99
Total $ 147.97 Stars icon

Table of Contents

10 Chapters
1. Under the Hood - Setting up the Backend Chevron down icon Chevron up icon
2. Its Game Time! - Designing the Project Chevron down icon Chevron up icon
3. Make It Rain! - Building a Particle System Chevron down icon Chevron up icon
4. Have Thy Gear Ready - Building Game Tools Chevron down icon Chevron up icon
5. Filling the Tool Belt - a few More Gadgets Chevron down icon Chevron up icon
6. Adding Some Finishing Touches - Using Shaders Chevron down icon Chevron up icon
7. One Step Forward, One Level Down - OpenGL Basics Chevron down icon Chevron up icon
8. Let There Be Light - An Introduction to Advanced Lighting Chevron down icon Chevron up icon
9. The Speed of Dark - Lighting and Shadows Chevron down icon Chevron up icon
10. A Chapter You Shouldnt Skip - Final Optimizations Chevron down icon Chevron up icon

Customer reviews

Rating distribution
Full star icon Empty star icon Empty star icon Empty star icon Empty star icon 1
(1 Ratings)
5 star 0%
4 star 0%
3 star 0%
2 star 0%
1 star 100%
Kamal johnson Dec 06, 2017
Full star icon Empty star icon Empty star icon Empty star icon Empty star icon 1
the price on the book is only 599Rs but the price on amazon is 1079Rsthe quality of the book is also very low.
Amazon Verified review Amazon
Get free access to Packt library with over 7500+ books and video courses for 7 days!
Start Free Trial

FAQs

How do I buy and download an eBook? Chevron down icon Chevron up icon

Where there is an eBook version of a title available, you can buy it from the book details for that title. Add either the standalone eBook or the eBook and print book bundle to your shopping cart. Your eBook will show in your cart as a product on its own. After completing checkout and payment in the normal way, you will receive your receipt on the screen containing a link to a personalised PDF download file. This link will remain active for 30 days. You can download backup copies of the file by logging in to your account at any time.

If you already have Adobe reader installed, then clicking on the link will download and open the PDF file directly. If you don't, then save the PDF file on your machine and download the Reader to view it.

Please Note: Packt eBooks are non-returnable and non-refundable.

Packt eBook and Licensing When you buy an eBook from Packt Publishing, completing your purchase means you accept the terms of our licence agreement. Please read the full text of the agreement. In it we have tried to balance the need for the ebook to be usable for you the reader with our needs to protect the rights of us as Publishers and of our authors. In summary, the agreement says:

  • You may make copies of your eBook for your own use onto any machine
  • You may not pass copies of the eBook on to anyone else
How can I make a purchase on your website? Chevron down icon Chevron up icon

If you want to purchase a video course, eBook or Bundle (Print+eBook) please follow below steps:

  1. Register on our website using your email address and the password.
  2. Search for the title by name or ISBN using the search option.
  3. Select the title you want to purchase.
  4. Choose the format you wish to purchase the title in; if you order the Print Book, you get a free eBook copy of the same title. 
  5. Proceed with the checkout process (payment to be made using Credit Card, Debit Cart, or PayPal)
Where can I access support around an eBook? Chevron down icon Chevron up icon
  • If you experience a problem with using or installing Adobe Reader, the contact Adobe directly.
  • To view the errata for the book, see www.packtpub.com/support and view the pages for the title you have.
  • To view your account details or to download a new copy of the book go to www.packtpub.com/account
  • To contact us directly if a problem is not resolved, use www.packtpub.com/contact-us
What eBook formats do Packt support? Chevron down icon Chevron up icon

Our eBooks are currently available in a variety of formats such as PDF and ePubs. In the future, this may well change with trends and development in technology, but please note that our PDFs are not Adobe eBook Reader format, which has greater restrictions on security.

You will need to use Adobe Reader v9 or later in order to read Packt's PDF eBooks.

What are the benefits of eBooks? Chevron down icon Chevron up icon
  • You can get the information you need immediately
  • You can easily take them with you on a laptop
  • You can download them an unlimited number of times
  • You can print them out
  • They are copy-paste enabled
  • They are searchable
  • There is no password protection
  • They are lower price than print
  • They save resources and space
What is an eBook? Chevron down icon Chevron up icon

Packt eBooks are a complete electronic version of the print edition, available in PDF and ePub formats. Every piece of content down to the page numbering is the same. Because we save the costs of printing and shipping the book to you, we are able to offer eBooks at a lower cost than print editions.

When you have purchased an eBook, simply login to your account and click on the link in Your Download Area. We recommend you saving the file to your hard drive before opening it.

For optimal viewing of our eBooks, we recommend you download and install the free Adobe Reader version 9.