My first SFML Program

[intrinsic]

I've been playing around with it all day almost. Did some reading of the documentation to better understand the classes and their members.

Here's what I got so far:
http://pastebin.com/J3vWifmF

If you have any suggestions on how I could do this better or if there is something I don't need in the code, please let me know.

[eXpl0it3r]

You could use sf::FloatRect instead of sf::Rect<float>.
sf::Mouse has only static member functions, as such creating an instance of it is necessary, you can just call the functions directly like this sf::Mouse::getPosition().
The mouse cursor is generally considered as a point, as such it doesn't really make sense to create a 1x1 rect. You can instead just use the sf::Rect<T>::contains() function. Additionally you can initialize the tileRect with the constructor thus you don't have to set every property. And finally you should convert between screen space and world space with mapPixelToCoords. So it would probably look more like this:

sf::FloatRect tileRect(100.f, 48.f, 100.f, 48.f);
sf::Vector2f relativePosition = window.mapPixelToCoords(sf::Mouse::getPosition(window));
if(tileRect.contains(relativePosition)) {
...

[Hapax]

#include <SFML\System.hpp>
#include "SFML Files\include\SFML\Window.hpp"
#include "SFML Files\include\SFML\Graphics.hpp"

Any particular reason why Window and Graphics were included differently from System?

[intrinsic]

#include <SFML\System.hpp>
#include "SFML Files\include\SFML\Window.hpp"
#include "SFML Files\include\SFML\Graphics.hpp"

Any particular reason why Window and Graphics were included differently from System?

I don't really have a reason why I included them differently.

I understand that FloatRect is just a typedef for Rect<float>, but I will use the constructor from now on.
I didn't realize the Mouse class had static members, so I've fixed that.

But now I have a problem and I don't feel like this would be the right place to post it.
the condition

if (tileRect.contains(relativePosition))

won't return true.

Here's the full thing:
http://pastebin.com/CsuwnrP5

Thanks for the tips.

[Hapax]

It doesn't return true because relativePosition never changes. You need to update relative position each frame; the position must still be mapped each time.

(click to show/hide)

You can just move this line:

sf::Vector2f relativePosition = window.mapPixelToCoords(sf::Mouse::getPosition(window));

to just before (or just after if you prefer) the window.clear() line.

[intrinsic]

Thanks for the help Hapax.

Would a better name for relativePosition be cursorCoords or even cursorPosition?

[Hapax]

I would (and often do) call it mousePosition. It makes sense: mousePosition = mouse::getPosition()...

And you're very welcome

[intrinsic]

Did a little more work with vectors and iterators.
Here's what I got so far:

http://pastebin.com/WzvUrErk

What I want to do next is automate the vector.push_back process with a loop and use the new keyword to create sprites and Rect's

[intrinsic]

I'm really diggin' this engine!
Now i gotta decide what type of classes I want to build for all this code.

Latest revision of my first SFML program:
http://pastebin.com/zkmLaVpk

I'm really happy with the window.draw() code

for (auto iter = spriteContainer.begin(); iter != spriteContainer.end(); iter++)
        {
            window.draw(**iter);
        }

As always I'm open to suggestions.
Thanks!

[Hapax]

Is there a reason for the double asterisk (**iter)? Nevermind. I just realised that your container stores pointers and not sprites

If you're using C++11 or later, you can draw your container of pointers much simpler:

for (auto& sprite : spriteContainer)
    window.draw(*sprite);

(if your container stored actual sprites, the asterisk wouldn't, of course, be necessary)

[intrinsic]

I read about this loop type in C++ primer 5th edition(C++11).
Is it called a for each loop?

[Hapax]

It can be considered a for each loop, as it works that way (for each item in the container, it runs the code block).

However, it's called a range-based for loop.

C++ does have an actual for_each, which is a different thing.

[intrinsic]

Thanks I'll review my book and re-read those portions.

[Evan Bowman]

Is there a reason for the double asterisk (**iter)? Nevermind. I just realised that your container stores pointers and not sprites

If you're using C++11 or later, you can draw your container of pointers much simpler:

for (auto& sprite : spriteContainer)
    window.draw(*sprite);

(if your container stored actual sprites, the asterisk wouldn't, of course, be necessary)

Worth considering that this creates an lvalue reference to each element (8 bytes on a 64 bit machine), where each element is a pointer (the exact same size), so getting the elements by value would be just fine here.

(click to show/hide)

To clarify, this would be negligibly faster, by saving you some dereference instructions:

for (auto/*&*/ sprite : spriteContainer) {
    window.draw(*sprite);
}
 

Some better alternatives to using new and delete would be using smart pointers (look at std::unique_ptr), or just pushing back the actual sprites. In fact, since you know the size of the vectors at compile time you may be better off using an array. std::array is nice and bounds checked, and also compatible with range based loops

[Hapax]

getting the elements by value would be just fine here.

True. I wrote this code assuming the container contained the actual sprites (so used the reference) and then modified it to dereference the pointer and the auto reference got left.

Some better alternatives to using new and delete would be using smart pointers (look at std::unique_ptr), or just pushing back the actual sprites. In fact, since you know the size of the vectors at compile time you may be better off using an array. std::array is nice and bounds checked, and also compatible with range based loops

I totally agree that unique_ptr should be used instead of raw news and deletes. Pushing the actual sprites would be my choice though; they're tiny and most likely don't need to be on the heap.

There doesn't seem to be any benefit to using std::array instead of std::vector here. Both are equivalent really with vector having more flexibility if something changes.