- [Narrator] Hi, and welcome
to the last video of this section.
Extending SFML classes, particle systems and shaders.
In this section we will start with the SFML Drawable class.
Then we would move onto building a particle system.
And lastly we'll see OpenGl, shaders and GLSL.
Now, we move onto the first video of this section,
that deals with the SFML Drawable class.
In this video, we're going to take a look at
an alternative to inheriting from Drawable.
And why it is best to inherit from Drawable.
The Drawable class has just one function,
it has no variables either.
Furthermore its one and only function is pure virtual.
This means that if we inherit from Drawable
we must implement its one and only function.
The purpose of this is that we can then use our class.
Which inherits from Drawable, as a polymorphic type.
Put more simply, anything that SFML
allows us to do with a Drawable object
we will be able to do with our class that inherits from it.
The only requirement is that we must provide
a definition for the pure virtual function, draw.
Some classes that inherit from Drawable
already include Sprite and Vertex array, among others.
Whenever we have used Sprite or Vertex array
we have passed them to draw function
of the Render window class.
The reason that we've been able to draw
every object we've drawn in this course.
Is that they have all inherited from Drawable.
We can inherit from Drawable, with any object we like.
As long as we implement the pure virtual draw function.
This is also a straightforward process.
The header file SpaceShip.h
of a hypothetical SpaceShip class
that inherits from Drawable would look like this.
In this code we can see
the pure virtual draw function and a Sprite.
Notice there is no way to access the private Sprite
outside of the class, not even a get Sprite function.
The SpaceShip.cpp file would then look something like this.
In this code notice the simple implementation
of the draw function.
The parameters are beyond the scope of this course.
Just note, that the target parameter is used to call draw,
and passes in m_Sprite,
as well as states the other parameter.
Now, in the main game loop we could now treat
a SpaceShip instance as if it were a Sprite.
Or any class that inherits from Drawable.
It is because SpaceShip is a Drawable
that we can treat it like a Sprite or Vertex array.
And because we overrode the pure virtual draw function
everything just works as we want it to.
Let's look at an alternative way
of encapsulating the drawing code into the game object.
It is also possible to keep all the drawing functionality
within the class, that is the object to be drawn,
by implementing our own function within our class.
Perhaps like this.
This code assumes that m_Sprite represents
the visual appearance of the current class we are drawing.
As it has throughout this and the previous project.
Assuming that the instance of the class
that contains the draw.
This object function is called playerHero.
And further assuming we have an instance of Render window
called m_window we could then draw the object
from the main game loop with this line of code.
In this solution we pass the Render window
m_window into the draw this object function as a parameter.
The draw this object function then uses the Render window
to draw the Sprite m_Sprite.
This solution certainly seems simpler
than extending Drawable.
The reason we do things the way suggested,
extending Drawable isn't really of any great benefit
in its own right for this project.
The actual reason we will soon draw and need explosion
using this method is because
it is a good technique to learn.
With each project we have completed throughout the course
we have learnt more about games, C++ and SFML.
Possibly the biggest improvements we have made
from one game to the next is in the structure of our code.
The programming patterns that we have used.
Think about the idea for improving our code.
Imagine every object in our game is derived
from a single, simple, abstract base class.
Let's call it game object.
Game object would probably have concrete functions
for get position and others.
It would likely have a pure virtual update function,
because every object updates differently.
Furthermore consider that game object
inherits from Drawable.
Now look at this hypothetical code.
The code is a big step up in terms of encapsulation,
code manageability, and elegance
when compared to even this final project.
You will notice there are, however,
unanswered questions, such as where collision detection
fits in, for example.
Hopefully, however, you can see that further study
by building lots of games will be necessary to master C++.
Although we will not be implementing
an entire game in this manner.
We will see how we can design a class particle system
and pass it directly to m_Window.draw
m_myparticlesysteminstance.
Cool, that's about it.
In this video we've learnt about the SFML Drawable class.
Splendid.
Next up we'll see building a particle system.