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.


Messages - fallahn

Pages: 1 ... 28 29 [30] 31 32 33
436
General / Re: A question about the dreaded singleton
« on: August 12, 2013, 05:03:09 pm »
Woah there, std::map has find which returns interator and has log n complexity and you're doing n complex linear search. Also erase returns iterator to element after erased one so you don't have to do --i.

Ah thanks! I guess I need to brush up on my containers some more. I've not used std::map often.

Thanks for the feedback / opinions. It's true I've left this a bit late in my design to actually be considering now, but we live and learn. I understand what you mean about the Doom 3 engine, and I think there is definitely something to be taken from it - but I'm not sure I want to create a carbon copy.

As for the OP, a resource manager is not an exception at all, in fact, it's most often used for that case on the forum, where we had already many of those discussions.
The main problem is: You break encapsulation, by making it possible to access the resource manager from everywhere at any time. Not every single class should be able to access it.

OK, so I'm right in thinking this is one of those times where a singleton would come into use, but rather than give it global scope provide controlled access to it via perhaps a reference stored as a member of a class which needs to access it? I can totally understand graphical classes not needing any access to a resource manager for sounds :)

437
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:

#ifndef TEXTURE_MANAGER_H_
#define TEXTURE_MANAGER_H_

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

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

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

#endif //TEXTURE_MANAGER_H_
 
and
#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
        if(!path.empty())
        {
                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);
                newTexture->loadFromImage(fallback);
        }
        else
        {
                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)
                {
                        if(i->second.unique())
                        {
                                std::cout << "Flushing: " << i->first << std::endl;                                    
                                m_textures.erase(i);
                        }
                        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 )

438
SFML projects / Re: Scratchvaders - a project of silliness and woo
« on: August 11, 2013, 09:55:40 pm »
Ah  ;D

Well there's not much to it. The audio input class just inherits from sf::SoundRecorder and uses the buffer to create a VU meter:

bool AudioIn::onProcessSamples(const sf::Int16* samples, std::size_t sampleCount)
{
        //sum and average the value of the current set of samples
        sf::Int64 sum = 0;
        for(std::size_t i = 0; i < sampleCount; i++)
        {
                sum += std::abs(samples[i]);
        }

        float avg = static_cast<float>(sum / sampleCount);
     
    //10 * log() == power, 20 * log() == amplitude
        //See: http://www.sengpielaudio.com/calculator-db.htm
        m_dB = (avg > 0) ? 20.f * log10(avg / m_reference) : -1000000.f; //in theory could go to -inf so we cut off somewhere
        sf::Lock lock(m_mutex);
        Signal = (m_dB > m_threshold);

        return true;
}
 

Signal is an atomic bool (because the audio input runs in its own thread) which is set to true if the input level is above a designated value. In this case that value is set by the calibration mode you see at the beginning of the video where I check the input volume of the record. That way you ultimately get a boolean value which you can test much in the same ways as sf::Keyboard::isKeyPressed(), eg:

if(AudioIn.Signal) fire();
 

439
Hehe looks interesting. I guess it could also be used for other things.
Btw how exactly do you decide when to shoot?

Well.. I don't really. I just get into the groove.... Like I say it's not really a serious thing, it was kind of inspired by a scene from qbert's wave twisters and I thought 'hey it would be cool to shoot aliens with scratching' or something. Unless someone wants the source I doubt I'll do anything else to it any time soon.

440
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 :)

441
A little while ago I found this which explains how all the physics were done in the real sonic games. While it's probably not accurate to use individual pixels as resolutions are so high these days you can create 'collision points' with a vector of sf::Vector2f and use them for testing, along with FloatRect::contains(). I've tried the methods with both a simple platformer and a top down 2D racing game and it works pretty well

442
SFML projects / Re: 'Tiled' Tile-map Loader
« on: July 22, 2013, 11:05:49 am »
I'm not entirely sure what you mean by an addObject function. Tiled objects contain a position and a shape as well as, optionally, user data and a tile from one of the tile sets. The map loader uses a MapObject class which just reflects these properties as well as adding a few utility functions for things like collision testing or drawing debug output. If you want to create a new MapObject programmatically you can by using the MapObject class just like any other C++ class, then use layer.objects.push_back(myObj) as all the objects are stored in a vector belonging to the object layer (see the MapLayer class). If you want extended functionality you'll need to create your own entities which you can compose from sf::Sprite or an animated sprite class, along with a reference to a MapObject, for example:

class MyEnt
{
public:
    MyEnt(tmx::MapObject& mo) : m_mapObj(mo){};
    void Update(float dt){//do ent logic here};
    //so we can draw with rt.draw(myEnt.GetSprite());
    const sf::Sprite& GetSprite(void) const{return m_sprite;};
private:
    sf::Sprite m_sprite;
    tmx::MapObject& m_mapObj;
};
 

Then your entity will have direct access to the map object to which it is bound, including its collision testing and debug drawing abilities. I've recently updated the MapObject class with a Move() function, as someone else has also requested it, but it's not generally the approach I take so I can't vouch for its effectiveness.

443
Graphics / Re: GLSL Normal Map Shader
« on: July 21, 2013, 09:36:51 am »
If it helps I wrote a similar shader a while back specifically for sfml. There's a breakdown of it here.

444
Graphics / Re: Xml
« on: July 18, 2013, 10:08:07 pm »

445
SFML projects / Re: 'Tiled' Tile-map Loader
« on: July 17, 2013, 11:00:14 am »
You can insert tiles on object layers and add all the associated properties which objects have using the tile tool (shortcut T iirc) in Tiled. These will be drawn by the map loader no problem. Currently there is a bug, however, when moving objects about where the associated debug graphic and AABB for the quad tree are not updated which I plan to fix in the near future. Personally speaking (I'm sure there are other and probably better ways to do this) I only use the map objects as static geometry for things such as solid objects or transition triggers. I usually create dynamic objects such as collectables, players or enemies as separate entities which can interact with each other and are drawn over the top of the map. It depends on what kind of game you are making, of course, but having the dynamic entities separate can also help with things like z-ordering when sprites need to move behind and in front of other objects. All dynamic objects can be made to interact with the loaded map by querying the quad tree (see the included example in the archive). If you want to place something like collectables in the map with Tiled you can do so with placeholder objects on their own layer, then when loading the map check that layer and use each object's position to spawn your collectable entity (or any other entity for that matter).

446
SFML projects / Re: 'Tiled' Tile-map Loader
« on: July 16, 2013, 05:57:43 pm »
Yup, assuming you're passing the same window to the Draw function (ie you're not drawing to a render texture then drawing that texture to the window or something). Take a look at the isometric demo in the archive for an example.

447
I've found that this is a good reference for platform physics in general http://info.sonicretro.org/Sonic_Physics_Guide and a good starting point for setting up collision detection. By its nature we also know the technique works well on low end hardware :-)

448
General / Re: How to make your game assets on a single file?
« on: July 07, 2013, 08:09:24 am »
Take a look at physfs which is a library for opening pak and zip files. I believe there is also sample code on the wiki to demonstrate using it with sfml

449
Network / Re: Simple chat, simple problem?
« on: July 03, 2013, 10:33:10 pm »
I worked on something similar a few months back. You can read about it/view the source here if it helps.

450
SFML projects / Re: 'Tiled' Tile-map Loader
« on: July 03, 2013, 04:36:43 pm »
I've updated this again so now it draws maps using vertex arrays, and is nice and speedy! :D

Pages: 1 ... 28 29 [30] 31 32 33