Topics

1

General / pollEvent crashes and I can't figure out why

« on: August 04, 2013, 10:52:14 pm »

I've been making a game state system and as it progressed I figured that each state will need to have access to the window everywhere within the state so I figured I'd make a reference to a window in my abstract state class. I also have a StateManager class which takes care of creating/adding/removing states and StateManager contains a reference to a window. State classes also contain a reference to a manager so they should be able to get the window easily from the manager which is passed to the constructor.

However when states are changing the program crashes upon reaching while(window.pollEvent()) line.
Oddly enough this only happens if the State class contains a window reference as a member. If I instead have the window be a parameter for all the methods within then no crashes occur. I have no idea why that makes a difference.

Sadly the smallest possible example I could make which demonstrates this is around 94 lines long.

#include <iostream>
#include <vector>
#include <memory>
#include <SFML/Graphics.hpp>
#include <SFML/System.hpp>
#include <SFML/Window.hpp>

class Foo;
typedef std::unique_ptr<Foo> FooPtr;

class FooManager
{
private:
        sf::RenderWindow& m_window;
        std::vector< FooPtr > m_foos;
public:
        FooManager(sf::RenderWindow& window) : m_window(window) {}
        sf::RenderWindow& getWindow() { return m_window; }
        void pushFoo( FooPtr );
        void popFoo();
        void changeFoo( FooPtr );
        void doStuff();
};

class Foo
{
private:
        FooManager& m_manager;
        //By having the window reference here instead of as a parameter to doStuff() it causes crashes
        //Removing the window reference from the class and having doStuff() take it as a parameter works just fine
        sf::RenderWindow& m_window;
public:
        Foo(FooManager& manager) : m_manager(manager), m_window(manager.getWindow()) {}

        void doStuff()
        {
                sf::Event event;
     //Upon pressing space the program breaks here at event poll
     //Message: Unhandled exception at 0x5d693261 in Test.exe: 0xC0000005: Access violation reading location 0xfeeefefa.
                while(m_window.pollEvent(event))
                {
                        if(event.type == sf::Event::Closed) m_window.close();
                        else if( event.type == sf::Event::KeyPressed && event.key.code == sf::Keyboard::Space)
                        {
                                m_manager.changeFoo(FooPtr(new Foo(m_manager)));
                        }
                }
                m_window.clear(sf::Color::Black);
                m_window.display();
        }
};

void FooManager::pushFoo( FooPtr foo )
{
        m_foos.push_back(std::move(foo));
}

void FooManager::popFoo()
{
        if(!m_foos.empty())
        {
                m_foos.pop_back();
        }

}

void FooManager::changeFoo( FooPtr foo)
{
        if(!m_foos.empty())
        {
                m_foos.pop_back();
        }

        m_foos.push_back(std::move(foo));
}

void FooManager::doStuff()
{
        if(!m_foos.empty())
        {
                m_foos.back()->doStuff();
        }
}

int main()
{
        sf::RenderWindow window(sf::VideoMode(400,400,32), "Test");

        FooManager fm(window);
        fm.changeFoo(FooPtr(new Foo(fm)));

        while(window.isOpen())
        {
                fm.doStuff();
        }

        return 0;
}
 

2

System / Weirdness with sf::Clock and sf::Time

« on: August 01, 2013, 02:37:04 am »

For some reason when using a modulus operator with sf::Time it doesn't seem to work properly for me

#include <iostream>

#include <SFML/Graphics.hpp>
#include <SFML/System.hpp>
#include <SFML/Window.hpp>

int main()
{
        sf::RenderWindow window(sf::VideoMode(100,100,32), "Clock test");
        window.setVerticalSyncEnabled(true);

        sf::Clock myClock;
        while(window.isOpen())
        {
                sf::Event event;
                while(window.pollEvent(event))
                {
                        if(event.type == sf::Event::Closed) window.close();
                }
                std::cout << myClock.getElapsedTime().asMilliseconds() << std::endl; //miliseconds keep piling up
                if(myClock.getElapsedTime().asMilliseconds() % 1000 == 0) //but this doesn't work (It prints "Tick" when elapsed time is 0 and that's that)
                {
                        std::cout << "Tick" << std::endl;
                }
                window.clear(sf::Color::Black);
                window.display();
        }

        return 0;
}
 

I'm using SFML 2.1 in Visual Studio 2012

3

General / A couple of questions regarding SFML and Box2D

« on: July 11, 2013, 07:19:48 pm »

I wasn't sure where to post this so my apologies if I posted this in the wrong subforum. But I have a couple of questions regarding SFML used in conjuction with Box2D.

• in Box2D, methods Shape.Set(...) and Shape.SetAsBox(...) Make syncing physical bodies with SFML's shapes/sprites a bit incosistent and cause the source of my confusion.
  
  What I noticed is that Set method calculates a shape's centroid while SetAsBox doesn't. I assumed that in Box2D shape's centroid is akin to SFML's origin in that it is the origin of all the transformations for the body. I therefore assumed that a SFML shape/sprite with it's default origin of [0,0] would perfectly reflect a Box2D physical body(of identical shape) whose centroid is [0,0], and likewise that a SFML shape/sprite with it's origin set to it's center would perfectly reflect a Box2D physical body whose centroid is accurately calculated.
  
  However it seems to be the opposite. An equilateral triangle in Box2D created using Set with it's centroid calculated is reflected perfectly by a SFML shape whose origin is [0,0], and a Box2D square created using SetAsBox which leaves it's centroid at [0,0] is reflected perfectly by a SFML shape whose origin is at it's centroid. Can anyone tell me why is that?
  
  
• SetFramerateLimit() seems to make my application choppy when limit is 60, and when limit is set to 120 it behaves weird. In my test application, even though the limit is set to 120 it is somewhere between 60 - 70 and when the user applies thrust to the triangle the FPS jumps to 120+ and when thrust is no longer applied it reverts back to 60 - 70. Does anyone know why that might be happening?  Code at the bottom of the post.
  
• Can anyone tell me am I perhaps doing something wrong in my code at least SFML wise so that that might cause choppyness?
  

Test code: https://gist.github.com/MrPlow442/5977338

4

General / Need help with sf::Texture, sf::Sprite and design choices

« on: February 22, 2013, 06:24:33 pm »

I'm not sure whether this is the appropriate forum section so I apologize if I messed up.

Basically I'm trying to make a Tic-Tac-Toe game for my first project while also trying to write classes to possibly be reusable in other future projects with little to no changes.

Right now the biggest question for me is how should i handle textures and sprites.
I'm making a Texture cache similar to this sprite cache code, and creating a tile class which will contain certain info such as states(like locked or interactable) and owner( cross or circle in this case, although I'm thinking of replacing this with some sort of a player reference or something ) and a board class which will basically contain an std::array of tiles to manipulate them.

First question would be:
Regarding the texture cache being made similar to the sprite cache code above: since the sf::Sprite takes a reference to a sf::Texture then there should be no problem with my cache since the texture will be alive for as long as there are sprites referencing it? Or am I thinking it wrongly?

And my second question would be:
What would be a better overall design choice:
a) to have the board class load the texture and for each tile to have it's own sf::Sprite?
b) to have the board and tile classes only contain "logic" parts, and have a separate manager class to take care of creating sprites and drawing and then somehow unify all that in the main game class?
c) neither?