Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon

Game From Scratch C++ Edition Part 3



So, now we have a functioning game loop and a screen to draw on, lets add some more functionality.  This time we are going to add a menu and a welcome splash screen.  We are going to take a consistent approach in that all “screens” are in charge of handling their own input.


Alright, lets start with adding a SplashScreen for when you start the game.  First off all, you are going to need an image to display as the splash screen.  Keep in mind the game is running at a fixed resolution of 1024x768, so ideally you want to make an image that size.  It is outside of the scope of this tutorial to create that image, but after playing around in Blender for a couple of minutes, I came up with this:



Click here to download full size version of SplashScreen.png


… what can I say, I am a programmer.  You can use this image or create your own it really doesn’t matter, although to follow along with the code, name it SplashScreen.png if you do decide to create your own.  Now that we have our image, lets write some code.


First create a new header file in the Header Files folder named SplashScreen.h.  Now add the following code:


1 #pragma once 2 class SplashScreen 3 { 4 public: 5 void Show(sf::RenderWindow& window); 6 }; 7

Click here to download SplashScreen.h


Simple enough right?  After the last section, there should be nothing new here.  We are simply creating a class called SplashScreen with a single public function Show(), which takes a RenderWindow as a parameter.  Save your changes.



Now we want to create SplashScreen.cpp in the Source Files folder.  Once created, add the following code:

1 #include "StdAfx.h" 2 #include "SplashScreen.h" 3 4 5 void SplashScreen::Show(sf::RenderWindow & renderWindow) 6 { 7 sf::Image image; 8 if(image.LoadFromFile("images/SplashScreen.png") != true) 9 { 10 return; 11 } 12 13 sf::Sprite sprite(image); 14 15 renderWindow.Draw(sprite); 16 renderWindow.Display(); 17 18 sf::Event event; 19 while(true) 20 { 21 while(renderWindow.GetEvent(event)) 22 { 23 if(event.Type == sf::Event::EventType::KeyPressed 24 || event.Type == sf::Event::EventType::MouseButtonPressed 25 || event.Type == sf::Event::EventType::Closed ) 26 { 27 return; 28 } 29 } 30 } 31 }

Click here to download Splashscreen.cpp


This code is also pretty straight forward.  First thing we do is load the splashscreen image from disk and simply return if it doesn’t exist, meaning of course nothing will be shown.  With SFML an image is not seen on screen, that is the job of a sprite.  An image represents the actual pixel data from a file, but a sprite represents displaying that information on screen.  Why, you might wonder would you bother creating two different classes?  Mostly because you could have multiple sprites using the same image.  For example, our game is going to have at least two paddles, but we are going to use only a single image.  Also, in the case of a sprite sheet you often have multiple images in a single image file.


One the sprite is loaded, we simply draw it to the screen.  We don’t need to worry about coordinates because the sprite and the renderWindow are the same size.  Next we simply call RenderWindow.Display() which displays our image on screen.


As I said earlier, all windows are responsible for their own event handling, which exactly what happens starting on line 18.  On 19 we declare an infinite loop, then each pass through we check for available events and if the user presses a key, clicks a mouse or closes the window we exit the function, thus closing the splash screen window.


The main menu works very similarly but has a couple of key differences.  The menu is essentially just an image that is displayed similar to the splash screen.  Let’s take a look at it now.  Create a file called MainMenu.h ( note, you can use Add Class because MainMenu is a reserved class name in MFC… again, stupid bug. ) and add the following code:


1 #pragma once 2 #include "SFML/Window.hpp" 3 #include "SFML/Graphics.hpp" 4 #include <list> 5 6 class MainMenu 7 { 8 9 public: 10 enum MenuResult { Nothing, Exit, Play }; 11 12 struct MenuItem 13 { 14 public: 15 sf::Rect<int> rect; 16 MenuResult action; 17 }; 18 19 MenuResult Show(sf::RenderWindow& window); 20 21 private: 22 MenuResult GetMenuResponse(sf::RenderWindow& window); 23 MenuResult HandleClick(int x, int y); 24 std::list<MenuItem> _menuItems; 25 };

Click here to download MainMenu.h


First thing you may ask is “Why isn’t <list> declared in stdafx?”.  The answer is, you’re right, it should be.  As you know from earlier, any header file you include but aren’t actively being changed should be included in stdafx to accelerate the build process.  For sample code purposes though, it was better to show it included locally instead of having to show stdafx.h over and over.


MainMenu is a fairly straight forward class.  First off it defines an enum type that contains the various possible return values the menu could return.  Next it declares a struct called MenuItem that represents the individual menu items in the menu.  This struct is exceedingly simple, containing a sf::Rect<int> that represents the dimensions of the MenuItem. It also contains a MenuResult enum presenting the value to return if that MenuItem is clicked.



Optional information


What's with the <int> ???

You may have just encountered your first line of templated code. In MainMenu.h we declared:
sf::Rect<int> rect;
sf::Rect is a templated class.  In this case we are declaring an instance of sf::Rect using the type of int.  In place of int we could have used many other numeric data types, such as float or double or even your own class, as long as it supported all of the operators that sf::Rect requires.
In essence, templates allow a class such as sf::Rect to become more generic by removing the requirement of them to know about the datatype they are operating on.  So instead of having to for example, implement three Add() methods for eac int, float and double, they can simply write one.
This is an extremely simple and incomplete explanation of templates.  Templates are of extreme importance to C++ and are becoming more and more important with every revision, so it is a very good idea to familiarize yourself with how they work.  Such a discussion is well beyond the scope of this work, so you may wish to consult a site such as this or consult a book such as  C++ Templates The Complete Guide, an excellent book on the subject.
You should be able to make it through this tutorial with minimal knowledge of templates, but if you are going to become proficient in C++, it is an area you will need to know extremely well.



Next MainMenu declares a single public function Show() that returns a MenuResult enum type.  Finally are the private functions and data.  GetMenuResponse() is used internally and will be explained shortly, as is HandleClick().  The last line item is a list of type MenuItem, which will hold the various MenuItems that compose MainMenu.  std::list is a templated class from the Standard Template Library.  If you are unfamiliar with STL, you should rectify that as soon as you get the chance.  There are some good book and link suggestions for learning C++ in the C++ section of the Beginners Guide if you wish to learn more.



That’s about it for MainMenu.h.  Most of this will make more sense in a few minutes.  I thought I would take a moment to explain something about the design of MainMenu, the nested structs/enums.  You may be wondering why I nested the definition of MenuItem and MenuResult inside of MainMenu and the simple answer is because they belong to MainMenu, so we want to scope them within MainMenu.  Truth of the matter is, those items are of absolutely no use when not dealing with MainMenu, so there is no sense polluting the global namespace with a number of classes with no use to anything but a MainMenu object.  This is a key aspect of object oriented programming, encapsulation.



This leads to another conversation, the design of MainMenu itself.  Don’t menus share enough functionality they should derive from a common base class and a generic MenuItem class that isn’t specific to a specific type of menu?  The answer is very much yes!  In your own game, if you have multiple menus this is exactly what you would want to do.  In the case of Pang however, we are only going to have a single menu, so I went this route in order to keep the code smaller/easier to understand.  Don’t worry, later in the tutorial we will cover inheritance in more detail.



Optional information


Why a struct?

You may have noticed that MenuItem is a struct instead of a class and may wonder why that is.  The simple answer is, it just as easily could have been a class, but struct is a slightly better choice.
First off, the biggest difference between a class and a struct is that a class defaults to private while a struct defaults to public.  Since MenuItem contains entirely public members, choosing struct saves a bit of typing “public: “.
The second reason is more a convention thing, but is no less important, especially if you are dealing with other coders.  When dealing with fully publicly available POD types ( Plain Old Data ) that has no member functions, the norm is to use struct.  Finally it is common to use struct for functors but you can forget about that for now, we will cover it later.  There are some advantages to POD types ( like no vtables ) but they are well beyond the scope of what we are dealing with and are generally an example of premature optimization.
In short, you could have used class instead and been just as right, struct was just a slightly better fit.


Now let’s implement MainMenu.  Create a new file called MainMenu.cpp and add the following code:


1 #include "stdafx.h" 2 #include "MainMenu.h" 3 4 5 MainMenu::MenuResult MainMenu::Show(sf::RenderWindow& window) 6 { 7 8 //Load menu image from file 9 sf::Image image; 10 image.LoadFromFile("images/mainmenu.png"); 11 sf::Sprite sprite(image); 12 13 //Setup clickable regions 14 15 //Play menu item coordinates 16 MenuItem playButton; 17 playButton.rect.Top= 145; 18 playButton.rect.Bottom = 380; 19 playButton.rect.Left = 0; 20 playButton.rect.Right = 1023; 21 playButton.action = Play; 22 23 //Exit menu item coordinates 24 MenuItem exitButton; 25 exitButton.rect.Left = 0; 26 exitButton.rect.Right = 1023; 27 exitButton.rect.Top = 383; 28 exitButton.rect.Bottom = 560; 29 exitButton.action = Exit; 30 31 _menuItems.push_back(playButton); 32 _menuItems.push_back(exitButton); 33 34 window.Draw(sprite); 35 window.Display(); 36 37 return GetMenuResponse(window); 38 } 39 40 MainMenu::MenuResult MainMenu::HandleClick(int x, int y) 41 { 42 std::list<MenuItem>::iterator it; 43 44 for ( it = _menuItems.begin(); it != _menuItems.end(); it++) 45 { 46 sf::Rect<int> menuItemRect = (*it).rect; 47 if( menuItemRect.Bottom > y 48 && menuItemRect.Top < y 49 && menuItemRect.Left < x 50 && menuItemRect.Right > x) 51 { 52 return (*it).action; 53 } 54 } 55 56 return Nothing; 57 } 58 59 MainMenu::MenuResult MainMenu::GetMenuResponse(sf::RenderWindow& window) 60 { 61 sf::Event menuEvent; 62 63 while(true) 64 { 65 66 while(window.GetEvent(menuEvent)) 67 { 68 if(menuEvent.Type == sf::Event::MouseButtonPressed) 69 { 70 return HandleClick(menuEvent.MouseButton.X,menuEvent.MouseButton.Y); 71 } 72 if(menuEvent.Type == sf::Event::Closed) 73 { 74 return Exit; 75 } 76 } 77 } 78 }

Click here to download MainMenu.cpp


This code is fairly long, but not very complex.  First off we implement Show(), which is very similar to SplashScreen from before.  We load an image file “mainmenu.png” from the images folder and create a sprite to display it.  Next we create two MenuItem’s, which correspond with the location of their buttons physical locations within the mainmenu.png image file.  Lastly, each MenuItem has an action, which is represented by the MenuResult enum we described earlier.




Click here to download MainMenu.png


After defining the location rects and action type of both MenuItems, we then add them to the _menuItems list using push_back(), which adds to an item to a list in the final position.  Next we draw our menu image to screen and tell the display to Display() just like we did in Splashscreen.  Finally, we call the function GetMenuResponse, returning it’s return value as Show’s return value.


GetMenuResponse() is the event loop for MainMenu.  It works just like our other two eventloops, except it only handles sf::Event::Closed and sf::Event::MouseButtonPressed.  In the event of close, it returns a value of MenuResult::Exit.  In the event of a button press, it passed the coordinates into HandleClick() returning it’s results.


HandleClick() is a very simple method that might look very confusing to you if you are new to STL datatypes.  First off, it declares an iterator, which is a datatype used for navigating through a collection of data.  In the for loop the iterator “it” is initially assigned a location of _menuItems.begin() which is the first element in the list.  Each pass through, the iterator’s ++ operator is called, which moves to the next item in the list, until the iterators location is equal to _menuItems.end().  One thing than can be a bit tricky is List.end() refers to a value past the end of the list, not to the last item in the list.  Think of .end() like you would a file’s EOF.  It does not represent a value, but instead the end of available values. 


Iterators also represent a pointer to the underlying datatype contained within the list<>.  Therefore when we dereference it ( using    (*it)  ) it contains a MenuItem type.  We then check to see if the click location is within the MenuItem’s rect.  If in fact the click was within MenuItem’s rect, we return the action (MenuResult). 



Lastly, we need to make a few changes to Game.h and Game.cpp, which will illustrate the power of using a state driven game structure. 


Change Game.h to contain the following:

1 #pragma once 2 #include "SFML\Window.hpp" 3 #include "SFML\Graphics.hpp" 4 5 6 class Game 7 { 8 public: 9 static void Start(); 10 11 private: 12 static bool IsExiting(); 13 static void GameLoop(); 14 15 static void ShowSplashScreen(); 16 static void ShowMenu(); 17 18 enum GameState { Uninitialized, ShowingSplash, Paused, 19 ShowingMenu, Playing, Exiting }; 20 21 static GameState _gameState; 22 static sf::RenderWindow _mainWindow; 23 };

Click here to download Game.h


The only changes we made here were the two next new functions on line 15 and 16, as well as the two new states on lines 18 and 19. The purpose of these changes will be explained in a moment.


In Game.cpp, we want to edit Game::Start() to look like:

1 void Game::Start(void) 2 { 3 if(_gameState != Uninitialized) 4 return; 5 6 _mainWindow.Create(sf::VideoMode(1024,768,32),"Pang!"); 7 8 _gameState= Game::ShowingSplash; 9 10 while(!IsExiting()) 11 { 12 GameLoop(); 13 } 14 15 _mainWindow.Close(); 16 }


The only real change here is line 8.  This simply sets the state to ShowingSplash when the game starts up.  Next up we just add two new states to Game::GameLoop, as follows:

1 void Game::GameLoop() 2 { 3 switch(_gameState) 4 { 5 case Game::ShowingMenu: 6 { 7 ShowMenu(); 8 break; 9 } 10 case Game::ShowingSplash: 11 { 12 ShowSplashScreen(); 13 break; 14 } 15 case Game::Playing: 16 { 17 sf::Event currentEvent; 18 while(_mainWindow.GetEvent(currentEvent)) 19 { 20 _mainWindow.Clear(sf::Color(sf::Color(0,0,0))); 21 _mainWindow.Display(); 22 23 if(currentEvent.Type == sf::Event::Closed) _gameState = 24 Game::Exiting; 25 26 if(currentEvent.Type == sf::Event::KeyPressed) 27 { 28 if(currentEvent.Key.Code == sf::Key::Escape) ShowMenu(); 29 } 30 } 31 break; 32 } 33 } 34 }



All that we add here are the Game::ShowingMenu and ShowingSplash case handlers, which call ShowMenu() and ShowSplash() respectively.  They are defined as:



1 void Game::ShowSplashScreen() 2 { 3 SplashScreen splashScreen; 4 splashScreen.Show(_mainWindow); 5 _gameState = Game::ShowingMenu; 6 } 7 8 void Game::ShowMenu() 9 { 10 MainMenu mainMenu; 11 MainMenu::MenuResult result = mainMenu.Show(_mainWindow); 12 switch(result) 13 { 14 case MainMenu::Exit: 15 _gameState = Game::Exiting; 16 break; 17 case MainMenu::Play: 18 _gameState = Game::Playing; 19 break; 20 } 21 }

Click here to download Game.cpp


Game::ShowSplashScreen() simply creates a SplashScreen object, calls its Show() method, then sets the game state to Showing Menu.  Game::ShowMenu() creates a MainMenu object and calls it’s Show() method.  In this case, it takes the returned MenuResults value and sets the game’s state accordingly.  This is how we handle the progression from state to state within our game. 



Pang running now:





Click any key or mouse button to get past the splash screen, then in the menu click either “Exit Game” to um… exit.   That’s it for now.  In the next section we will work a bit more with graphics and delve a little deeper into object oriented programming.


You can download a completely updated project here.



Back to Part Two Forward to Part Four

blog comments powered by Disqus

Popular Comments

Guest Tutorial: Creating a mobile game using the Moscrif SDK
Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon

30. October 2012

 The following is a guest tutorial post written by Michael Habalcik on using the freely available Moscrif game development suite to create a simple mobile game.  I hope you find it informative.




Balloons game demo in Moscrif SDK


We are proud to present one of very first tutorials about “a new kid on the block”. Moscrif is the new member of cross-platform development tools suited for a modern mobile game developer.


Moscrif overview

Moscrif SDK is a development suite solving the problem of supporting an increasing number of mobile platforms. The number of these platforms is increasing making it almost impossible to go native for every one of these. With Moscrif, only one development cycle is needed allowing you to publish the game to the most popular platforms. With the current support of iOS, Android, Nook or Kindle you can reach up to 80% of the mobile market audience. New Windows Phone should be supported in the near future reaching even more mobile users.


The key advantage is the need of just one code base. Because Moscrif uses JavaScript, it is extremely easy to adopt for experienced developers as well as for beginners because JavaScript is one of the easiest languages to learn with a countless number of tutorials all over the net.


Other benefits:


      Graphics performance - Moscrif applications are able to achieve 50 frames per seconds (one of the bests in the industry)

      Hardware acceleration – the amazing graphics performance is achieved with the contribution of fully OpenGL hardware acceleration

      Code one, run anywhere – the only one code of application can run on almost 90% of devices

      Reuse your knowledge – Moscrif uses JavaScript language which makes no problem for everybody who has ever developed web application or desktop applications in C, C++, Java etc.

      Publish on your own computer in few seconds – some other cross platform tools requires sending the source codes to theirs servers and publishing process sends some hours. Moscrif makes it on your own computer in few seconds.

      Free license - Moscrif is one of only few similar tools offering a free license

      IDE - Moscrif comes with its own IDE which is a part of the SDK


The Moscrif is available for free download on its homepage


The balloon game demo


To present the capabilities of Moscrif, we have created a simple game demo based on shooting down the balloons. This game contains only one level and simple game menu, but with only few additional lines of code it can be transferred into a full game ready to hit the app stores.

NewImage NewImage


Starting a new project


To create the project the Project wizard (click File -> New -> New project) will be used. We have selected the new 2D Game option as it is exactly what we are looking for.


New Project

In the next step we set few of the most basic project’s properties like the landscape orientation. We have also checked the box2d library to be added into the project. As we are interested in some basic game menu as well, the option called Screens select Game with Menu is checked as well.



In the next step we set few of the most basic project’s properties like the landscape orientation. We have also checked the box2d library to be added into the project. As we are interested in some basic game menu as well, the option called Screens select The wizard will create a new project with three precreated scenes: menu, single and multiPlayer.


In this sample we are only going to use a single player mode. Therefore, we need only 2 scenes - one for the menu and one for the game itself. So you can delete the multi player scene (remove also the include command in file). Game with Menu is checked as well.The wizard will create a new project with three precreated scenes: menu, single and multiPlayer. In this sample we are only going to use a single player mode. Therefore, we need only 2 scenes - one for the menu and one for the game itself. So you can delete the multi player scene (remove also the include command in file).


The whole game code will be in singlePlayerScene file, so we open it for editing. As seen on the example below, our scene class is extended from the PhysicsScene base class. The Scene base class creates a basic scene without the support of physical engine. Because Scene class is not sufficient for use as we need the support of physics engine, we use PhysicsScene class instead.


Following, a new instance of b2World object is created in the init method taking 4 parameters:


1      gravity on the x axis

2      gravity on the y axis

3      true/false doSleep parameter. We use True to improve the performance

4      true/false allowing the collisions between the objects within the scene


We set the gravity on the y axis to -9.81 what is equivalent of real earth’s gravity.


Example: applying physical engine in the scene


class SinglePlayerScene : PhysicsScene


    // constants

    const maxForce = 2000;

    const forceStep = 0.1;

    const maxDistance = 3*System.height / 5;

    function init()

        this.start = System.tick; = new b2World(0.0, -9.81, true, true);



Physical engine


To simulate the real world’s behavior Moscrif relies on powerful box2d physical engine. This engine is used by many platforms and many well known games rely on it like: Crayon Physics Deluxe, Limbo, Rolando, Fantastic Contraption, Incredibots, Angry Birds etc.


The main part of the physical engine is the world which consists of the bodies and the joints. It manages all aspects of the simulation and contacts between the bodies. Bodies interact together according to theirs properties which specify the density, friction and/or bounce.


The engine supports three different types of the bodies, which behaves differently. Static bodies do not move under the simulation and collide with dynamic bodies. The dynamic bodies are fully simulated and collide with all other bodies. The last, kinematic bodies do not move under the forces, only according to its velocity. They interact only with dynamic bodies. In Moscrif, bodies are created as an instance of PhysicsSprite class or class extended from the PhysicsSprite class. The position of bodies and collisions are recalculated in small time intervals.


Example: making a time step in physics simulation


function process()


    // timestep in physics simulation

    var timeStep = 1.0 / 40.0;

    // recalculate physics world. All objects are moved about timeStep

    this.step(timeStep, 4, 8);




The Balloons


Balloons are managed by their own class extended from the PhysicsSprite class. Every balloon is made of several frames that are changed every 100 milliseconds creating a simple and realistic animation. When a balloon reaches the top of the screen an end event is raised.


Image: balloons frames





Example: creating the balloon class


class Balloon : PhysicsSprite


    function init()




        // set image with frames

        this.image = GFX.ballon;

        // set frame dimension

        this.frameWidth = GFX.ballon.width / 5;

        this.frameHeight = GFX.ballon.height;


        // start timer

        this.timer = new Timer(100, true);

        this.timer.onTick = function()


            // move to next frame

            if (this super.frame == 4/*number of frmes*/)

                this super.frame = 0;


                this super.frame+=1;


            // check if the balloon does not passed the top of the screen

            var (x, y) = this super.getPosition();

            if (y < 0)

                this super._endHandler(this super);

            // speedup

            this super.setLinearVelocity(0, this super.getLinearVelocity() + 0.07);





    // end level event

    property end(v)


        get return this._endHandler;

        set this._endHandler = v;




Balloons start from the random position at the bottom of the screen in time intervals.


function _setTimer(i = 1)


    this._timer = new Timer(1, 1);

    this._timer.onTick = function()


        // create ballon

        this super._createBallon(i);

        // decrease the time between two ballons

        if (this super._time > 200)

            this super._time -= 3;

        i += 0.1;

        this super._setTimer(i);






The Ball


The ball is fired from the bottom of the screen. The angle and force of the fire are controlled by the user touches on the screen. When user taps the screen the first angle and force is calculated. The force is calculated as a rate of distance of user’s touch from the ball’s start position and its max distance which is equal to the max force. The angle is calculated using the trigonometric function tangents as a rate of distance on y and x axis.


Example: calculating the force and angle


function pointerPressed(x, y)


    super.pointerPressed(x, y);


    if(this._ended) {





    // calculate distance on both axis

    var distanceX = x - System.width / 2;

    var distanceY = y - 9*System.height / 10;

    // calculate angle

    this._angle = Math.atan2(distanceY, distanceX);

    // total distance

    var distance = Math.sqrt(distanceX*distanceX + distanceY*distanceY);

    // max distance (max distance is distance which equal the max force)

    if (distance > maxDistance)

        distance = maxDistance;

    // calculate force

    this._force = (1.0*distance / maxDistance)*maxForce;



When user drags his finger the angle and force are recalculated in the same way as when he presses it. Finally, when user releases his finger the ball is fired.


Example: firing the ball


function _fire()


    // if can not fire do nothing

    if (!this._canFire)



    // add new ball

    this._ball = this.addCircleBody(GFX.ball, #dynamic, 1.0, 0.0, 0.0, GFX.ball.width / 2);

    this._ball.setPosition(System.width / 2, 9*System.height / 10); = #ball;

    this._ball.bullet = true;


    // start veloity of the ball acording to angle and force

    var velox = this._force*Math.cos(this._angle)/this.scale;

    var veloy =-this._force*Math.sin(this._angle)/this.scale;


    //apply velocity

    this._ball.setLinearVelocity(velox, veloy);


    // diable next fire

    this._canFire = false;

    // allow fire after 500ms

    var t = new Timer(1, 1);

    t.onTick = function ()


        this super._canFire = true;







When two bodies collide together a beginContact and endContact events are raised. The events have only one parameter – a list of all contacts in the world. Every record in the list contains information about both bodies of the contact (accessible by getBodyA and getBodyB methods).


Example: managing contacts


function beginContact(contact)


    var current = contact;

    while (current) {

        // get both bodies in contact

        var bodyA = current.getBodyA();

        var bodyB = current.getBodyB();

        // check if a ballon was hit

        if ( == #ball && == #ballon) {

            // destoy ballon


        // check if a ballon was hit

        } else if( == #ball && == #ballon) {

            // destoy ballon


        // check if something hit the border (only ball can)

        } else if( == #border) {


        } else if( == #border) {



        // get next body

        current = current.getNext();






As you can see, creating mobile games using Moscrif SDK is straightforward and even the beginners should be able to create a killer game. So are you going the make the new Angry Birds? It’s free, so why not to try it …


The source code of this sample can be found at


blog comments powered by Disqus

Month List

Popular Comments