Book Image

Mastering SFML Game Development

By : Raimondas Pupius
Book Image

Mastering SFML Game Development

By: Raimondas Pupius

Overview of this book

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.
Table of Contents (17 chapters)
Mastering SFML Game Development
Credits
About the Author
About the Reviewer
www.PacktPub.com
Customer Feedback
Preface

Adapting the light pass


With the shadow maps rendered, it may be extremely tempting to try and sample them in our existing code, since the hard part is over, right? Well, not entirely. While we were extremely close with our previous approach, sadly, sampling of cubemap textures is the only thing that we couldn't do because of SFML. The sampling itself isn't really the problem, as much as binding the cubemap textures to be sampled is. Remember that sampling is performed by setting a uniform value of the sampler inside the shader to the texture unit ID that's bound to the texture in our C++ code. SFML resets these units each time something is rendered either onscreen, or to a render texture. The reason we haven't had this problem before is because we can set the uniforms of the shaders through SFML's sf::Shader class, which keeps track of references to textures and binds them to appropriate units when a shader is used for rendering. That's all fine and good, except for when the time comes...