Messages

121

General / Re: Deciding which Container to use for a Manager Class.

« on: October 31, 2012, 05:16:38 am »

Vectors are very fast at iterating from the start to end, but removing something in the middle can be heavy. Consider adding are removing instances nearly every step. (Obviously, there are very few times when this is even a good idea, but I know a vector is not the best container for this scenario.)

A vector or deque should be considered the container of choice until you know that you need the qualities of another container.

Removing something from the middle of a vector can be quite cheap if the element is say, a pointer, and the relative order of elements in the vector isn't important.  Just swap it with the back one and erase the end (or resize if you prefer.)  And, you won't find faster insertion/deletion than at the ass-end of  a vector or either end of a deque.

122

General / Re: Needing help with object manager.

« on: October 29, 2012, 04:42:57 am »

Is there a possibility spriteList is empty when you enter this method?

If it is, you don't return anything.

In the version with the iterator, you had all of the returns commented out.

123

General / Re: Needing help with object manager.

« on: October 29, 2012, 12:22:47 am »

Also in this case the if doesn't need an else since I'm going to have to up the count anyways since I'm in a loop.

Actually, in this case you do need an else and to not increment the iterator.  Maybe you should look up what erase does and what it returns.

124

General / Re: Needing help with object manager.

« on: October 29, 2012, 12:11:29 am »

I don't know if this is what's causing your problem or not, but the implementation of BaseObjectManger::RemoveDeadSprites is not correct.  You're looping on an iterator that becomes invalid after the first erase call.  And I don't know, in several functions, why you're mixing iterators and indexes.   Use whichever is one is most suited to the purpose, but I would avoid mixing them in the same loop. 

Here's a straightforward (untested)  implementation:

void BaseObjectManager::RemoveDeadSprites()
{
    typedef std::vector<BlankSprite*> vec_t ;

    vec_t::iterator current = spriteList.begin() ;

    while ( current != spriteList.end() )
    {
        if ( current->getDead() )
            current = spriteList.erase(current) ;
        else
            ++current ;
    }
}

It could be optimized if the order of elements in the vector isn't important.

[Edit:  Same issue in BaseObjectManager::RemoveSprite(std::string) since you don't exit the loop when you've found the one you want to remove.]

125

System / Re: sf::err result what does it mean?

« on: October 28, 2012, 06:09:06 am »

What exactly are you trying to do?  Writing a stream to another stream doesn't make much sense.

Are you trying to redirect sf::err to another stream?  That's covered in the documentation.

http://www.sfml-dev.org/documentation/2.0/group__system.php

126

System / Re: sf::err result what does it mean?

« on: October 28, 2012, 02:48:08 am »

Why are you trying to write a std::ostream to your file?  Why does Write even take a std::ostream&, given the implementation?

127

Graphics / Re: Tile won't texture SFML 2.0

« on: October 27, 2012, 10:14:38 pm »

Is there something I have to specifically do except for writing that find file code to get it to work?

You could put the file where the program expects to find it.

If you're using Visual Studio and running from the IDE, the default location is the same place it places your source files.  So just open a file in the IDE, right click on the tab and click "Open Containing Folder."  Paste your file into that folder and it should work.   Of course, if you've messed with the default settings that may not be the case.

Then you may need to check under project settings -> configuration properties -> debugging -> working directory.  You can choose edit from the pulldown box and click the macros button to see what the macro expands to if it happens to be a macro.

At least, that's how it works for C++.  You mentioned C#, and I don't know if that's handled the same way.

128

Window / Re: Static Window? "static sf::Window renderWindow;"

« on: October 27, 2012, 10:02:08 pm »

It seems as if I'll have to re make ever class as an object before I am able to actually use it, ....doesn't that defeat some purpose of something?

You have to have an object to use an object.  If all I have is the idea of a ball, it's going to be hard to play catch.

129

Window / Re: Static Window? "static sf::Window renderWindow;"

« on: October 27, 2012, 09:01:51 pm »

One can guess from the stack trace posted earlier that this happens prior to main being invoked, which is when things of static and external storage duration are constructed, so it is very likely some sort of dependency issue on the order of things being constructed (which is supported by the OP's assertion that it only happened after he made the variable static.)  Unfortunately, there is no portable way to order the construction of such objects which is one reason these type of variables should be avoided when possible.

One possible solution is to:

sf::Window& GetWindowInstance()
{
    static sf::Window instance ;
    return instance ;
}
 

And just use that to access your window instance.  The instance isn't constructed until the function is called the first time.  However, any object of static duration which calls this function directly or indirectly during construction could cause the problem to recur.

A better solution is to refactor the code so this isn't necessary.

130

Graphics / Re: Tile won't texture SFML 2.0

« on: October 27, 2012, 08:44:47 pm »

Since you're only adding one item to the vector in your code, I don't believe that's a problem, but it certainly could be in the future.

So, for future reference:  When you add an item to a vector, it may not have enough memory initially to store it.  If it doesn't it allocates more memory, copies/moves what was in the old memory to the new memory, and releases the old memory.  This means that any pointers or references to those objects would no longer be referencing valid objects.  If those references or pointers are then used/dereferenced the result is undefined behavior which will hopefully just crash the program instead of appearing to work correctly while silently formatting your hard drive.

To avoid that, make sure all textures are loaded before you attach any sprites to them, or use a container like std::deque for which it isn't an issue.

Change your implementation of Engine::LoadTextures to:

 void Engine::LoadTextures()
{
    sf::Texture texture;

    // Load tile textue
    if ( !texture.loadFromFile("grassTile.png"))
        throw "Unable to open file: grassTile.png" ;

    // Add the image to imageManager
    textureManager->AddTexture(texture);
    // Initialize grassTile as a new tile and set it's texture
    grassTile = new Tile(textureManager->GetTexture(0));
}

Run, report, and remember to check return values from functions.

131

SFML projects / Re: TGUI: a c++ GUI for SFML (with Form Builder)

« on: October 27, 2012, 07:09:48 pm »

Maybe making use of some C++11 features (or boost, previously) would make things a little easier?

#include <iostream>
#include <functional>
#include <map>
#include <vector>

class Button
{
public:
    typedef std::function<void()> callbackfunc ;
    enum Clicked { LeftMouseClick } ;

    void addCallback( callbackfunc cbf, Clicked click )
        { callbacks[click].push_back(cbf) ;}

    void doCallbacks(Clicked c)
    {
        switch ( c )
        {
        case LeftMouseClick:
            for ( auto cb : callbacks[c] )
                cb() ;
            break ;
        }
    }

private:
    std::map<Clicked, std::vector<callbackfunc>> callbacks ;
};


class myClass
{
public:
    myClass ( Button & b )
    {
        // onMouse = std::bind(&myClass::onMouseClick, *this) ;  Don't need this!
        b.addCallback(std::bind(&myClass::onMouseClick, *this), Button::LeftMouseClick) ;
    }

private:
    void onMouseClick()
        { std::cout << "onMouseClick()\n" ;}

    // Button::callbackfunc onMouse ;  Don't need this!
};

void myCallbackFunc()
    { std::cout << "myCallbackFunc()\n"; }

int main()
{
    Button b ;
    b.addCallback(myCallbackFunc, Button::LeftMouseClick) ;    
    myClass mc(b) ;

    b.doCallbacks(Button::LeftMouseClick) ;
}

Edit:  myClass doesn't need to keep a copy of the std::function object.  Commented it out.

132

Window / Re: Handling mouse input outside of Window::GetEvent()

« on: October 25, 2012, 06:18:54 pm »

It seems to me what you really want to do is have the Player object process some events, so why not add a member function to Player that does just that?

void Player::ProcessEvent( const sf::Event & event )
{
    // ...
}

// ...

    while(window.IsOpened()){
        while(window.GetEvent(event)){
            if(event.Type == sf::Event::Closed){
                window.Close();
            }
            else // player processes events we don't want to process here.
                player.ProcessEvent(event) ;
        }

        window.Clear();
        window.Display();
    }

// ...
 

133

Graphics / Re: Unexpected result using sf::Lines primitive.

« on: October 14, 2012, 01:54:50 pm »

sf::VertexArray is an encapsulated std::vector<sf::Vertex>, i.e. it allocates a dynamic array.

Aha.  For some reason the array type didn't even occur to me.  Now that you point it out, it's pretty obvious.  Thanks!

It doesn't mask it, it solves it. Since your lines are 1-pixel wide, their position must be the center of the pixels so that they cover them completely.

That's good news, then!   

134

Graphics / Re: Unexpected result using sf::Lines primitive.

« on: October 14, 2012, 10:58:35 am »

The drivers did need updating (in fact, they jumped up a major version,) but unfortunately it didn't resolve the problem.  Adding .5 to the x value does mask the problem though, so I can work with that for the time being.  It does have me wondering how else the problem might manifest.

That version of the function is certainly cleaner, but I don't think there's actually any heap memory involved is there?  It avoids calling the default constructor for the objects in the lines array in favor of direct initialization, but heap?  Maybe I'm misunderstanding.

In the "real" code,  the function looks a bit different.

Thanks for the assist!

135

Graphics / Unexpected result using sf::Lines primitive.

« on: October 14, 2012, 02:41:23 am »

I'm not sure why the 'gaps' appear when I'm using the code below.  At first I thought perhaps it might be some float rounding thing, but that doesn't seem to be the case.


You can see the gaps (black lines) here:



Here is the (minimal, compilable) code that produces it on my system.  You'll have to pardon the naming style mismatch.

#include <SFML/Graphics.hpp>

const unsigned win_height = 600 ;
const unsigned win_width  = 800 ;
const unsigned line_height = 300 ;

void draw_vertical_line(sf::RenderTexture& t, unsigned x) ;
void update_texture(sf::RenderTexture& t) ;
void wait_for_close(sf::RenderWindow& window) ;

int main()
{
    sf::RenderWindow window(sf::VideoMode(win_width, win_height), "Vertical Lines") ;

    sf::RenderTexture texture ;
    if (texture.create(win_width, win_height))
    {
        update_texture(texture) ;
        window.clear() ;
        window.draw(sf::Sprite(texture.getTexture())) ;
        window.display() ;
    }
    wait_for_close(window) ;
}

void draw_vertical_line(sf::RenderTexture& t, unsigned x)
{
     sf::VertexArray line(sf::Lines, 2) ;

    line[0].position = sf::Vector2f(x, win_height) ;
    line[1].position = sf::Vector2f(x, win_height - line_height) ;
    line[0].color = line[1].color = sf::Color(0, 255, 256 * x / win_width) ;

    t.draw(line) ;
}

void wait_for_close(sf::RenderWindow& window)
{
    sf::Event event ;

    while (window.isOpen())
        while ( window.pollEvent(event) )
            if ( event.type == sf::Event::Closed )
                window.close() ;
}

void update_texture(sf::RenderTexture& t)
{
    t.clear() ;
    for ( unsigned i=0; i<win_width; ++i)
        draw_vertical_line(t, i) ;
    t.display() ;
}

Can anyone see what I'm doing wrong here?