Messages

31

System / Re: Time and clock

« on: January 16, 2015, 10:51:43 pm »

You're creating the sf::Clock object inside fire(), so it gets destroyed when fire() exits.  Hence you have a brand new clock every single time you call fire().

This is how all objects work in C++, so it's perfectly normal and expected behavior.  If you wanted the clock to "survive" longer than one iteration of the while loop, then create it outside the loop.

32

General / Re: A question about shared_ptr (not strictly sfml specific)

« on: January 15, 2015, 01:56:51 am »

As far as I know, everything you describe is supported by the ResourceCache in Thor: http://www.bromeon.ch/libraries/thor/v2.0/tutorial-resources.html

The ResourceCache itself owns the resources, so by default they don't get freed until the whole cache goes out of scope.  You can call release() to manually release individual resources (if no one other than the cache is using them), or set the cache to AutoRelease mode to make it automatically release resources that aren't getting used.  And there's nothing stopping you from making multiple caches so that certain resources get one policy and other resources get another, which is probably the clean solution to your problem.

It does all this with shared_ptr, but without the massive hack you're proposing =)

33

General / Re: Trying to create a function that opens a window, please help.

« on: January 13, 2015, 02:26:41 am »

Might as well toss out a few more nitpicks while they're easy to fix:

1) When you write this:

sf::RenderWindow window = sf::RenderWindow();

A temporary RenderWindow gets constructed, then RenderWindow "window" gets constructed using copy assignment, then the temporary RenderWindow gets destroyed.  This is kinda wasteful, so just let "window" default construct itself:

sf::RenderWindow window; // yes, this is a default constructor call

2) Passing by pointer is certainly a big improvement over your first attempt, but when I said "pass by reference" I was referring to C++ references, which are often better than raw pointers.  startWindow with references would be:

void startWindow(sf::RenderWindow& window) // &, not *
{
        std::vector<sf::VideoMode> i = sf::VideoMode::getFullscreenModes();
        window.create(i.front(), "SFML WORKS!", sf::Style::Fullscreen); // ., not ->
}

References can't be null, they don't allow unsafe things like pointer arithmetic, and they retain the efficiency bonus you get from passing by pointer instead of (copied) value.  So for the simple use case of efficiently passing arguments, references are generally preferable to pointers.

3)

#include<array>

This is interesting since you're using std::vector and no std::arrays.  Perhaps you should include <vector> instead. =)

34

General / Re: Trying to create a function that opens a window, please help.

« on: January 13, 2015, 01:38:55 am »

You're returning a pointer to an object just before it gets destroyed.  This is about as undefined as undefined behavior gets.

The simplest/best/safest solution is to default construct the actual window in main(), then pass it by reference to a function that takes care of looking at fullscreen modes and then calls create() on it.

In general, you should avoid using raw pointers (especially owning raw pointers like this one) unless you have a very good reason to, because as you've just discovered, they're very error-prone.

35

Graphics / Re: Sprite-Object lost (Probably a scoping-problem)

« on: January 11, 2015, 03:43:50 pm »

Sorry, I thought it would be easier to understand the problem if only some simple pseudo-code was posted

That's why it has to be minimal.  See http://sscce.org/.  Reduce the code you actually have down to a single file that still reproduces the problem, but contains absolutely no code that isn't needed to reproduce it.  Then, we can actually help.

Usually trying to reduce the code helps you find the bug on your own, and anyone who claims they can't easily reduce it probably has such unmaintainable code that the current bug is the least of their worries.

Also, use a debugger.  If the null pointer thing happens inside draw(), but not in the dereferences you have directly above the draw(), the problem clearly is not what you think it is (which is why an SSCCE is so important).

Finally, resource managers are hard.  Jesper's right to suggest that you use an existing one instead.

36

Graphics / Re: Sprite-Object lost (Probably a scoping-problem)

« on: January 11, 2015, 02:30:30 pm »

Since you're asking us to help find a bug in your program, there's really nothing we can do without a complete and minimal example.

The only thing I can do is respond to this comment:

I know that Singletons are bad but no idea how to do it otherwise

This is exactly why singletons/globals are bad: They let you "get away" with not figuring out the real solution to your problem.

Of course, without more details I can't tell you what the correct solution is, but most of the time it's fine to pass all of a class's dependencies to it in the constructor.  In this case, I would think that whoever is constructing Entities can talk to the resource manager itself, so the Entity simply receives a Sprite and deals with that.

37

SFML projects / Re: SfmlExt

« on: January 10, 2015, 09:32:18 pm »

I suspect a push_back(args) isn't all that different from an emplace_back() followed by thing.setArgs(args).  Probably shouldn't worry about it until you have profiler data showing it makes a difference.

38

System / Re: Trouble converting v8::String::Utf8Value to sf::String

« on: January 10, 2015, 12:08:02 pm »

Could you show a complete and minimal example where you simply initialize some char[]s or std::strings (with whatever bytes you have in "utf8" right now) and then actually draw an sf::Text with it?

Incidentally, I'm fairly sure you can pass a std::string directly to sf::Text::setString() without worrying about the conversion yourself.  It's probably safer that way.

39

General / Re: stuck in World::adaptPlayerPosition() pls help

« on: January 10, 2015, 02:10:56 am »

From my understanding we just set the LEFT X and TOP Y position with
sf::FloatRect viewBounds(mWorldView.getCenter() - mWorldView.getSize() / 2.f, mWorldView.getSize());

Those methods all return Vector2s, so it's using the FloatRect constructor that takes two Vector2s.

I know how max and min work but i'm confused about the values we are using inside the brackets (i think viewBounds.left is 160f 'cause our window is 640w, 480h,....) :/

I don't think the view is identical to the window size/position.  Otherwise mWorldView wouldn't serve much of a purpose.  So the actual numbers involved are going to vary depending on where the view is.

-Also can you please explain me in simple worlds how the following code works with the values, maybe with an example please.

The code is essentially:

    position.x = std::max(position.x, xCoordinateOfLeftEdge);
    position.x = std::min(position.x, xCoordinateOfRightEdge);
    position.y = std::max(position.y, yCoordinateOfTopEdge);
    position.y = std::min(position.y, yCoordinateOfBottomEdge);

which in English means "if position is not inside the current world view, move it back into the current world view".  In some contexts you would call this "clamping" the position variable.

The +/-borderDistance simply ensures that the object will not only remain inside the view, but at least borderDistance pixels inside the view, presumably so that you can't end up with half the object outside the view or something.

Since you requested an example: Say your character is 40x40 pixels, so you set borderDistance to 20 pixels.  Your world view is 100x100 at (0,0), because I like round numbers.  Somehow your player ends up at position=(-5, -5).  Those four lines of code move him back to (20, 20), so he's fully visible.


P.S. I've never read the book so all of the above is guessing from the code snippet you posted.  But it's clean, readable code doing very simple, standard things so I should be pretty close.

40

Graphics / Re: [solved]Collision counter, count increses 1 time per collision

« on: January 09, 2015, 09:36:03 pm »

Since that's nowhere near a complete and minimal code example, it's impossible to say anything for sure, but here's my guess:

When the collision is true I'm setting a bool to not increse the score any more

You seem to be implying that setting the bool to false will somehow keep collisionCoin() from changing it back to true until "this" collision is "done".  That's not how bools work.

If this comes as a surprise to you, you may wish to read a good C++ book.

Assuming that is the problem, something like this would work better:

bool gameHandler::isCollidingWith(Obstacle &o) {
    return player.getSprite().getGlobalBounds().intersects(o.getSprite().getGlobalBounds());
}

bool gameHandler::collisionCoin(Obstacle &o) {
    if(this->isCollidingWith(o)) {
        this->show = false;
        if(!this->collisionInProgress) {
            // notice we'll only end up in here once per collision
            this->score.addScore();
        }
        this->collisionInProgress = true;
        return true;
    } else {
        this->collisionInProgress = false;
        return false;
    }
}

From a general software architecture point of view, it's also better to keep your score update logic together with the rest of your update logic.  showHighScore() is essentially a getter, so it shouldn't be taking care of updating the value as it gets it.

41

General / Re: [img]sfml-graphics-d-2.dll missing BUT can run perfect without debuggning

« on: January 09, 2015, 12:19:41 am »

I don't see any executables in that folder.  Do you?

Visual Studio normally puts the executables in Debug/Release subfolders.  Try there.

42

Feature requests / Re: Facility to get standard paths

« on: January 08, 2015, 08:50:51 pm »

Awesome, I always assumed this was out of SFML's scope.

Could we also consider the executable directory? The current working directory isn't that great for (portably and reliably) loading resources, which is what most basic SFML programs need the filesystem for.

43

Graphics / Re: custom shape type not appear in window

« on: January 07, 2015, 09:02:03 am »

You seem to be lacking a basic understanding of how C++ works.  There are no variables called "shape" or "EllipseShape" anywhere in this program.  There are classes/types called sf::Shape and EllipseShape, but those are classes, not objects.

To solve your immediate problem you simply need to create an actual object:

EllipseShape anActualObjectOfTypeEllipseShape;
...
window.draw(anActualObjectOfTypeEllipseShape);

Like most software libraries, SFML assumes (and has to assume) that you already know the language it's written in.  If you weren't aware that classes are not the same thing as objects, you probably need to go read a good book on C++ before trying to use libraries written in that language.

44

General discussions / Re: Multi Monitor Setup

« on: January 07, 2015, 01:12:17 am »

We should probably look at what the actual operating systems are doing before talking in detail about what the cross-platform API should be.

For Windows, it looks like almost everything will be under this page: http://msdn.microsoft.com/en-us/library/dd145071(v=vs.85).aspx
For Mac OS X, I think NSScreen is the place to start: https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSScreen_Class/index.html#//apple_ref/occ/clm/NSScreen/screens
And for Linux I can find some useful XCB functions scattered around like this one: http://www.x.org/releases/X11R7.6/doc/libxcb/tutorial/index.html#ScreenCount

I also found an iOS page for handling "external displays": https://developer.apple.com/library/ios/documentation/WindowsViews/Conceptual/WindowAndScreenGuide/Introduction/Introduction.html

I don't have time to read all of these pages myself, but one interesting thing I saw right away was a very clear answer about how multi-monitor screen coordinates work on Windows:

The primary monitor contains the origin (0,0). This is for compatibility with existing applications that expect a monitor with an origin. However, the primary monitor does not have to be in the upper left of the virtual screen. In Figure 1, it is near the center. When the primary monitor is not in the upper left of the virtual screen, parts of the virtual screen have negative coordinates. Because the arrangement of monitors is set by the user, all applications should be designed to work with negative coordinates. ... The coordinates of the virtual screen are represented by a signed 16-bit value because of the 16-bit values contained in many existing messages.

45

Graphics / Re: custom shape type not appear in window

« on: January 06, 2015, 08:19:35 pm »

In addition to what exploiter said.

window.draw()
...
but I can't figure out what goes into the parentheses here

The tutorials probably cover this somewhere, but if you're ever unsure or want more details, that's what API documentation is for.