A complete C++ game from scratch using SFML

Nice looking tutorial.
I took a quick look at chapter 4 and one thing that struck me was that each Visual object contains a sf::Image rather than a pointer/reference to a sf::Image.
Wouldn't it be a good idea to separate the images from that class, making it a "global" resource instead? Or at least explain for the reader that storing the image data in each visual object could become a waste of resources in the long run?

[quote name='pulpfist' timestamp='1315502665' post='4859122']
Nice looking tutorial.
I took a quick look at chapter 4 and one thing that struck me was that each Visual object contains a sf::Image rather than a pointer/reference to a sf::Image.
Wouldn't it be a good idea to separate the images from that class, making it a "global" resource instead? Or at least explain for the reader that storing the image data in each visual object could become a waste of resources in the long run?

I don't quite like your first introduction to classes. Also, I don't agree with your reasons to do so. Free functions are part of the a class's public interface in C++. If you don't need real class, then why not just use free functions. Free functions would be much softer landing for beginners.

You don't need to expose a singleton in header, nor global objects. If you need global access, just use free function which is global accessor.

Something like:

// Game.h
#pragma once

void StartGame();


// Game.cpp
#include "stdafx.h"
#include "Game.h"

enum GameState { Uninitialized, ShowingSplash, Paused,
ShowingMenu, Playing, Exiting };

GameState _gameState = Uninitialized;
sf::RenderWindow _mainWindow;

bool IsExiting()
{
if(_gameState == Exiting)
return true;
else
return false;
}

void GameLoop()
{
sf::Event currentEvent;
while(_mainWindow.GetEvent(currentEvent))
{

switch(_gameState)
{
case Playing:
{
_mainWindow.Clear(sf::Color(sf::Color(255, 0, 0)));
_mainWindow.Display();

if(currentEvent.Type == sf::Event::Closed)
{
_gameState = Exiting;
}
break;
}
}
}
}

void StartGame()
{
if(_gameState != Uninitialized)
return;

_mainWindow.Create(sf::VideoMode(1024, 768, 32),"Pang!");
_gameState = Playing;

while(!IsExiting())
{
GameLoop();
}

_mainWindow.Close();
}


I mean maybe it's not good to first teach everyone to use statics (or globals), then tell them to unlearn it when projects grow bigger and they run into problems. IMO all static and global instances belong into cpp file in C++, it's easier to get rid of them later.

Also I'm somewhat against private member functions. I'd rather like to see them as free functions (in anonymous namespace) inside the cpp file, or even extracted to implementation detail class.

[quote name='Serapth' timestamp='1315503212' post='4859124']
[quote name='pulpfist' timestamp='1315502665' post='4859122']
Nice looking tutorial.
I took a quick look at chapter 4 and one thing that struck me was that each Visual object contains a sf::Image rather than a pointer/reference to a sf::Image.
Wouldn't it be a good idea to separate the images from that class, making it a "global" resource instead? Or at least explain for the reader that storing the image data in each visual object could become a waste of resources in the long run?

This is actually one of those area's ( actually the area ) I most hummed and hawed about if I was introducing needless complexity or not. However, as time goes on, there actually will be some (justified) global instances with Game:: being the sole point of contact. I don't actually swear users off them, as frankly in a few cases, they make sense. ( I have also grown to dislike how I named Gameloop )


I am curious though why you are anti private member functions?

[quote name='pulpfist' timestamp='1315512274' post='4859195']
[quote name='Serapth' timestamp='1315503212' post='4859124']
[quote name='pulpfist' timestamp='1315502665' post='4859122']
Nice looking tutorial.
I took a quick look at chapter 4 and one thing that struck me was that each Visual object contains a sf::Image rather than a pointer/reference to a sf::Image.
Wouldn't it be a good idea to separate the images from that class, making it a "global" resource instead? Or at least explain for the reader that storing the image data in each visual object could become a waste of resources in the long run?

I noticed that all the switch statements do not have a default label. Maybe this would be a nice opportunity to introduce the concept of an assertion (something which is also missing from the project) in combination with the default label?

The assertions might also come in handy when for example loading an image. Do you really want to continue your code when you cannot load an image?
[/quote]


This is a very valid point.

Thinking about it, you could create a introduction chapter explaining the fundamental hardware in use in a simple game, like memory for example. For a complete beginner these things isn't so obvious, so a drawing of memory as a big buffer of bytes with linear addressing starting at zero, could be worth its weight in gold later on. The reader would intuitively map the information in later chapters back to those basic drawings, and fill in the overall map as they go. If the introduction chapter is simple and easy to digest, I think it could give a great boost for both you and for the reader in the learning process.

For instance, if you already explained and made some simple drawings of how and why a disk is extremely slow compared to memory (assuming we are not talking of SSD disks), the reader will understand why optimizing code that access files on disk would be rather pointless. And you don't even need to remind them, or explain why, when the time comes.

A simple explanation and sketch of memory would also be very valuable in several circumstances, like pointers, buffer overruns, dynamic allocation, etc.
I always wondered why teachers doesn't take their time to do this when they start a new programming course.