SFML! Is alright...

[ResidentBiscuit]

Decided to grab SFML again, but this time for my Linux box. Anyway, after grabbing the latest 2.0-rc, unpacking in the right area, getting the OpenGL dependencies (I could have sworn Ubuntu came default with these, but whatever) I got more issues. Not with linking, but with the damn example Laurent has on his 2.0 set up page -_- All sorts of "x is not member of Y" or "No such function foo() in Y". Like what the shit, if you're gonna write a program for testing to see if your product is set up correctly, at least make sure the damn thing compiles. Ugh, rant over. I'm gonna go write my own SFML test, damnit.

[Disch]

I think the API changed greatly halfway through SFML2.0 development. I know one thing that changed was he switched to camelCase for function names. Maybe he just didn't get around to updating all the tutorials to reflect those changes?

[darkestfright]

One of the major reasons that it's still in RC is because the documentation isn't finished yet. I still used the examples as a Guideline but rely on Intellisense when the documentation is incomplete.

[ResidentBiscuit]

I'm using Emacs, so no intellisense for me -_- I know the API changed a good deal, and I'm sure most of these are just formatting changed and he copy pasta'd an old test program now they don't compile. But as a user, I expect an API's test program to be compil-able.

And the whole 1.6 vs 2.0 thing is annoying. How long has 2.0 not been officially out?? A year? Two? But he commonly states that, "Hey, 1.6 is way out of date. Use 2.0". Alright dude, that would be awesome and all but maybe update your crap to reflect how to use 2.0. Not just copy pasta the 1.6 stuff over and hope it works, even though you wrote it and know it won't work!

[darkestfright]

I'm using Emacs, so no intellisense for me

You poor soul.

[Athar]

I'm using Emacs

That's a problem you can easily fix yourself at any time.

[ResidentBiscuit]

When I first got Emacs, I read that it was pretty much the rival of Vi/m. I figured it would be good. -_-

[ResidentBiscuit]

After digging around my directories and looking at the source, I got the feeling that my include paths were pointing in the wrong direction. I unpacked everything in usr/local/SFML2.0. In the program however it points at just SFML/Header.hpp. Now there is an SFML directory, but it's at /usr/local/SFML2.0/include/SFML/, so I put that in the include path. That changed my error, now I get errors from the header I'm including, saying it can't find a file that exists in the same directory. For example, I'm currently only using Window.hpp, in my program I have the include path set to:
#include </usr/local/SFML-2.0/include/SFML/Window.hpp>

(For some reason there is two Window.hpp's residing in different directories. I think originally I was pointed to the first one which had no members or data defined, just a bunch of other includes)

Window.hpp includes several files, the first 6ish are all in the same directory. The file it can't find is ContextSettings.hpp, which is includes like:

<SFML/Window/ContextSettings.hpp>

This is interesting because for one, it's in the same damn directory. Two, the file right above and below this one (the next 4 or so actually) are all also in the same directory and it has no problems finding them. So, basically I'm lost here. I'm not too sure why none of this working for me. I'm gonna eat lunch and hopefully have a solution figured out. Chances are, it's something really basic and small I'm doing wrong.

[naraku9333]

And the whole 1.6 vs 2.0 thing is annoying. How long has 2.0 not been officially out?? A year? Two? But he commonly states that, "Hey, 1.6 is way out of date. Use 2.0". Alright dude, that would be awesome and all but maybe update your crap to reflect how to use 2.0. Not just copy pasta the 1.6 stuff over and hope it works, even though you wrote it and know it won't work!

I would assume Laurent feels his time is better spent on the API itself, he is only one person after all. Heres an example that should run in case you still need it

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


int main()
{
    // Create the main window
    sf::RenderWindow window(sf::VideoMode(800, 600), "SFML window");
 
    // Load a sprite to display
    sf::Texture texture;
    if (!texture.loadFromFile("Images//sfml2.png"))
	{
		return EXIT_FAILURE;
	}   
	sf::Sprite sprite(texture);
    sf::Text text("Hello SFML");
 
    
    // Start the game loop
    while (window.isOpen())
    {
        // Process events
        sf::Event event;
        while (window.pollEvent(event))
        {
            // Close window : exit
            if (event.type == sf::Event::Closed)
			{
                window.close();			 
			}
        }
		if(sf::Keyboard::isKeyPressed(sf::Keyboard::Escape))
		{
			window.close();
		}
		
        // Draw the sprite
		window.draw(text);
        window.draw(sprite);
		
        // Update the window
        window.display();
    }
	
    return EXIT_SUCCESS;
}

You'll need to change the name and path of the image file.

[naraku9333]

I believe you should have the .../include directory in the PATH but not .../include/SFML

[ne555]

> I unpacked everything in usr/local/SFML2.0
¿why? Use /usr/local/include (or simply /usr/include )


Edit: @naraku9333 ¿two slashes?

[ResidentBiscuit]

Moving it to /usr/local/include leads to the same errors I was getting before. Using naraku's code also gives the same errors, just more of them. Here's a snippet of the errors:

/usr/include/SFML/Graphics/Color.hpp:40:16: note:   candidate expects 1 argument, 4 provided
sfml_test.cpp: In function ‘int main()’:
sfml_test.cpp:12:5: error: ‘Texture’ is not a member of ‘sf’
sfml_test.cpp:12:17: error: expected ‘;’ before ‘texture’
sfml_test.cpp:13:10: error: ‘texture’ was not declared in this scope
sfml_test.cpp:17:20: error: ‘texture’ was not declared in this scope
sfml_test.cpp:18:5: error: ‘Text’ is not a member of ‘sf’
sfml_test.cpp:18:14: error: expected ‘;’ before ‘text’
sfml_test.cpp:22:19: error: ‘class sf::RenderWindow’ has no member named ‘isOpen’
sfml_test.cpp:26:23: error: ‘class sf::RenderWindow’ has no member named ‘pollEvent’
sfml_test.cpp:29:23: error: ‘class sf::Event’ has no member named ‘type’

The first ~20 some odd errors are in the form of the first error I just pasted. The rest all "class X has no member Y".

[Athar]

This is interesting because for one, it's in the same damn directory.

Well, the include does not refer to the same directory, it refers to SFML/Window/..., a subdirectory.
You need to properly specify the include path via -I (e.g. /usr/local/SFML-2.0/include).
Purge libsfml-dev if you've installed it, so you don't accidentally end up including SFML 1.6 headers (which is probably exactly what is happening right now).

[ResidentBiscuit]

Purge libsfml-dev

SOB... I totally forgot I installed libsfml last week, and then realized it was 1.6 but never deleted it. That would explain these errors, I figured it was something stupid of me.

[ne555]

To clarify, you've got /usr/local/include/SFML/Window.hpp ¿right?
You could test with

$ g++ -I/whatever/you/put/the/SFML/directory test.cpp -c

Wait... /usr/include/SFML/Graphics/Color.hpp:40:16: ¿what?

[ResidentBiscuit]

I just completely restarted. Purged libsfml-dev (should have already) and deleted everything from 2.0. Then I wget'd it again, and unpacked so I have /usr/local/include/SFML/<various headers and directories for headers>

Tried building again with naraku's example, and once again a ton of build errors. -I /dir/to/SFML doesn't help either (I shouldn't need to, since it's in /usr/local/include though, right?).

Wait... /usr/include/SFML/Graphics/Color.hpp:40:16: ¿what?

Huh? Oh, I had a bunch of those. Like 20 or 30 of those types of errors. I just grabbed a random sample.

EDIT:
Not getting the same type of errors so I'll post a sample of them:

/usr/local/include/SFML/Graphics/Color.hpp:40:25: note: sf::Color::Color(const sf::Color&)
/usr/local/include/SFML/Graphics/Color.hpp:40:25: note:   candidate expects 1 argument, 4 provided
In file included from /usr/local/include/SFML/Graphics.hpp:40:0,
                 from sfml_test.cpp:2:
/usr/local/include/SFML/Graphics/RenderWindow.hpp:76:60: error: ‘Uint32’ has not been declared
In file included from /usr/local/include/SFML/Graphics.hpp:47:0,
                 from sfml_test.cpp:2:
/usr/local/include/SFML/Graphics/Text.hpp:146:19: error: ‘Uint32’ has not been declared
/usr/local/include/SFML/Graphics/Text.hpp:210:5: error: ‘Uint32’ does not name a type
/usr/local/include/SFML/Graphics/Text.hpp:290:5: error: ‘Uint32’ does not name a type

[L B]

My problem with SFML is that the debug DLLs crash and the release DLLs don't even link. Me and two other people have the same problem.

[ResidentBiscuit]

You're having the same issue as I? Because I'm about to give up on this. Second time trying to use SFML in the last year and neither time has gone well at all.

[Athar]

The error message sort of tells you what's wrong:

/usr/local/include/SFML/Graphics/Color.hpp ...
In file included from /usr/local/include/SFML/Graphics.hpp

Edit: actually it doesn't, I just can't read. Just make sure you only have one copy of the headers in the range of your include paths for the project - so either in /usr/include or /usr/local/include (the latter is preferred for things that weren't installed via the package manager).

I just tested naraku's example with SFML 2.0 RC, it compiles fine.

[ResidentBiscuit]

Then I don't know what the error is here. I have a feeling the message about data types is completely irrelevant...