Messages

1

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

« on: August 04, 2013, 11:28:03 pm »

You are deleting the foo on which you call do stuff in the do stuff function and then you try to access it's members.

Yea that seems to be it. Now that it's clearer on what's causing my issue I'll fiddle around to see how I can fix it. Thanks

2

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;
}
 

3

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

« on: August 01, 2013, 05:15:48 pm »

I hoped I could use a single clock for multiple events

You just have to write it slightly differently:

sf::Time lastEvent1;
sf::Time lastEvent2;

...

sf::Time now = clock.getElapsedTime();
if (now - lastEvent1 > sf::milliseconds(300))
{
    // trigger event 1...
    lastEvent1 = now;
}
if (now - lastEvent2 > sf::seconds(5))
{
    // trigger event 2...
    lastEvent2 = now;
}

This way you can have any number of events with different periods, all using the same absolute time base.

Sweet! Certainly less messy than what I had in mind

4

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

« on: August 01, 2013, 03:11:07 pm »

Your elapsed time is very unlikely to be exactly a multiple of 1000. That's why the modulo test fails most of the time.

You should rather test (elapsed >= 1000) and restart the clock everytime a second is elapsed.

I was afraid of something like that. I hoped I could use a single clock for multiple events(Like do one action every 300ms and then when 5 seconds passes do another action and restart the clock), though I can probably still do that if I accumulate the restart time somewhere and then check that. Thanks for the answer.

5

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

« on: August 01, 2013, 03:38:15 am »

sf::Time/Clock don't support a modulus function.  This has been a requested feature in the feature request thread but probably won't ever be implemented unless you can supply some darn good and concrete uses for it.

I see... However myClock.getElapsedTime().asMilliseconds() returns sf::Int32 which is essentialy typedef'd int, and this code compiles and runs. So if the result is an integer and I'm making a modulus operation over an integer it should work, shouldn't it?

6

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

7

SFML projects / Re: ee::MiniEd Messy idk-what-and-Box2D-editor (Heavily WIP, screens)

« on: July 31, 2013, 06:00:46 pm »

I can now output XML(yuck..) using pugi for it. hehe.xml:

pugi(xml) is name of the library I use, it's very nice, c++ish and documented well.
http://pugixml.org/

Welp!! It's official... I am blind.    Thanks

8

SFML projects / Re: ee::MiniEd Messy idk-what-and-Box2D-editor (Heavily WIP, screens)

« on: July 31, 2013, 04:47:33 pm »

I was thinking of making something like this because I really need an editor where I can make complex body shapes and export them and I can't really afford R.U.B.E. Could you tell me what libs/tools did you use for serialization and exporting to XML?

9

General / Re: A couple of questions regarding SFML and Box2D

« on: July 12, 2013, 04:12:43 pm »

Thanks for the response.

I read the blog post but I'm somewhat puzzled with his use of smoothedPosition and smoothedAngle variables. He calculates them but doesn't show how they're used. I assume that the body's position and angle are set to those values, or perhaps those values are applied to the render body/sprite? If that is the case wouldn't then the physical body and the sprite be a bit out of sync? Anyway since he doesn't show when and where he updates the body position and angles I have no clue what to do with those values. The fact that he's done it as a part of a component system doesn't help alleviate my confusion.

Got any advice on this?

10

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

11

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

« on: February 23, 2013, 03:17:19 pm »

std::shared_ptr is a complex and expensive smart pointer, it should never be the default approach. It can be taken when ownership has to be shared among multiple owners, and it's not clear which owner is responsible of destruction. std::weak_ptr is always used together with std::shared_ptr; it allows to have weak references (i.e. smart pointers that don't keep the resource alive).

That makes sense. std::shared_ptr also creates a structure of reference counters so i guess it is expensive to use. I just thought it fit the purpose of a cache since I'd have multiple objects share the same resource and I didn't want it to be released prematurely.

I don't see why you have a sprite manager and shared pointers to sprites. sf::Sprite is a very lightweight class, don't be afraid of copying it. So, simply have a std::vector<sf::Sprite> without any managers, custom sprite classes and smart pointers. These indirections make code very complicated, but don't really add an advantage. Your class ActualSprite is broken anyway, since it doesn't consider the Rule Of Three.

Yeah, I basically misunderstood sf::Sprites. I didn't notice that they take a reference to a texture so I thought that each sprite contains a copy of their own texture. That's why i made a sprite cache, instead what I really should have made was a texture cache.  But I don't have to now.

12

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

« on: February 22, 2013, 11:25:07 pm »

The Thor Nigthly builds match the SFML Nightly builds, so they'll most likely fail with SFML 2 RC.

Oh, well i guess I'll just have to download the newest SFML nightly then.
Are there any changelogs i could look at to see what has changed between the RC and the newest nightly aside from reading the Commit history?

13

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

« on: February 22, 2013, 10:29:30 pm »

Something I also had to teach myself: Don't make things more complicated than necessary. Manager classes, shared and weak pointers are rarely necessary -- mainly if you have true shared ownership and can't determine a class to have responsibilities about resources. For such cases, I have also written thor::ResourceCache, so you wouldn't need to reinvent the wheel.

But often, a simple STL container (std::map if you have some sort of ID) is enough to store textures. You can then distribute raw pointers, given that you guarantee the lifetime of the resources.

Wow the Thor library seems pretty sweet. Anything that makes me write less code to achieve a goal is nice.
One question though. For Thor 2.0(the newest eXpl0it3r VS2010 nightly), will it work with SFML 2.0 RC or do i have to download the newest SFML build? I'm kind of unwilling to build things myself since I'm awfully inexperienced in CMake( i really ought to learn how to build things properly ).

Also is there anything wrong with how I've made the sprite cache? Cause i was planning on making the texture cache almost identical. The sprite cache started out from my misunderstanding of sprites( it should've been a texture cache all along ). At first it was just raw pointers but then someone told me and pointed me to resources which said that i should never use raw pointers in C++ if i have the option of using smart pointers. So i made it with weak_ptr/shared_ptr. I spent quite a lot of time on it(learning about smart pointers mostly) so even though I don't plan on using it I still want to know what i did wrong. 

Concerning your board, you can try to have only logic in the tiles. In my game Zloxx II, each tile contains only a few attributes like type or animation step. I even create a new sf::Sprite in each frame for each visible tile, and I have not had any performance problems. In such a case, you could still take sf::VertexArray or try other optimizations.

You can also have a sf::Sprite as a member (not base class!) of your tile class, however tiles become more heavyweight as a result. Copies are more expensive, and you need to keep data like the position or texture rect always synchronous and sometimes even duplicate information.

I still have a lot of planning to do so I'll see how everything goes. What I'd like the most is to have either a specialized class(a functor maybe?) or just a function which would be used to unify(synchronize?) the logic elements with sprites. Like have the main Game class with update() and render() methods.

14

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?