Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - fallahn

Pages: 1 [2]
Graphics / Sprite becomes distorted
« on: November 02, 2013, 12:19:03 pm »
This only happens maybe once in every 200 times, but when drawing this image with an sf::Sprite (nothing fancy, just a normal sprite) instead of getting this I get this.

It seems like the vertex array in the sprite is somehow getting messed up - but as it happens so rarely I have no idea how to reproduce it. I'm not really expecting anyone to come up with a fix for this - I just wondered if it was something known about or if someone has come across something similar in the past

General / A question about the dreaded singleton
« on: August 12, 2013, 03:03:50 pm »
Pretty much every book I've read and every forum topic I've seen which discusses the Singleton pattern, and global variables in general, basically sum up as: don't do it. I understand the arguments against this too, but I've come up against a situation in something I'm working on where I think it may be the exception, although I'm not really sure. I'm hoping some of the experienced programmers here might be able to provide some perspective on the situation. First of all let me explain a little about what I'm doing / trying to do. Currently I have some basic texture resource management in this simple class:


#include <Game/Common.h>
#include <memory>

namespace Game
        class TextureManager
                static const std::shared_ptr<sf::Texture> GetTexture(std::string path = "");

                static std::map<std::string, std::shared_ptr<sf::Texture> > m_textures;

#include <Game/TextureManager.h>

const std::shared_ptr<sf::Texture> Game::TextureManager::GetTexture(std::string path)
        //see if we already have it loaded first and return if we do
                for(auto texture : m_textures)
                        if(texture.first == path)
                                std::cout << "Texture manager found: " << path << std::endl;
                                return texture.second;

        //else attempt to load from path and create placeholder if missing
        std::shared_ptr<sf::Texture> newTexture(new sf::Texture());
        if(path.empty() || !newTexture->loadFromFile(path))
                sf::Image fallback;
                fallback.create(20u, 20u, sf::Color::Magenta);
                std::cout << "Texture manager loaded: " << path << std::endl;
        m_textures[path] = newTexture;

        //check size of map and flush unused textures
        if(m_textures.size() > 200u)
                std::cout << "Texture Manager begin flushing textures..." << std::endl;
                for(auto i = m_textures.begin(); i != m_textures.end(); ++i)
                                std::cout << "Flushing: " << i->first << std::endl;                                    
                        i--; //move back to previous position else next index is skipped

        return m_textures[path];

std::map<std::string, std::shared_ptr<sf::Texture> > Game::TextureManager::m_textures;

Basically any textures loaded are referenced in a std::map along with the resource's file path, so if a requested texture is already loaded a reference is returned to that, rather than loading the resource again. If the map reaches a certain size when loading a new texture any currently unused textures are flushed from the cache. The class members are static, which makes it simple to access the texture manager from anywhere in my program as well as guaranteeing all loaded textures are referenced by the same map. This works very well.

However: I have been considering using this method to manage other resources, such as fonts, images or sounds. In the interest of code reuse it makes sense to me to make a templated version of this class rather than implement it for every type of resource I want to manage. This is where it falls down, because (as far as I know) I can't use static members with templates in the same way, as there will be no way for the class to know which data type / resource it's working with – and therefore I will need to start creating instances of the resource manager for each type of resource I want to manage. So this is where my question comes in: When I create these instances I want to make sure there are only ever one of each type of manager, and I need to be able to provide global access to the managers from the rest of the program, ie the resource manager would suit the singleton pattern – so would this be the exception to the rule? Or am I taking the wrong approach to resource management? (Apologies for the small essay :D )

SFML projects / Scratchvaders - a project of silliness and woo
« on: August 11, 2013, 02:17:49 pm »
So apart from coding I like to spend my time playing with old school vinyl, and I got to thinking what would happen if I tried to combine the two. The answer was this:


Just a bit of fun really, the audio input triggers the 'fire' function when it peaks - it would work just as well if you were to sit there shouting 'pew pew pew!' in to a microphone. I had to reduce the sleep time in SFML audio to 1ms to make it sensitive enough to work, but it also had the side effect of causing the music to skip / stutter when using the screen capture software (it works fine other wise). It's no DJ Hero but a good learning experience :)

SFML projects / Threat Level 2.0
« on: March 08, 2013, 07:20:57 pm »
This is a remake of one of my first projects using SFML 2.0. Nothing ground breaking, and probably full of bugs but I'm bored of working on it now so I thought I'd share. Uses Thor for particle effects and TGUI for the UI, so credit to the authors of those libraries.


Download Windows installer.

SFML projects / sfchat - a class for adding client/server in-game chat
« on: January 25, 2013, 07:00:49 pm »
The subject says it all really: I've basically been working on a class which can be included in a network game to let players talk to each other. Currently working features are:

IRC style commands like /me /nick /connect
Team filtering so messages can be global or private to team members
Logging to text file - both client and server side
Easy to add to an existing project, with just one instance and a few function calls

I've a blog post here which explains a bit about how it works, and I've created a project for it on Google code github. It's not thoroughly tested yet so any bugs or feedback would be appreciated, thanks. I hope someone finds this useful!

Pages: 1 [2]