SFML community forums

General => General discussions => Topic started by: Laurent on April 15, 2012, 02:43:31 pm

Title: SFML 2.0 RC
Post by: Laurent on April 15, 2012, 02:43:31 pm
SFML 2.0 Release Candidate (http://www.sfml-dev.org/download.php#2.0-rc) is ready!

Please try it, and report anything that should be fixed for the final release:

The tutorials are not ready yet (I'll now start to write them), so if you have no idea how to install and use this version, don't do it, wait for the final one instead.

The Linux version has no install script, you just have to copy the contents of the archive to your preferred install location (typically /usr/local). I'm still not sure what should be done for Linux packages:
There doesn't seem to be a "standard" way of packaging libraries for Linux.
Title: Re: SFML 2.0 RC
Post by: Nexus on April 15, 2012, 02:56:28 pm
Very nice! :)

Is the release candidate the same as the latest Git revision 19276a?
Title: Re: SFML 2.0 RC
Post by: Laurent on April 15, 2012, 03:01:32 pm
Quote
Is the release candidate the same as the latest Git revision 19276a?
It's the same as the revision tagged "2.0-rc". Which should be the latest one, yes.
Title: Re: SFML 2.0 RC
Post by: programmer47 on April 15, 2012, 05:01:44 pm
Not sure if this is a bug or something I'm doing wrong, but after I ran the Mac installer and created a new SFML project in Xcode, I tried to build it and got an error:
Code: [Select]
ld: library not found for -lsfml-system-d
Title: Re: SFML 2.0 RC
Post by: Hiura on April 15, 2012, 05:08:16 pm
haha the first error is on me!  :P

Go to your project build settings and at the bottom edit SFML_LINK_DYLIBS_SUFFIX to "" (empty). That's should do it.

(Project using frameworks are not affected by this issue.)
Title: Re: SFML 2.0 RC
Post by: Beuc on April 15, 2012, 05:46:11 pm
Nifty!

How do you plan work on porting to Android (https://github.com/SFML/SFML/issues/39)?

Actually I was experimenting with porting 1.6 to Android when I saw the announcement ;)
Title: Re: SFML 2.0 RC
Post by: programmer47 on April 15, 2012, 05:58:06 pm
haha the first error is on me!  :P

Go to your project build settings and at the bottom edit SFML_LINK_DYLIBS_SUFFIX to "" (empty). That's should do it.

(Project using frameworks are not affected by this issue.)
Thanks, works like a charm!
Title: Re: SFML 2.0 RC
Post by: Laurent on April 15, 2012, 06:09:22 pm
Quote
How do you plan work on porting to Android?
I have no plan yet. All I can say is that I'd like to work on it soon, maybe SFML 2.2.
Title: Re: SFML 2.0 RC
Post by: Groogy on April 15, 2012, 07:15:03 pm
Aaah this comes perfectly as I've just started to work on Ymir ^^
Now I can work more rapidly on it and make an awesome game in Ruby!

I'll be quite quick to let you know if I find anything :)
I have found some things when you do advanced stuff with OpenGL and threads but I expect they won't be fixed as I think you see it as outside the realm of SFML.
Title: Re: SFML 2.0 RC
Post by: DJuego on April 15, 2012, 11:58:09 pm
Congrats Laurent!   ;)

DJuego
Title: Re: SFML 2.0 RC
Post by: Deftwun on April 16, 2012, 06:50:35 am
I know there has been an issue with the sf::text constructor and the default font recently. Just downloaded the latest SFML release version (SFML-2.0-rc, debug libs, dynamic link) with codeblocks 10.05, Windows 7 and I get this error output to the console:

It repeats these two errors a total of 3 times...
Code: [Select]
An internal OpenGL call failed in Texture.cpp (146) : GL_INVALID_ENUM, an unacceptable value has been specified for an enumerated argument.
An internal OpenGL call failed in Texture.cpp (147) : GL_INVALID_ENUM, an unacceptable value has been specified for an enumerated argument.


Heres my code:
Code: [Select]
sf::Font mFont;
mFont.loadFromFile("fonts/arial.ttf");
sf::Text mText("Hello",mFont);

Its only when I initialize the sf::text or set the string it produces these errors. It will still draw and display correctly though. Just thought it might mean something.

Ps: love the new forum layout.
Title: Re: SFML 2.0 RC
Post by: Laurent on April 16, 2012, 07:57:28 am
This error implies that you have a crappy graphics card (or drivers) that don't support OpenGL 1.2. Is that true?
Title: Re: SFML 2.0 RC
Post by: Deftwun on April 16, 2012, 02:23:36 pm
I highly doubt it. Its an Nvidia Geforce Card (cant remember the model off the top of my head) thats only a a few years old. It will run just about any game I've thrown at it pretty well. I updated the drivers a couple months ago too. I will post the exact specs and version numbers later today when I get home. (I'll try running off the onboard graphics card as well)
Title: Re: SFML 2.0 RC
Post by: Laurent on April 16, 2012, 02:31:02 pm
Can you check the OpenGL version that your driver gives you?
sf::ContextSettings settings = window.getSettings();
std::cout << settings.majorVersion << "." << settings.minorVersion << std::endl;
Title: Re: SFML 2.0 RC
Post by: SoleSoul on April 16, 2012, 08:38:03 pm
Great news!
Thank you  :)
Title: Re: SFML 2.0 RC
Post by: Deftwun on April 16, 2012, 11:31:04 pm
You were correct Laurent. Apparently my drivers were not installed correctly so I was stuck with Opengl 1.1. I reinstalled my video drivers and I now have OpenGL 3.3. Error messages gone life is good. Sorry for the false alarm.
Title: Re: SFML 2.0 RC
Post by: eigenbom on April 17, 2012, 10:03:54 am
Hey awesome, well I'll be using this for Ludum Dare this weekend, so I'll let you know if I encounter any bugs! ;)

Good work Laurent and his minions/bug catchers!

Title: Re: SFML 2.0 RC
Post by: Laurent on April 17, 2012, 08:59:01 pm
The tutorial for OS X / XCode is online
http://www.sfml-dev.org/tutorials/2.0/start-osx.php
Title: Re: SFML 2.0 RC
Post by: Hiura on April 17, 2012, 09:13:56 pm
The tutorial for OS X / XCode is online
http://www.sfml-dev.org/tutorials/2.0/start-osx.php

This is also a RC of the tutorial. Tell me if something that is not clear enough, should be developed, added, removed, ...

There is no french version yet; I'll write it after you gave me some feedback on this first draft.
Title: Re: SFML 2.0 RC
Post by: mchung on April 17, 2012, 10:05:02 pm
    // Create the window with the OpenGL 3.2 Context.
    window = new sf::Window(sf::VideoMode(800,600,32),"RadiumCoreCross",sf::Style::Close,sf::ContextSettings(24,8,4,3,2));
    std::cout << "OpenGL Version" << window->getSettings().ContextSettings::majorVersion << "." << window->getSettings().ContextSettings::minorVersion << std::endl;
    sf::ContextSettings settings = window->getSettings();
    std::cout << settings.majorVersion << "." << settings.minorVersion << std::endl;

It appears on osx lion where 3.2 opengl is supported the context isn't being set to 3.2 but rather 2.1 opengl instead?

Is 3.2 opengl supported for SFML 2.0 ?
Title: Re: SFML 2.0 RC
Post by: Hiura on April 17, 2012, 10:26:25 pm
OGL 3.2 is not supported on Mac. (https://github.com/SFML/SFML/issues/84)
Title: Re: SFML 2.0 RC
Post by: mchung on April 17, 2012, 10:31:03 pm
http://www.g-truc.net/post-0411.html

That is incorrect OGL 3.2 is supported and I have used GLFW to render with it. I am on OSX Lion 10.3 of course. My guess is that this SFML does not support 3.2 for OSX Lion.
Title: Re: SFML 2.0 RC
Post by: Hiura on April 17, 2012, 10:31:56 pm
did you click on the link I gave above and read the text ?  ;)
Title: Re: SFML 2.0 RC
Post by: mchung on April 17, 2012, 10:35:00 pm
Yeah I did 5 seconds ago haha thanks, awww man I really wanted to use 3.2 I guess Ill have to wait then =(
Title: Re: SFML 2.0 RC
Post by: Nexus on April 18, 2012, 11:54:04 am
Laurent, some time ago (http://en.sfml-dev.org/forums/index.php?topic=4646.msg48312#msg48312) you wanted to rename the CMake variable SFMLDIR to SFML_ROOT in order to avoid confusion with other (CMake-proposed) variables like SFML_DIR. Is that still a topic?
Title: Re: SFML 2.0 RC
Post by: Laurent on April 18, 2012, 12:28:22 pm
Quote
Laurent, some time ago you wanted to rename the CMake variable SFMLDIR to SFML_ROOT in order to avoid confusion with other (CMake-proposed) variables like SFML_DIR. Is that still a topic?
Yes, I'll probably do that for the final 2.0 release (I have other CMake renaming to do).
Title: Re: SFML 2.0 RC
Post by: Chuckleluck on April 18, 2012, 04:46:36 pm
SFML 2!?

(http://images1.wikia.nocookie.net/brookproves/ca/images/a/a1/Awww_yeah.jpg)
Title: Re: SFML 2.0 RC
Post by: Laurent on April 18, 2012, 08:48:48 pm
Quote
Laurent, some time ago you wanted to rename the CMake variable SFMLDIR to SFML_ROOT in order to avoid confusion with other (CMake-proposed) variables like SFML_DIR. Is that still a topic?
Done.
Title: Re: SFML 2.0 RC
Post by: Serapth on April 19, 2012, 01:38:47 am
Does the move to SFML 2.0 decouple the OpenGL window stuff ( AKA, is it easier to port to ES 2)?

Regardless, congrats.
Title: Re: SFML 2.0 RC
Post by: Laurent on April 19, 2012, 07:54:39 am
Yes, absolutely. But there are still important modifications left to do before SFML is 100% ready to be ported to OpenGL ES 2.
Title: Re: SFML 2.0 RC
Post by: JohnStabler on April 19, 2012, 01:32:55 pm
This is great news. I'll be downloading and testing the .NET version 2.0 RC tonight. I'll probably use it in my current project.

Thanks Laurent
Title: Re: SFML 2.0 RC
Post by: Laurent on April 19, 2012, 09:20:43 pm
The Code::Blocks tutorial is online :)
Title: Re: SFML 2.0 RC
Post by: Laurent on April 20, 2012, 11:21:28 pm
The Visual Studio tutorial is now online too.
Title: Re: SFML 2.0 RC
Post by: Groogy on April 20, 2012, 11:27:55 pm
Do you want a "SFML and Ruby" tutorial? In case you do what do you want it to contain?
Title: Re: SFML 2.0 RC
Post by: Laurent on April 21, 2012, 10:31:59 am
Quote
Do you want a "SFML and Ruby" tutorial? In case you do what do you want it to contain?
It's up to you. If you feel like Ruby users would need a tutorial then I can put one there, but you can also create your own website, or just put an HTML doc file in rbSFML packages, or nothing at all.
Title: Re: SFML 2.0 RC
Post by: Laugilus on April 22, 2012, 07:41:08 pm
I have an issue, even if it's not a big deal. And maybe it's just due to my messy installation of SMFL.

When I launch the tutorial example :
Code: [Select]
#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode(300, 200), "SFML works!");
    sf::Text text("Hello SFML");

    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
        }

        window.clear();
        window.draw(text);
        window.display();
    }

    return 0;
}

I get a run-time error. The window appears properly and the text is well displayed. But when I close the window, I get a segfault error (-1073741823). Why is that ?
I'm on Windows 7 64-bits, and compile with gcc 4.6.something.

Thx and nice job!
Title: Re: SFML 2.0 RC
Post by: Laurent on April 22, 2012, 08:25:50 pm
Might be this one
https://github.com/SFML/SFML/issues/59
Title: Re: SFML 2.0 RC
Post by: kaB00M on April 22, 2012, 09:00:47 pm
Hi Laurent! I know this thread is for issues with 2.0, but I was wondering if this version 'fixes' the 'fps issues'  of 1.6?

Thank you.
Title: Re: SFML 2.0 RC
Post by: Laugilus on April 22, 2012, 09:21:17 pm
I'm not sure it's the same. I launched the do-not-crash example, and it crashes :)

Code: [Select]
#include <SFML/Graphics.hpp>

int main() {

sf::RenderWindow window(sf::VideoMode(300, 200), "SFML works!");

sf::Font fnt;
fnt.loadFromFile("C:/Windows/Fonts/ARABTYPE.ttf");

sf::Text text("Hello SFML");
text.setFont(fnt);

while (window.isOpen())
{
sf::Event event;
while (window.pollEvent(event))
{
if (event.type == sf::Event::Closed)
window.close();
}

window.clear();
window.draw(text);
window.display();
}

return 0;
}

Nevertheless, if I comment some lines, it works (if I don't draw the text)
Code: [Select]
#include <SFML/Graphics.hpp>

int main() {

sf::RenderWindow window(sf::VideoMode(300, 200), "SFML works!");

sf::Font fnt;
fnt.loadFromFile("C:/Windows/Fonts/ARABTYPE.ttf");

// sf::Text text("Hello SFML");
// text.setFont(fnt);

while (window.isOpen())
{
sf::Event event;
while (window.pollEvent(event))
{
if (event.type == sf::Event::Closed)
window.close();
}

window.clear();
// window.draw(text);
window.display();
}

return 0;
}

I will investigate further when I have time. Btw I don't know whether this is the right place to talk about this, is it ?
Title: Re: SFML 2.0 RC
Post by: Laurent on April 22, 2012, 09:36:24 pm
Quote
I know this thread is for issues with 2.0, but I was wondering if this version 'fixes' the 'fps issues'  of 1.6?
What FPS issue?

Quote
I'm not sure it's the same. I launched the do-not-crash example, and it crashes
What's important with the no-crash code is that it assigns the text's font in the constructor, so that the default font never gets instanciated. Your code doesn't do that.
Title: Re: SFML 2.0 RC
Post by: kaB00M on April 22, 2012, 09:49:36 pm
Quote
What FPS issue?

The ones with .SetFramerateLimit(). My games vary a lot in some builds.
Title: Re: SFML 2.0 RC
Post by: Laugilus on April 22, 2012, 10:03:48 pm
My bad. I called the constructor with which you can load a font, and now it works perfectly fine. I guess it's the same problem then.
Title: Re: SFML 2.0 RC
Post by: Laurent on April 22, 2012, 10:07:26 pm
Quote
The ones with .SetFramerateLimit()
I'm not aware of any problem with that. Would you mind pointing me to the forum thread or issue that discusses it?
Title: Re: SFML 2.0 RC
Post by: kaB00M on April 22, 2012, 11:05:37 pm
Quote
You should try SFML 2, the implementation of timing functions have changed and is supposed to be more reliable.
http://en.sfml-dev.org/forums/index.php?topic=6854.0 (http://en.sfml-dev.org/forums/index.php?topic=6854.0)
Sorry, I guess I read this out of context.

The thing is, if I set the frame-limit to 60, I get different fps on different computers (below 60 in some), yet if I don't specify a limit, the fps goes 80's in all comps. Also, in some instances on my fastest comp, my fps goes up to 100's regardless of set frame-limit.

Maybe I'm running old version of 1.6? Is the one on http://www.sfml-dev.org/download.php (http://www.sfml-dev.org/download.php) the latest?
I'm using Code::Blocks.
Title: Re: SFML 2.0 RC
Post by: Laurent on April 23, 2012, 07:54:15 am
Quote
Maybe I'm running old version of 1.6? Is the one on http://www.sfml-dev.org/download.php the latest?
There is only one version of SFML 1.6 -- otherwise they would have different numbers ;)
Title: Re: SFML 2.0 RC
Post by: AdelR on April 23, 2012, 09:51:30 am
Hi! I wanted to try SFML but seeing the state of transition from 1.6 to 2.0 - wanted to ask. Are tutorials on site from 1.6 version up to date with current API? Or should i wait for them to be rewritten?
Title: Re: SFML 2.0 RC
Post by: Laurent on April 23, 2012, 10:10:09 am
The tutorials which are up to date are those in tutorials/2.0. Missing ones are being rewritten and will be uploaded as soon as they are ready.
Title: Re: SFML 2.0 RC
Post by: Cornstalks on April 23, 2012, 11:01:48 pm
Hi! I wanted to try SFML but seeing the state of transition from 1.6 to 2.0 - wanted to ask. Are tutorials on site from 1.6 version up to date with current API? Or should i wait for them to be rewritten?
Just a note that in general, it's not too hard to look at a 1.6 tutorial and the 2.0 documentation (the documentation for 2.0 is up to date, as far as I know), and figure out how to do the same thing in 2.0. Version 2.0 introduces a lot of changes/new things, but it's still good old SFML so things are still related.
Title: Re: SFML 2.0 RC
Post by: eigenbom on April 24, 2012, 05:19:45 am
Well I used SFML-2.0rc for the last 72 hours during Ludum Dare and it worked great. I used the Xcode installer and the Visual Studio 2010 binaries.

(And just in case you're interested, the game is here (http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=1695).)
Title: Re: SFML 2.0 RC
Post by: nulloid on April 24, 2012, 04:11:35 pm
IDK if it was posted/mentioned before, but I've noticed that in the CSFML binding, Graphics.h doesn't include SFML/Graphics/Sprite.h.
Title: Re: SFML 2.0 RC
Post by: Laurent on April 24, 2012, 05:35:53 pm
Quote
IDK if it was posted/mentioned before, but I've noticed that in the CSFML binding, Graphics.h doesn't include SFML/Graphics/Sprite.h.
Thanks!
Title: Re: SFML 2.0 RC
Post by: Foaly on April 26, 2012, 01:02:08 pm
I not really sure if it's a bug or if I'm doing something wrong, but when I called the isAvailable() member of SoundRecorder anywhere in my program, i get a segfault when my program finishes. My Debugger tells my the segfault happens in alcCloseDevice () (...myprogramdirectory...\bin\Debug\openal32.dll). here is some minimal code to reproduce it:
#include <SFML/Audio.hpp>
#include <iostream>
int main()
{
    // Check that the device can capture audio
    if (sf::SoundRecorder::isAvailable() == false)
    {
        std::cout << "Sorry, audio capture is not supported by your system" << std::endl;
        return EXIT_SUCCESS;
    }

    return 0;
}

edit: of course i am using the rc2 build and i am on a windows xp machine with codeblocks and gcc
Title: Re: SFML 2.0 RC
Post by: Laurent on April 26, 2012, 01:03:28 pm
Please check the task tracker before posting.

https://github.com/SFML/SFML/issues/30
Title: Re: SFML 2.0 RC
Post by: Foaly on April 26, 2012, 01:06:06 pm
I'm sorry... Of course I checked the issue pages before i posted, but only searched for SoundRecorder. My bad, I will look more carefully next time.
Title: Re: SFML 2.0 RC
Post by: Laurent on April 26, 2012, 01:45:19 pm
There's not a lot of issues for each module in the tracker, so instead of searching for a particular keyword you can just activate the module filter (ie. click on the module name in the tag list) and check the few issues associated to it. That's what I always to when I have do find an old issue :)
Title: Re: SFML 2.0 RC
Post by: CptZouglou on April 28, 2012, 05:55:28 pm
Well I used SFML-2.0rc for the last 72 hours during Ludum Dare and it worked great. I used the Xcode installer and the Visual Studio 2010 binaries.

(And just in case you're interested, the game is here (http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=1695).)

Hey nice game !
We used SFML too for the 72h compo at Ludum Dare: check it out !
http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=10655
Title: Re: SFML 2.0 RC
Post by: eXpl0it3r on April 28, 2012, 08:30:10 pm
We used SFML too for the 72h compo at Ludum Dare: check it out !
http://www.ludumdare.com/compo/ludum-dare-23/?action=preview&uid=10655

But you didn't use SFML 2rc or did you? Because I only get a blank command line window and then nothing happens which speaks for the typical ATI bug which is present in SFML 1.6.

As a side note, SFML projects (http://en.sfml-dev.org/forums/index.php?board=10.0) was specially created to present your games to the SFML community. So it would be nice to see an announcement there. ;)
Title: Re: SFML 2.0 RC
Post by: BMB on May 01, 2012, 05:22:44 pm
There is a problem when building static libraries with Mingw-w64 (32 and 64 versions). It is in the Macros.cmake file at lines 18-19:

Code: [Select]
            if(NOT ${lib} MATCHES ".*/.*")
                string(REGEX REPLACE "(.*)/bin/.*\\.exe" "\\1" STANDARD_LIBS_PATH "${CMAKE_CXX_COMPILER}")
                set(lib "${STANDARD_LIBS_PATH}/lib/lib${lib}.a")
            endif()

The problem is that the libs are split between a couple of directories. Specifically, in my 32-bit version, libopengl32.a, libgdi32.a, libwinmm.a and a few others are not in <mingw>/lib, but rather in <mingw>/i686-w64-mingw32/lib. This totally breaks the above code, which assumes they are in <mingw>/lib, and the make fails.
Title: Re: SFML 2.0 RC
Post by: Laurent on May 01, 2012, 06:12:20 pm
There are issues for that on the tracker.
Title: Re: SFML 2.0 RC
Post by: nulloid on May 01, 2012, 08:01:49 pm
Another bunch of buggies from CSFML: In the include files, sfCircleShape has _GetOrigin and _GetScale instead of their camelCase versions, and all of sfRectangleShape's functions suffer from the same problem.
Title: Re: SFML 2.0 RC
Post by: Laurent on May 01, 2012, 08:19:49 pm
Quote
Another bunch of buggies from CSFML: In the include files, sfCircleShape has _GetOrigin and _GetScale instead of their camelCase versions, and all of sfRectangleShape's functions suffer from the same problem.
Wow, there was in fact a lot of functions that were still using the old naming convention. I wonder why I didn't check using a regexp before.
Title: Re: SFML 2.0 RC
Post by: Teemperor on May 01, 2012, 11:44:49 pm
I don't know if this is a bug, but i found out sf::Keyboard::isKeyPressed() really slows down your programm if it is used every loop? I used it 5 times per gameloop and got ~10fps in the game. Now i changed to a Keyboard-Event-based input and i got 80-100 fps (on the same crappy netbook)? Found the issue with the valgrind profiler.

I know the event-based is the preffered way, but the other was more intuitive in my opinion.
Title: Re: SFML 2.0 RC
Post by: Laurent on May 02, 2012, 08:00:08 am
Quote
I don't know if this is a bug, but i found out sf::Keyboard::isKeyPressed() really slows down your programm if it is used every loop?
It's the first time that I hear about that. It would be interesting to know if other people experience this problem too.
Title: Re: SFML 2.0 RC
Post by: Paki Programmer on May 03, 2012, 12:31:48 am
Actually i found that to be true too...that exact line of code seemed to slow down my computer
Title: Re: SFML 2.0 RC
Post by: Laurent on May 03, 2012, 07:55:34 am
On which OS?
Title: Re: SFML 2.0 RC
Post by: Sonkun on May 05, 2012, 07:54:31 pm
It's just a personal opinion but I think the design of the sf::Shape part of the API is ugly and non-natural. Of course, I know nothing about the under layer (which is OpenGL) so I won't criticize. If SFML 2.0 is meant to be a widely used version, from my point of view, this should need a face-lifting before being released :)

When I say ugly, I'm talking about writing CircleShape, ConvexShape (which should be ConvexPoligon by the way) and RectangleShape. Theese name are long because of the substring "Shape" which make things ugly. Why don't you put everything in a namespace named sf::Shape ?

When I say non-natural, I'm talking about why RectangleShape doesn't inherit from ConvexShape because a rectangle is no more than a convex polygon. Why can't I move my RectangleShape's points anymore and - by the way - why have point's properties (color, outline color) disappeared ? I found them very useful. Now I would understand if this comes from a technical reason belonging to a layer below the SFML but it took interest in using sf::Shape. Why don't you add other shapes such sf::TriangleShape.

I just want the best for Simple and Fast Multimedia Library :)
Title: Re: SFML 2.0 RC
Post by: Nexus on May 05, 2012, 08:31:48 pm
When I say ugly, I'm talking about writing CircleShape, ConvexShape (which should be ConvexPoligon by the way) and RectangleShape. Theese name are long because of the substring "Shape" which make things ugly.
You have a quite... special understanding of ugly. sf::Shape::Rectangle is more beautiful because it is... hm, longer? Or do you always write using namespace as soon as you see a namespace?

Honestly, the names match their meaning perfectly. "Shape" is the base class, and "RectangleShape" is a specialized shape (namely a rectangle), so its name is standing to reason.

When I say non-natural, I'm talking about why RectangleShape doesn't inherit from ConvexShape because a rectangle is no more than a convex polygon.
Probably because some functions like setPointsCount() are not appropriate for a rectangle.

Why can't I move my RectangleShape's points anymore
You can, using setSize() and setPosition().

why have point's properties (color, outline color) disappeared ? I found them very useful.
There is now less confusion with global/point-local color. The special case of differently colorized points can still be achieved with sf::VertexArray.
Title: Re: SFML 2.0 RC
Post by: Sonkun on May 06, 2012, 01:39:40 am
When I say ugly, I'm talking about writing CircleShape, ConvexShape (which should be ConvexPoligon by the way) and RectangleShape. Theese name are long because of the substring "Shape" which make things ugly.
You have a quite... special understanding of ugly. sf::Shape::Rectangle is more beautiful because it is... hm, longer? Or do you always write using namespace as soon as you see a namespace?

Honestly, the names match their meaning perfectly. "Shape" is the base class, and "RectangleShape" is a specialized shape (namely a rectangle), so its name is standing to reason.

Finally you are right. Maybe because I'm used to write sf::Shape::Rectangle() to create my rectangle.

When I say non-natural, I'm talking about why RectangleShape doesn't inherit from ConvexShape because a rectangle is no more than a convex polygon.
Probably because some functions like setPointsCount() are not appropriate for a rectangle.

Why can't I move my RectangleShape's points anymore
You can, using setSize() and setPosition().
The reason may be about hardware acceleration but I can make a Rectangle using ConvexShape with wich I can move the point as I want. I thought I could use RectangleShape not to start from scratch when I want to make a parallelogram.


why have point's properties (color, outline color) disappeared ? I found them very useful.
There is now less confusion with global/point-local color. The special case of differently colorized points can still be achieved with sf::VertexArray.
I did not notice this class. How do I set a color ?
Title: Re: SFML 2.0 RC
Post by: Laurent on May 06, 2012, 09:08:15 am
Quote
The reason may be about hardware acceleration but I can make a Rectangle using ConvexShape with wich I can move the point as I want. I thought I could use RectangleShape not to start from scratch when I want to make a parallelogram.
You got the point: if you want to manipulate your rectangle as a convex polygon (change every point individually and eventually get a non-rectangle), use sf::ConvexShape. If you want to manipulate your rectangle as a rectangle (change size and position, and let SFML ensure that it will always be a rectangle), then use sf::RectangleShape.

Quote
I did not notice this class. How do I set a color ?
This class is the low-level layer of SFML. You construct your own vertices (a vertex is a 2D point with attributes: position, color and texture coordinates), and then you draw them as either points, lines, triangles or quads. So there's no global function that would work on your whole vertex array, instead you have to manage the points individually -- which is what you need, apparently.
Title: Re: SFML 2.0 RC
Post by: Teemperor on May 06, 2012, 06:08:42 pm
On which OS?

Sorry for the late reply. OS is Ubuntu 12.04 64bit on Intel Atom :).
Can i help solving this bug? I'll try to reproduce the bug on my other PC with 12.04 tomorrow.

I'm not sure but as far as i can remember, the most CPU time in KeyPressed was used in an other SFML-internal function which was called inside KeyPressed. I hope i can find the name of the function again.

I'll will post all results tomorrow evening :)
Title: Re: SFML 2.0 RC
Post by: Cornstalks on May 06, 2012, 11:24:10 pm
Quote
The reason may be about hardware acceleration but I can make a Rectangle using ConvexShape with wich I can move the point as I want. I thought I could use RectangleShape not to start from scratch when I want to make a parallelogram.
You got the point: if you want to manipulate your rectangle as a convex polygon (change every point individually and eventually get a non-rectangle), use sf::ConvexShape. If you want to manipulate your rectangle as a rectangle (change size and position, and let SFML ensure that it will always be a rectangle), then use sf::RectangleShape.
I just looked at the API docs, and I may have (probably have) missed something, but it may be nice to provide a function/operator to convert a RectangleShape into a ConvexShape (and similarly with a CircleShape). Quite a low-priority feature, I might say, but what do you think about this possibility?

I too think RectangleShape should inherit from ConvexShape, just because a rectangle is a convex shape. But I don't think it should inherit from ConvexShape in its current form, and I haven't given enough thought to this to propose any kind of clean alternative. I don't think it's a show-stopper though, so I'm not too concerned with it.
Title: Re: SFML 2.0 RC
Post by: Walker on May 07, 2012, 02:03:00 am
I can't tell if there is a reason for this or not. When you create an sf::CircleShape the origin is set as if it were at the top-left corner of a bounding box encasing the circle. I find it more intuitive to have the circle's origin at the centre of the circle.
Title: Re: SFML 2.0 RC
Post by: Laurent on May 07, 2012, 08:10:14 am
Quote
I just looked at the API docs, and I may have (probably have) missed something, but it may be nice to provide a function/operator to convert a RectangleShape into a ConvexShape (and similarly with a CircleShape). Quite a low-priority feature, I might say, but what do you think about this possibility?
Why woud one need such a feature?
And don't forget that shape classes are just helpers, you're free to create your own shapes, either derived from sf::Shape or even from scratch with vertex arrays. Don't be limited by SFML classes, they are just there to provide simple features for simple use cases.

Quote
I too think RectangleShape should inherit from ConvexShape, just because a rectangle is a convex shape.
So you're the kind of programmer that would make a Square class inherit from Rectangle? ;)
What you suggest is not possible. ConvexShape is less constrained than RectangleShape, so the latter would inherit functions that would be able to break its contract.

Quote
I can't tell if there is a reason for this or not. When you create an sf::CircleShape the origin is set as if it were at the top-left corner of a bounding box encasing the circle. I find it more intuitive to have the circle's origin at the centre of the circle.
This is a convention, all graphical entities in SFML have their origin in the top-left corner by default. It's easy to change that by calling setOrigin.
Title: Re: SFML 2.0 RC
Post by: Nexus on May 07, 2012, 10:31:49 am
Quote
I just looked at the API docs, and I may have (probably have) missed something, but it may be nice to provide a function/operator to convert a RectangleShape into a ConvexShape (and similarly with a CircleShape). Quite a low-priority feature, I might say, but what do you think about this possibility?
Why woud one need such a feature?
And don't forget that shape classes are just helpers, you're free to create your own shapes, either derived from sf::Shape or even from scratch with vertex arrays. Don't be limited by SFML classes, they are just there to provide simple features for simple use cases.
There are cases where one wants to construct a specialized shape, but after that, just use it generically as convex shape -- similar to the old factory functions that returned a single type. Thor contains such a function
sf::ConvexShape toConvexShape(const sf::Shape&);

It is not strictly necessary, but a little bit more convenient that sf::Shape pointers which have no value semantics. Although I could also use aurora::CopiedPtr<sf::Shape> to give them value semantics ;)

But if it's necessary for SFML, is a different question. At the moment I'm not even sure how much of the Shape functionality will remain in Thor -- some parts seem to be very specific, maybe I'll remove them or provide them as examples.


I too think RectangleShape should inherit from ConvexShape, just because a rectangle is a convex shape.
That's not the only criterion for inheritance, take a look at the Liskov Substitution Principle.
Title: Re: SFML 2.0 RC
Post by: Laurent on May 07, 2012, 10:36:21 am
Quote
There are cases where one wants to construct a specialized shape, but after that, just use it generically as convex shape
In this case it's not hard to use sf::CongexShape directly. Defining a circle's or rectangle's points manually is really straight-forward.
Title: Re: SFML 2.0 RC
Post by: Laurent on May 07, 2012, 10:47:35 am
... But I agree that the new shapes API is still not perfect. I can't change it now because SFML 2 is going to be released, but I'm already thinking about something that could replace it in the future.

However, we could work on solutions and provide them soon, for example in Thor if you're interested in improving this area. Later, some of these solutions could be integrated to SFML if they prove to be good enough (like boost and std ;D).

I don't know if it would be a good idea, that was just the monday morning suggestion :)
Title: Re: SFML 2.0 RC
Post by: Cornstalks on May 07, 2012, 03:48:02 pm
Quote
I just looked at the API docs, and I may have (probably have) missed something, but it may be nice to provide a function/operator to convert a RectangleShape into a ConvexShape (and similarly with a CircleShape). Quite a low-priority feature, I might say, but what do you think about this possibility?
Why woud one need such a feature?
It could be easier for creating custom convex shapes. That is, you could take a rectangle as a starting shape, and then slightly transform the points (so it's not a rectangle, but still a convex shape), rather than starting from scratch.

Quote
I too think RectangleShape should inherit from ConvexShape, just because a rectangle is a convex shape.
So you're the kind of programmer that would make a Square class inherit from Rectangle? ;)
What you suggest is not possible. ConvexShape is less constrained than RectangleShape, so the latter would inherit functions that would be able to break its contract.
Don't forget I said I wouldn't do this in its current form :) Doing so right now would certainly violate LSP. I suppose I'm thinking of a more component-based design for the shapes, where shape classes are created through composition of various attributes/capabilities. And I figure with a design like this, implementing it with inheritance would require a little less typing :D (plus allow polymorphic behavior, if done carefully, though I don't know if that's a worthwhile goal).

But I'm ok with the shapes API for now. It's not like these little details are going to stop me or anyone else from making a game. I'm just thinking out loud.
Title: Re: SFML 2.0 RC
Post by: Laurent on May 07, 2012, 03:57:49 pm
Quote
Don't forget I said I wouldn't do this in its current form
Any other form that I can think of doesn't involve inheritance. To me, the current design is the best that you can get if you want to keep inheritance: sf::Shape has all the common attributes plus functions to read points. Functions that set points (ie. that wouldn't fit in the RectangleShape class) are kept in ConvexShape only.

Quote
I suppose I'm thinking of a more component-based design for the shapes, where shape classes are created through composition of various attributes/capabilities. And I figure with a design like this, implementing it with inheritance would require a little less typing  (plus allow polymorphic behavior, if done carefully, though I don't know if that's a worthwhile goal).
If you have a precise idea of what this solution would look like, I'll be glad to hear more about it :)
Title: Re: SFML 2.0 RC
Post by: Nexus on May 07, 2012, 05:34:00 pm
I don't know if it would be a good idea, that was just the monday morning suggestion :)
Yes, it's a good idea in my opinion :)

I just don't really have an exact imagination of how I could improve it. The only thing I'm quite sure to leave in its current form is thor::ConcaveShape, I don't know however if it's a candidate for SFML because of its rather complex triangulation algorithm. And it doesn't inherit from sf::Shape, since the latter only supports convex shapes. thor::Arrow could also be useful to visualize vectors, but it's not integrated with sf::Shape either...

One approach consists of minimalizing the Thor Shape API for 2.0, and of adding features as soon as I've found a good way ;)
Title: Re: SFML 2.0 RC
Post by: nulloid on May 11, 2012, 01:34:29 am
In CSFML, SoundStream.h isn't #included in Audio.h (public headers). Also, in the same SoundStream.h, there are still CamelCase function names, but maybe it isn't necessary to report them, since you indicated you will use regexp. (Am I wrong?)
Title: Re: SFML 2.0 RC
Post by: Laurent on May 11, 2012, 07:59:56 am
Quote
In CSFML, SoundStream.h isn't #included in Audio.h (public headers). Also, in the same SoundStream.h, there are still CamelCase function names, but maybe it isn't necessary to report them, since you indicated you will use regexp. (Am I wrong?)
Have you checked the latest modifications on the repository?
Title: Re: SFML 2.0 RC
Post by: nulloid on May 12, 2012, 06:08:45 pm
Oh, hell, I forgot that. Thanks :)
Title: Re: SFML 2.0 RC
Post by: Foaly on May 14, 2012, 05:02:19 pm
I've been messing around a little more with the release candidate in the last days and I couldn't find anything that not yet on the issue tracker. Great job!

What's still left to be done before the final version is released?
Title: Re: SFML 2.0 RC
Post by: Laurent on May 14, 2012, 05:29:16 pm
Quote
What's still left to be done before the final version is released?
I must finish to write the tutorials.
Title: Re: SFML 2.0 RC
Post by: Sonkun on May 15, 2012, 11:08:29 pm
The documentation about events says "Depending on the type of event, the event instance will be filled with different parameters" but where to find more about how is filled an event when it's a precise type of event ? E.g: if the event type is sf::Event::Closed, how is the event filled ? The same question for the other seventeen one.
Title: Re: SFML 2.0 RC
Post by: Laurent on May 16, 2012, 07:30:38 am
It's not hard to find the matching member:
MouseButtonPressed/Released -> event.mouseButton
KeyPressed/Released -> event.key
...

Closed and a few others have no parameter (what would you expect?).

This is of course explained in detail in the tutorials.
Title: Re: SFML 2.0 RC
Post by: Sonkun on May 16, 2012, 05:29:07 pm
If this was explained, I wouldn't be here for asking :) I didn't expect anything special for events that are triggered when a window closes but as I'm writing a binding I wanted to be sure.
Title: Re: SFML 2.0 RC
Post by: Laurent on May 16, 2012, 10:11:28 pm
Quote
If this was explained, I wouldn't be here for asking
It's in the "Handling events" tutorial.
Title: Re: SFML 2.0 RC
Post by: Sonkun on May 18, 2012, 05:30:23 pm
Quote
If this was explained, I wouldn't be here for asking
It's in the "Handling events" tutorial.
It was implicitly said :) Maybe a line like "The other three events (Closed, LostFocus and GainedFocus) have, of course, no specific parameters" would have removed my doubt.

By the way, maybe there's a small error in the documentation, shouldn't sf::Text::getStyle() and sf::Text::setStyle() returns/takes a sf::Text::Style instead of Uint32 ? I'm saying that based of sf::Sotcket::bind() which returns a sf::Socket::Status, they are both an enumeration. It's been a long I haven't practiced my C++ so I may be wrong...
Title: Re: SFML 2.0 RC
Post by: Laurent on May 18, 2012, 06:35:36 pm
Quote
Maybe a line like "The other three events (Closed, LostFocus and GainedFocus) have, of course, no specific parameters" would have removed my doubt.
The new documentation will be much better :)

Quote
By the way, maybe there's a small error in the documentation, shouldn't sf::Text::getStyle() and sf::Text::setStyle() returns/takes a sf::Text::Style instead of Uint32 ?
No, because you can combine several styles. In C++, combining multiple items of an enum produces an integer, not a variable of the enum type.
Title: Re: SFML 2.0 RC
Post by: reta on May 19, 2012, 01:39:40 am
Hello,

I have a problem with the git version of CSFML, when I try to compile I get the error:

undefined reference to `sfWindow_setSize'

If I remove this function call, there isn't any error anymore, and the compilation succeed.
Title: Re: SFML 2.0 RC
Post by: Laurent on May 19, 2012, 07:55:13 am
The function exists, make sure that you use a rencent revision of CSFML, that you properly compiled it, and that you're not mixing with an older version.
Title: Re: SFML 2.0 RC
Post by: reta on May 20, 2012, 03:07:48 am
yes it is a recent version of the GIT, I downloaded/compiled it again just before posting.

and indeed it is a weird error, because the function is there, without any case error.

1.6 is also arround but I mouved it outside of /usr/lib, I put it in /usr/lib/sfml-1.6/ so if I don't provide this path it should not be found
(I also moved the 1.6 includes)

I have this error only with this particular function. And I have no idea why because it's there in the sources.
If I remove this function from my sources, there is no error.

I have not tryed yet to test from a more simple hello world example. I'll do tomorrow.
Title: Re: SFML 2.0 RC
Post by: Laurent on May 20, 2012, 09:11:48 am
I remember another user having a similar issue with sfImage_createMaskFromColor. The function is well defined and exported, but missing from the compiled libraries.
Title: Re: SFML 2.0 RC
Post by: reta on May 21, 2012, 06:01:08 pm
Hi,
It seems that there is a problem with sfMouse_getPosition() and sfMouse_setPosition().
It seems that it provides interaction with sfWindow but not with sfRenderWindow.

cheers
Title: Re: SFML 2.0 RC
Post by: Laurent on May 21, 2012, 10:23:58 pm
Indeed. That's a problem.
Title: Re: SFML 2.0 RC
Post by: MorleyDev on May 21, 2012, 11:34:35 pm
Hmm, interesting. Mostly playing around with some odd threading stuff here. I made a system where you have n threads (where n is the hardware concurrency), and the first available thread grabs any tasks that are pushed onto a concurrent fifo task queue and executes them.

Now, originally I had it written so one of those tasks was the final render pass, which does the drawing to an sfml window and the window.display(). The window inputs always happened on the main thread (which was separated from this task system by making it just wait for tasks and then run those tasks, letting other threads "jump into" the main thread for a bit, kinda inefficient but as a stopgap solution it worked).

This worked fine when I was running it with my integrated graphics card (NVIDIA Optimus technology defaulted to this for the unrecognised executable), regardless of how many threads I was using. However,when n was >= 5 (meaning 6 or more threads were in use, one main thread and 5 task threads) it'd render a few frames and then crash.

Modifying the code so both final render and input polling occurred on the main seemed to fix this problem so I'm putting it down under "nvidia opengl multithreading weirdness" and "you dolt, graphics cards are not meant to run on potentially different threads in the same program every render" and moving on.
Title: Re: SFML 2.0 RC
Post by: reta on May 22, 2012, 09:12:24 pm
Indeed. That's a problem.

Do you plan to resolve this for the 2.0 release ?
Title: Re: SFML 2.0 RC
Post by: Laurent on May 22, 2012, 11:31:42 pm
Quote
Do you plan to resolve this for the 2.0 release ?
I'll try.
Title: Re: SFML 2.0 RC
Post by: talanak on May 24, 2012, 06:05:11 am
Hi Laurent!

I've not been able to compile with <SFML/Network/Http.h> except if I make the change below in the header file.

Also Ftp.hpp and Http.hpp are in Network.hpp, but Ftp.h and Http.h are not in Network.h, so the patch below correct this too.


diff -Naur LaurentGomila-CSFML-bfebe0a/include/SFML/Network/Http.h CSFML_git_2012-05-24/include/SFML/Network/Http.h
--- LaurentGomila-CSFML-bfebe0a/include/SFML/Network/Http.h     2012-05-22 17:56:01.000000000 +0200
+++ CSFML_git_2012-05-24/include/SFML/Network/Http.h    2012-05-24 05:55:57.000000000 +0200
@@ -37,19 +37,19 @@
 /// \brief Enumerate the available HTTP methods for a request
 ///
 ////////////////////////////////////////////////////////////
-enum sfHttpMethod
+typedef enum
 {
     sfHttpGet,  ///< Request in get mode, standard method to retrieve a page
     sfHttpPost, ///< Request in post mode, usually to send data to a page
     sfHttpHead  ///< Request a page's header only
-};
+} sfHttpMethod;
 
 
 ////////////////////////////////////////////////////////////
 /// \brief Enumerate all the valid status codes for a response
 ///
 ////////////////////////////////////////////////////////////
-enum sfHttpStatus
+typedef enum
 {
     // 2xx: success
     sfHttpOk        = 200, ///< Most common code returned when operation was successful
@@ -78,7 +78,7 @@
     // 10xx: SFML custom codes
     sfHttpInvalidResponse  = 1000, ///< Response is not a valid HTTP one
     sfHttpConnectionFailed = 1001  ///< Connection with server failed
-};
+} sfHttpStatus;
 
 
 ////////////////////////////////////////////////////////////
diff -Naur LaurentGomila-CSFML-bfebe0a/include/SFML/Network.h CSFML_git_2012-05-24/include/SFML/Network.h
--- LaurentGomila-CSFML-bfebe0a/include/SFML/Network.h  2012-05-22 17:56:01.000000000 +0200
+++ CSFML_git_2012-05-24/include/SFML/Network.h 2012-05-24 05:55:20.000000000 +0200
@@ -30,6 +30,8 @@
 ////////////////////////////////////////////////////////////
 
 #include <SFML/System.h>
+#include <SFML/Network/Ftp.h>
+#include <SFML/Network/Http.h>
 #include <SFML/Network/IpAddress.h>
 #include <SFML/Network/Packet.h>
 #include <SFML/Network/SocketSelector.h>
 
Title: Re: SFML 2.0 RC
Post by: Laurent on May 24, 2012, 07:53:40 am
Thanks :)
Title: Re: SFML 2.0 RC
Post by: Bread on May 28, 2012, 10:19:34 am
Hey Laurent,

Is there a problem with the server that is hosting the C++ RC 2.0 files?

I'm getting literally <500 bytes/second.

Thanks,
Bread
Title: Re: SFML 2.0 RC
Post by: Laurent on May 28, 2012, 10:37:04 am
There's no known problem. I just tried to download something and got more than 1 MB/s.
Title: Re: SFML 2.0 RC
Post by: Bread on May 28, 2012, 10:45:12 am
Ok, it must be something on my end.. other networks seem to be downloading it fine.

Thanks for the quick reply! I'm looking forward to making these forums my home haha.
Title: Re: SFML 2.0 RC
Post by: kaB00M on May 29, 2012, 01:19:22 am
No flip function for the Sprite class?  :'(
Title: Re: SFML 2.0 RC
Post by: Cornstalks on May 29, 2012, 04:28:38 am
No flip function for the Sprite class?  :'(
I'm pretty sure you can scale by negative amounts to flip. So sprite.setScale(1.0f, -1.0f) would be a flip along the x-axis.
Title: Re: SFML 2.0 RC
Post by: kaB00M on May 30, 2012, 01:19:31 am
Quote
I'm pretty sure you can scale by negative amounts to flip. So sprite.setScale(1.0f, -1.0f) would be a flip along the x-axis.

Yep! ;) Thank you. Always used the FlipX in 1.6.
Title: Re: SFML 2.0 RC
Post by: soro on June 05, 2012, 09:01:20 pm
Hi,

There is a problem with this funciton:

void sfPacket_readString(sfPacket* packet, char* string);

You may argue that the application should know what is the buffer size needed, but a malicious peer may send a bigger string, which will make the game server segfault.

Here is a test case that produces such a segmentation fault:

#include <stdio.h>
#include <stdlib.h>
#include <SFML/Network/Packet.h>

int main()
{
    char *buf = "+++";
    sfPacket *p = sfPacket_create();
    sfPacket_writeString(p, "0123456789ABCDEF");
    sfPacket_readString(p, buf);
    printf("BUF: %s\n", buf);
    sfPacket_destroy(p);
    return 0;
}

There are one parameter missing and a returned value missing.

It should be something like:

int sfPacket_readString(sfPacket* packet, char* string, int length);

We need a parameter length that tells the size of the buffer string provided, and the function should not try to fill more than that in oreder to prevent the segmentation fault.

We also need a returned value telling how many bytes where filled into the buffer, because if the buffer is of a larger size (for exemple 1024) and the function fills a smaller amount (for exemple 30), we need that value to extract the actual chunk. Using the NULL C string terminator is not enough / is not always a good method.
Title: Re: SFML 2.0 RC
Post by: Ceylo on June 05, 2012, 09:25:23 pm
https://github.com/SFML/SFML/issues/117
Title: Re: SFML 2.0 RC
Post by: kaB00M on June 22, 2012, 02:39:01 am
Any Randomizer alternative?
Title: Re: SFML 2.0 RC
Post by: eXpl0it3r on June 22, 2012, 02:52:29 am
Any Randomizer alternative?

std::rand (http://www.cplusplus.com/reference/clibrary/cstdlib/rand/) & std::srand (http://www.cplusplus.com/reference/clibrary/cstdlib/srand/)
Title: Re: SFML 2.0 RC
Post by: Celtic Minstrel on June 22, 2012, 03:32:13 am
Or if you're using C++11, there's the <random> (http://en.cppreference.com/w/cpp/numeric/random) header. If you seed your random generator and require the same results on different platforms, you can't rely on rand(), but the <random> header should be consistent across platforms.

Of course, if you don't need repeatable random numbers, all that doesn't matter. ;)
Title: Re: SFML 2.0 RC
Post by: tAKi on June 23, 2012, 09:41:01 pm
Hi,
it seems there is an issue with the API 2.0.

I post it here, not in feature request because I have read that there will be no change in the API 2.0 until 3.0.

It seems that it is possible to plug several joypads into the same computer to play multiusers game because there is a joypadID field in the event structure, but it seems that there is no equivalent for mices!

With the SDL it is possible to handle one mouse for each player. So this is impossible with SFML ?
Title: Re: SFML 2.0 RC
Post by: Laurent on June 23, 2012, 10:51:57 pm
Quote
So this is impossible with SFML ?
Indeed. This feature is not implemented yet.

Quote
I have read that there will be no change in the API 2.0 until 3.0.
The API can't be broken, it must remain backward compatible. But it doesn't mean that new things cannot be added.
Title: Re: SFML 2.0 RC
Post by: tAKi on June 23, 2012, 11:28:24 pm
Quote
So this is impossible with SFML ?
Indeed. This feature is not implemented yet.

Quote
I have read that there will be no change in the API 2.0 until 3.0.
The API can't be broken, it must remain backward compatible. But it doesn't mean that new things cannot be added.

Sorry, I don't see how this could be added without breaking API compatibility?

Wouldn't it be better to add the mouseID field to the event struct, and the mouseID parameter to the sf::Mouse methods now (even if it's ignored at the beginning), so that it wouldn't break 2.0 API when we add this feature?
Title: Re: SFML 2.0 RC
Post by: Celtic Minstrel on June 24, 2012, 09:04:29 am
It might be nice to have an operator| for Rects.
Code: [Select]
template<typename Num> sf::Rect<Num> operator| (sf::Rect<Num> lhs, sf::Rect<Num> rhs) {
sf::Rect<Num> intersect;
if(!lhs.Intersects(rhs, &intersect)) return sf::Rect<Num>();
return intersect;
}

template<typename Num> sf::Rect<Num>& operator|= (sf::Rect<Num>& lhs, sf::Rect<Num>& rhs) {
lhs = lhs | rhs;
return lhs;
}

Using the set intersection operator makes sense for this context, and it's slightly different than the member function which returns a boolean rather than the intersecting rectangle. Of course, it's not that important, since these are global functions and therefore I can just do this myself if I need it. Just a random thought in passing.

(It'd also be nice to have a "contains" operator that takes a Rect and a Vector, but I can't think of a reasonably logical operator symbol to use for that one.)
Title: Re: SFML 2.0 RC
Post by: Nexus on June 24, 2012, 10:12:31 am
It is not obvious at all what operator| means in combination with rectangles, thus I recommend not to overload it.

Why do you call it "set intersection operator"? This one has the symbol ∩. If I had to choose the most appropriate C++ operator for set intersection, it would probably be & (because the intersection contains the elements that are in the first set and the second set) -- on the contrary, | would rather denote set union.
Title: Re: SFML 2.0 RC
Post by: Laurent on June 24, 2012, 10:19:31 am
Quote
Sorry, I don't see how this could be added without breaking API compatibility?
Adding a member to a struct, and an argument with default value to a function doesn't break API compatibility.
Title: Re: SFML 2.0 RC
Post by: Laurent on June 24, 2012, 03:30:52 pm
The sfml-window tutorials are online.
Title: Re: SFML 2.0 RC
Post by: Celtic Minstrel on June 24, 2012, 04:20:25 pm
Why do you call it "set intersection operator"? This one has the symbol ∩. If I had to choose the most appropriate C++ operator for set intersection, it would probably be & (because the intersection contains the elements that are in the first set and the second set) -- on the contrary, | would rather denote set union.
Huh. You're right, of course. (Duh.) Anyway, I think it's reasonably obvious that what operator& would mean for rectangles, since the logical and set operators are closely related, and documentation would clear up any confusion.

That said, I don't really care that much if it's added. It's just a thought thrown out.
Title: Re: SFML 2.0 RC
Post by: tAKi on June 25, 2012, 12:22:57 am
Quote
Sorry, I don't see how this could be added without breaking API compatibility?
Adding a member to a struct, and an argument with default value to a function doesn't break API compatibility.

So when you say that the 2.0 API should not be broken, you exclude the C API?
Title: Re: SFML 2.0 RC
Post by: Laurent on June 25, 2012, 07:57:51 am
Quote
So when you say that the 2.0 API should not be broken, you exclude the C API?
That's a good point. I don't know if I'm going to provide API compatibility for the C API, since its purpose is to be a base for other bindings and not a ready-to-use API for C programers.

But I can also find workarounds (like defining a new function for that extra argument), and clean them in SFML 3.
Title: Re: SFML 2.0 RC
Post by: kaB00M on June 30, 2012, 09:37:39 am
How can I compute fps in 2.0?  :-[
Thanks.
Title: Re: SFML 2.0 RC
Post by: Hiura on June 30, 2012, 09:43:00 am
what I get when I search for 'fps' : http://en.sfml-dev.org/forums/index.php?topic=8223.msg54975#msg54975 searching is fun! Do some. ;)
Title: Re: SFML 2.0 RC
Post by: Conan on July 05, 2012, 07:51:49 pm
just tried the RC, looks nice. Just one weird quirk:
i installed it into a custom directory.
however, when i set the PKG_CONFIG_PATH accordingly and try pkg-config --libs --cflags sfml-all
it shows the following:
-I/home/laurent/release/2.0-rc/sfml/SFML-2.0-rc/include  -L/home/laurent/release/2.0-rc/sfml/SFML-2.0-rc/lib -lsfml-system -lsfml-window -lsfml-graphics -lsfml-audio -lsfml-network 

alas, neither my name nor my user login is laurent, so i guess this directory is hardcoded somewhere.
Title: Re: SFML 2.0 RC
Post by: Laurent on July 05, 2012, 08:52:38 pm
Yeah, pkg-config files contain absolute paths, they mustn't be distributed. I didn't noticed it because these files were added by someone else.
Title: Re: SFML 2.0 RC
Post by: Celtic Minstrel on July 06, 2012, 12:19:02 am
I was browsing the git repository a little while ago (can't quite remember why) and noticed this (https://github.com/SFML/SFML/blob/master/src/SFML/Graphics/Arial.hpp). I may be wrong, but I was under the impression that distributing Arial without a licence is not allowed, and that looks suspiciously like distributing Arial.
Title: Re: SFML 2.0 RC
Post by: Laurent on July 06, 2012, 08:16:15 am
Interesting, I never thought about that. I should definitely find a free replacement. It's not clear whether I can take a GPL font or not, though.
Title: Re: SFML 2.0 RC
Post by: Celtic Minstrel on July 06, 2012, 09:04:04 am
Maybe an OFL font? I'm not sure really; I'm not a lawyer or anything.
Title: Re: SFML 2.0 RC
Post by: eXpl0it3r on July 06, 2012, 11:15:07 am
What about Bitstream Vera (https://en.wikipedia.org/wiki/Bitstream_Vera)?
The license states:

Quote from: gnome
Copyright

Copyright (c) 2003 by Bitstream, Inc. All Rights Reserved. Bitstream Vera is a trademark of Bitstream, Inc.

Permission is hereby granted, free of charge, to any person obtaining a copy of the fonts accompanying this license (“Fonts”) and associated documentation files (the “Font Software”), to reproduce and distribute the Font Software, including without limitation the rights to use, copy, merge, publish, distribute, and/or sell copies of the Font Software, and to permit persons to whom the Font Software is furnished to do so, subject to the following conditions:

The above copyright and trademark notices and this permission notice shall be included in all copies of one or more of the Font Software typefaces.

The Font Software may be modified, altered, or added to, and in particular the designs of glyphs or characters in the Fonts may be modified and additional glyphs or characters may be added to the Fonts, only if the fonts are renamed to names not containing either the words “Bitstream” or the word “Vera”.

This License becomes null and void to the extent applicable to Fonts or Font Software that has been modified and is distributed under the “Bitstream Vera” names.

The Font Software may be sold as part of a larger software package but no copy of one or more of the Font Software typefaces may be sold by itself.

THE FONT SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF COPYRIGHT, PATENT, TRADEMARK, OR OTHER RIGHT. IN NO EVENT SHALL BITSTREAM OR THE GNOME FOUNDATION BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, INCLUDING ANY GENERAL, SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF THE USE OR INABILITY TO USE THE FONT SOFTWARE OR FROM OTHER DEALINGS IN THE FONT SOFTWARE.

Except as contained in this notice, the names of Gnome, the Gnome Foundation, and Bitstream Inc., shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Font Software without prior written authorization from the Gnome Foundation or Bitstream Inc., respectively. For further information, contact: fonts at gnome dot org.
Title: Re: SFML 2.0 RC
Post by: Laurent on July 06, 2012, 12:08:02 pm
It looks too limited:
Quote
Vera itself covers only common punctuation and the Latin alphabet with some diacritics

DejaVu (https://en.wikipedia.org/wiki/DejaVu_fonts) seems to have a much wider glyph coverage.
Title: Re: SFML 2.0 RC
Post by: Marukyu on July 06, 2012, 01:38:35 pm
Speaking of a built-in default font, it would be nice to have an easy way (perhaps some sort of compilation flag) to build SFML-Graphics without including Arial.hpp (or DejaVu.hpp if it's changed to that), without having to manually comment it out everytime. I personally never use sf::Text, as I have my own class that renders bitmap text, so there is essentially >300 KB of useless data in the graphics dll.
Title: Re: SFML 2.0 RC
Post by: eXpl0it3r on July 06, 2012, 02:24:20 pm
DejaVu (https://en.wikipedia.org/wiki/DejaVu_fonts) seems to have a much wider glyph coverage.
Oh didn't think about the glyph coverage, yeah this looks good.

Speaking of a built-in default font, it would be nice to have an easy way (perhaps some sort of compilation flag) to build SFML-Graphics without including Arial.hpp (or DejaVu.hpp if it's changed to that), without having to manually comment it out everytime. I personally never use sf::Text, as I have my own class that renders bitmap text, so there is essentially >300 KB of useless data in the graphics dll.
It's one thing just to not include a file and it's another thing to prevent any crash due to the missing file.
Also we don't live in the 90s anymore where every single bit was important, so imho it doesn't hurt to include those 300kb, although some might not like it. ;)
I'm not sure but does it also get included when you link statically?
Title: Re: SFML 2.0 RC
Post by: Laurent on July 06, 2012, 06:56:00 pm
Can you tell us why these 300 KB are so important?
Title: Re: SFML 2.0 RC
Post by: Laurent on July 06, 2012, 07:10:23 pm
I added an issue on the tracker for the default font replacement.
Title: Re: SFML 2.0 RC
Post by: Marukyu on July 07, 2012, 11:30:48 am
Building without Arial.hpp makes libsfml-graphics.so 269 KB on my system, so the inclusion of a default font file does add quite some size bloat, looking at it in relative numbers (>100% of the original size). While in absolute numbers, ~300 KB may indeed not be that much, I imagine only a small number of people actually use it, as most of them actually want to switch to their preferred font or write a customized bitmap text renderer.
It looks more like a debug feature to me that is primarily used by people who want a quick prototype program without any other resources, but it is not really something anyone would use in a large-scale project. I actually was not even aware of its presence and always assumed SFML would fail to display text if you didn't load a ttf file, until I checked out the source code.
Title: Re: SFML 2.0 RC
Post by: Laurent on July 07, 2012, 05:14:07 pm
Although I agree with you, do you think it's worth making the API more complicated for this argument?
Title: Re: SFML 2.0 RC
Post by: Pakatius on July 08, 2012, 01:55:03 am
Hello,

While comparing Network/Http.hpp and Network/Http.h it seems some values are missing for sfHttpStatus enum:

diff -Naur LaurentGomila-CSFML-8e856b0.orig/include/SFML/Network/Http.h LaurentGomila-CSFML-8e856b0/include/SFML/Network/Http.h
--- LaurentGomila-CSFML-8e856b0.orig/include/SFML/Network/Http.h        2012-07-08 01:45:50.000000000 +0200
+++ LaurentGomila-CSFML-8e856b0/include/SFML/Network/Http.h     2012-07-08 01:48:19.000000000 +0200
@@ -56,6 +56,8 @@
     sfHttpCreated   = 201, ///< The resource has successfully been created
     sfHttpAccepted  = 202, ///< The request has been accepted, but will be processed later by the server
     sfHttpNoContent = 204, ///< Sent when the server didn't send any data in return
+    sfHttpResetContent   = 205, ///< The server informs the client that it should clear the view (form) that caused the request to be sent
+    sfHttpPartialContent = 206, ///< The server has sent a part of the resource, as a response to a partial GET request
 
     // 3xx: redirection
     sfHttpMultipleChoices  = 300, ///< The requested page can be accessed from several locations
@@ -68,12 +70,15 @@
     sfHttpUnauthorized = 401, ///< The requested page needs an authentification to be accessed
     sfHttpForbidden    = 403, ///< The requested page cannot be accessed at all, even with authentification
     sfHttpNotFound     = 404, ///< The requested page doesn't exist
+    sfHttpRangeNotSatisfiable = 407, ///< The server can't satisfy the partial GET request (with a "Range" header field)
 
     // 5xx: server error
     sfHttpInternalServerError = 500, ///< The server encountered an unexpected error
     sfHttpNotImplemented      = 501, ///< The server doesn't implement a requested feature
     sfHttpBadGateway          = 502, ///< The gateway server has received an error from the source server
     sfHttpServiceNotAvailable = 503, ///< The server is temporarily unavailable (overloaded, in maintenance, ...)
+    sfHttpGatewayTimeout      = 504, ///< The gateway server couldn't receive a response from the source server
+    sfHttpVersionNotSupported = 505, ///< The server doesn't support the requested HTTP version
 
     // 10xx: SFML custom codes
     sfHttpInvalidResponse  = 1000, ///< Response is not a valid HTTP one
Title: Re: SFML 2.0 RC
Post by: BMB on July 08, 2012, 07:44:45 am
Building without Arial.hpp makes libsfml-graphics.so 269 KB on my system, so the inclusion of a default font file does add quite some size bloat, looking at it in relative numbers (>100% of the original size). While in absolute numbers, ~300 KB may indeed not be that much, I imagine only a small number of people actually use it, as most of them actually want to switch to their preferred font or write a customized bitmap text renderer.
It looks more like a debug feature to me that is primarily used by people who want a quick prototype program without any other resources, but it is not really something anyone would use in a large-scale project. I actually was not even aware of its presence and always assumed SFML would fail to display text if you didn't load a ttf file, until I checked out the source code.

I second this. Though 300k may not be a lot, I just have this pet peeve on including anything I don't need. Just sort of an unexplained disgust.
Title: Re: SFML 2.0 RC
Post by: Laurent on July 08, 2012, 10:02:50 am
Quote
While comparing Network/Http.hpp and Network/Http.h it seems some values are missing for sfHttpStatus enum:
Since it can be added later without breaking the API, let's not discuss it in this thread ;)

Quote
I second this. Though 300k may not be a lot, I just have this pet peeve on including anything I don't need. Just sort of an unexplained disgust.
Feel free to suggest a solution to solve this "problem" :P
Title: Re: SFML 2.0 RC
Post by: Ceylo on July 08, 2012, 10:26:11 am
I second this. Though 300k may not be a lot, I just have this pet peeve on including anything I don't need. Just sort of an unexplained disgust.
Personally I really don't care about 300 KB and I find it very convenient to be able to display text without caring about loading a font, although I agree that in large projects I would probably use a custom font, but SFML isn't for large projects only.

If the proposed solution does not involve more complexity I've nothing against it.
Title: Re: SFML 2.0 RC
Post by: Marukyu on July 08, 2012, 11:47:06 am
I have no experience with automatic building tools and how to supply them with parameters. What would adding something like a checkbox to cmake to toggle a certain compiler flag that switches inclusion of Arial.hpp for a project involve? How would it complexify the API? If it's too complicated, then it's probably not worth the effort for the potentially saved memory, but I will still keep manually commenting it out everytime I update SFML (which I do quite frequently throughout development). Even a compilation flag/macro (#define SFML_NO_BUILTIN_FONT?) without any cmake-visible option would help speed up that process.
Title: Re: SFML 2.0 RC
Post by: eXpl0it3r on July 08, 2012, 12:22:16 pm
I have no experience with automatic building tools and how to supply them with parameters. What would adding something like a checkbox to cmake to toggle a certain compiler flag that switches inclusion of Arial.hpp for a project involve?
As I've stated before it's easy to exclude one file, but it's another thong to guarantee no crashes. Because you can't just remove it let all applications crash ugly if they try to use the default font and then blame the developer. One would implement a switch that changes more than just the exclusion.
Title: Re: SFML 2.0 RC
Post by: Laurent on July 08, 2012, 12:28:00 pm
Disabling it at compile time is not a good option. Because I would then have to disable Font::getDefaultFont as well, and that would end up in two different (and incompatible) SFML APIs depending on how one compiled it. And the default version would still have it enabled anyway.
Title: Re: SFML 2.0 RC
Post by: Marukyu on July 08, 2012, 03:31:46 pm
Ah well, it's probably not worth trying to find a clean solution to this then. I'll just keep manually removing it myself then, it's not a big deal.
Title: Re: SFML 2.0 RC
Post by: bastien on July 09, 2012, 06:24:04 am
I really like the Libertine fonts (http://www.linuxlibertine.org/) and they're free/libre/open source too.

Another license problem is that, as far as I can tell, you don't distribute the license with the binary dependencies. This is needed for the BSD license, for example.
Title: Re: SFML 2.0 RC
Post by: Laurent on July 09, 2012, 07:54:44 am
There's an issue on the tracker if you want to discuss free fonts further.

Quote
Another license problem is that, as far as I can tell, you don't distribute the license with the binary dependencies
I distribute a license.txt file, which contains a mention of every dependency and its license. But I think that I should put a direct link to the license text too.
Title: Re: SFML 2.0 RC
Post by: Pakatius on July 09, 2012, 03:39:06 pm
Quote
While comparing Network/Http.hpp and Network/Http.h it seems some values are missing for sfHttpStatus enum:
Since it can be added later without breaking the API, let's not discuss it in this thread ;)

Why you just don't apply the patch now?

If you apply it later, I'll have to update my code later...
Title: Re: SFML 2.0 RC
Post by: Laurent on July 09, 2012, 04:02:43 pm
Oh wait, I just understood that these values are in the C++ version but not in the C one.

I thought you wanted to add new codes, sorry.

I'll do it as soon as I can.
Title: Re: SFML 2.0 RC
Post by: Marukyu on July 09, 2012, 10:44:54 pm
I stumbled upon a problem while implementing an event-based remappable input system: SFML makes no distinction between unknown keypresses and "A" keypresses. While this might not be a big issue for QWERTY users, other keyboard layouts, particularly QWERTZ (which is what I am using) have lots of keys that are not correctly picked up by the sf::Window implementation and end up being incorrectly fired as "A" keypresses (specifically, the ÄÖÜß^<# keys on QWERTZ keyboards). I described the issue and a possible, hopefully non-API-breaking fix here (https://github.com/SFML/SFML/issues/7#issuecomment-6858248). It basically involves adding an extra key (sf::Keyboard::Unknown or something like that) to the sf::Keyboard::Key enum and replacing instances of the bottom-catcher "return Keyboard::Key(0);" (which happens to be "A") in the sf::Window implementations with "return Keyboard::Unknown;".

This is quite a big issue in my opinion, and any kind of temporary "quick fix" would be better than having no way to eliminate incorrectly fired "A"-key events.
Title: Re: SFML 2.0 RC
Post by: minirop on July 09, 2012, 10:48:15 pm
the « problem » is that :
    enum Key
    {
        A,            ///< The A key
nothing before so A == 0.
So something like :
    enum Key
    {
        Unknown,
        A,            ///< The A key
should be enough (?)
Title: Re: SFML 2.0 RC
Post by: Marukyu on July 09, 2012, 11:03:07 pm
Ah, good point. I guess it would still be a bit cleaner to replace Keyboard::Key(0) with Keyboard::Unknown though. I wouldn't only call it a "« problem »" though. :p
It is an issue that can limit the usefulness of KeyEvents quite a bit.
Title: Re: SFML 2.0 RC
Post by: Laurent on July 09, 2012, 11:31:39 pm
It is indeed a major problem. I added sf::Keyboard::Unknown as suggested to solve it.

Thank you very much for your feedback :)
Title: Re: SFML 2.0 RC
Post by: Marukyu on July 10, 2012, 12:13:21 am
Thank you very much for the fix! Glad I could help. :3
Title: Re: SFML 2.0 RC
Post by: Tank on July 11, 2012, 09:02:37 am
Can you tell us why these 300 KB are so important?
300 KB are not really important, but we can kill two birds with one stone here probably:

1) Get rid of 300 KB.
2) Get rid of default font crash bug.

Maybe you still remember my proposal from the past when I suggested to force the user to load a font. I really don't think that it would be complicated or annoying, it's as simple as:

sf::Font font;
font.loadFromFile( "foobar.ttf" );
sf::Text text( L"Hello", 12, font );

It's not the same, but you do it with images and sounds too, which is very reasonable. I still find it problematic that the library provides unmanaged resources.
Title: Re: SFML 2.0 RC
Post by: Laurent on July 11, 2012, 09:25:40 am
Yes, I remember this solution everytime there's an issue with the default font. And I admit that it seems to be the best one so far.

However if I change anything in the public API, it must be done before SFML 2.0 is released... so I must take a decision quickly :-\
Title: Re: SFML 2.0 RC
Post by: Tank on July 11, 2012, 10:39:57 am
Indeed. ;) The only thing which is a little bit more annoying is providing a standard font. I see 2 options here:

1) sf::Font::makeStandardFont: Returns a new sf::Font, font data is included in sources. Pro: Easy. Con: 300 KB extra, always.
2) sf::makeDejaVuFont: Returns a new sf::Font, font data is included in separate(!) header only. Pro: 300 KB extra only if being included, which is intended if someone does it (not included by SFML itself). Con: Annoying to use in-place, see below.

Option 2 would be for sure a compromise and still easy enough, I think. Ex:

#include <SFML/Graphics/DejaVuFont.hpp>
sf::Font font = sf::makeDejaVuFont();

A big drawback is the following, which is invalid:

sf::Text text( L"I will crash :-(", 12, sf::makeDejaVuFont() );

I can't think of a real solution to satisfy everybody, except shared resource management through smart pointers, but I'm sure you're already screaming right now. ;)
Title: Re: SFML 2.0 RC
Post by: binary1248 on July 11, 2012, 12:09:33 pm
I could live without a default built-in font. And since I'm too lazy to implement my own OS #ifdefs maybe there could be a sf::Font::loadSystemFont(sf::String) that looks for that font face in the system font directory? With clever use of environment variables it shouldn't be too hard :)
Title: Re: SFML 2.0 RC
Post by: Laurent on July 11, 2012, 01:06:01 pm
Quote
1) sf::Font::makeStandardFont: Returns a new sf::Font, font data is included in sources. Pro: Easy. Con: 300 KB extra, always.
2) sf::makeDejaVuFont: Returns a new sf::Font, font data is included in separate(!) header only. Pro: 300 KB extra only if being included, which is intended if someone does it (not included by SFML itself). Con: Annoying to use in-place, see below.
I like option 2. But then it becomes similar to providing the font file directly, the only difference is that with a header it is compiled directly into the final application. But then why not go further, and provide a generic system to embed any data into the application?

Quote
I can't think of a real solution to satisfy everybody, except shared resource management through smart pointers, but I'm sure you're already screaming right now.
Indeed :P
Smart pointers are not a big deal, but what's annoying is that they exist in C++11/TR1/boost, but as SFML has to remain compatible with pure C++03, I would have to rewrite it myself. But the name and API of the shared_ptr class would then be different. It's definitely too messy.

Quote
I could live without a default built-in font. And since I'm too lazy to implement my own OS #ifdefs maybe there could be a sf::Font::loadSystemFont(sf::String) that looks for that font face in the system font directory? With clever use of environment variables it shouldn't be too hard
That's a very interesting feature, and to be honest until now I avoided it only because there was a default font. But now, with the mentionned issues, I guess it would be a good moment for investigating that.

I'll take a look at Qt's source code, and see if the related code is not too complicated.
Title: Re: SFML 2.0 RC
Post by: Laurent on July 11, 2012, 01:10:30 pm
A drawback of the loadSystemFont solution is that it is impossible to guarantee that a given font will be available. Which leads to the "font family" system, ie. you give a more or less precise definition of the font that you want, with optional fallbacks, and the system finds the best match. It becomes already quite complicated.
Title: Re: SFML 2.0 RC
Post by: binary1248 on July 11, 2012, 06:20:37 pm
No no no... I didn't mean it to be that complicated. loadSystemFont should just be an extended version of loadFromFile that searches known paths automatically. Like loadFromFile it would return false if the font doesn't exist on the system. Passing an empty string (the default) to loadSystemFont would load the default font for the system, whatever you choose it to be.

This solution would work for 99.99% of the userbase of SFML.

Windows users are the easiest. All their fonts are in %WINDIR%/Fonts and they always have Arial installed if thats what you want as default.
Mac OS X users I presume have the same situation as Windows users.
Linux users, most of them use one of the popular distros, would also mostly have the same paths and font faces installed.
Title: Re: SFML 2.0 RC
Post by: Andrei15193 on July 11, 2012, 06:44:56 pm
the « problem » is that :
    enum Key
    {
        A,            ///< The A key
nothing before so A == 0.
So something like :
    enum Key
    {
        Unknown,
        A,            ///< The A key
should be enough (?)
A good option however it implies declaring another constant. Like you said:
#include <iostream>

enum TestEnum{a, b, c};

int main(){
    std::cout<<a<<" "<<b<<" "<<c<<std::endl;
    return 0;
}
Outputs: "0 1 2". However the following code fixes the issue for the enumeration start constant:
#include <iostream>

enum TestEnum{a = 1, b, c};

int main(){
    std::cout<<a<<" "<<b<<" "<<c<<std::endl;
    return 0;
}
Will output: "1 2 3". No extra constant required.

Docs: Other data types - C++ (http://www.cplusplus.com/doc/tutorial/other_data_types/).
Title: Re: SFML 2.0 RC
Post by: Laurent on July 11, 2012, 06:48:51 pm
Quote
A good option however it implies declaring another constant.
We want a new constant. sf::Keyboard::Unknown is much better than sf::Keyboard::Key(0), isn't it?

Quote
No no no... I didn't mean it to be that complicated. loadSystemFont should just be an extended version of loadFromFile that searches known paths automatically. Like loadFromFile it would return false if the font doesn't exist on the system. Passing an empty string (the default) to loadSystemFont would load the default font for the system, whatever you choose it to be.
I'm wondering is this is relevant. I mean, if I write an application and plan to distribute it, I won't rely on a specific font being present on the user's system. Instead I'll provide the font with my application for 100% safety.
So who would use this feature?
Title: Re: SFML 2.0 RC
Post by: Andrei15193 on July 11, 2012, 06:51:14 pm
Quote
A good option however it implies declaring another constant.
We want a new constant. sf::Keyboard::Unknown is much better than sf::Keyboard::Key(0), isn't it?
I thought you wanted the enum to start from 1 and not from 0.
Title: Re: SFML 2.0 RC
Post by: Laurent on July 11, 2012, 06:59:36 pm
Quote
I thought you wanted the enum to start from 1 and not from 0.
No we don't care. The problem to solve was that 'A' and unhandled keys had the same code.
Title: Re: SFML 2.0 RC
Post by: Andrei15193 on July 11, 2012, 07:04:20 pm
Quote
I thought you wanted the enum to start from 1 and not from 0.
No we don't care. The problem to solve was that 'A' and unhandled keys had the same code.
Oh, my bad
Title: Re: SFML 2.0 RC
Post by: binary1248 on July 11, 2012, 08:12:12 pm
I'm wondering is this is relevant. I mean, if I write an application and plan to distribute it, I won't rely on a specific font being present on the user's system. Instead I'll provide the font with my application for 100% safety.
So who would use this feature?
For the people who just want to see text you have the default whatever you define in SFML system font as a replacement for getDefaultFont() now. People who have an idea what font they might want on a specific system can either use the system font or specify their own. SFML should just make it easy to make use of the system fonts IF the user wants to.
Title: Re: SFML 2.0 RC
Post by: Laurent on July 11, 2012, 09:11:44 pm
Then I wonder if providing a default font still makes sense.
Title: Re: SFML 2.0 RC
Post by: binary1248 on July 11, 2012, 09:58:23 pm
It's not a question of if there should be a default font, but where the font data comes from :)
Title: Re: SFML 2.0 RC
Post by: exafi on July 12, 2012, 12:47:30 am
that you changed the style of the methods?
Before was better.

GetPos ...
  now
getPos ...

-1 to this


I used Google translate XDDDD
Title: Re: SFML 2.0 RC
Post by: Tank on July 12, 2012, 04:34:19 pm
Quote
I like option 2. But then it becomes similar to providing the font file directly, the only difference is that with a header it is compiled directly into the final application. But then why not go further, and provide a generic system to embed any data into the application?
The difference is that you don't have a global sf::Font object. Nobody's against global data (just make sure to declare it static const, so it won't be included X times in the binary).

I would even go one more step further and say: Why not a generic loading chain with changeable adapters for choosing which backend we want? (filesystem, archives, binary data in executable, HTTP) :) But that's definitely something for a later version, also the idea with generic embedded data.

However, having something like

font.load( sf::FileSystemAdapter( "foobar.ttf" ) );
font.load( sf::ZipAdapter( "foobar.ttf", "meow.zip" ) );
font.load( sf::HttpAdapter( "http://sfml-dev.org/resources/foobar.ttf" ) );
// Same for all the other load() functions, e.g. in sf::Image.
 

would be great and powerful. Maybe in SFML 4? ;-)

Quote
but as SFML has to remain compatible with pure C++03

Do you plan to drop that requirement for, let's say SFML 3?

Quote
Before was better.
...
-1 to this

-1337 for flaming. :)
Title: Re: SFML 2.0 RC
Post by: Laurent on July 12, 2012, 07:25:48 pm
Quote
font.load( sf::FileSystemAdapter( "foobar.ttf" ) );
font.load( sf::ZipAdapter( "foobar.ttf", "meow.zip" ) );
font.load( sf::HttpAdapter( "http://sfml-dev.org/resources/foobar.ttf" ) );
// Same for all the other load() functions, e.g. in sf::Image.
Isn't it the sf::InputStream system, which is already implemented in SFML 2?

Quote
Do you plan to drop that requirement for, let's say SFML 3?
I don't know, I guess it depends when SFML 3 is released ;)
At least I'll provide conditional support for C++11 in SFML 2 (there's an issue on the tracker for that).
Title: Re: SFML 2.0 RC
Post by: Tank on July 13, 2012, 01:51:45 pm
Isn't it the sf::InputStream system, which is already implemented in SFML 2?
Indeed, I wasn't aware of it.
Title: Re: SFML 2.0 RC
Post by: jPollock on July 14, 2012, 04:30:32 am
Hi, just the case of the setString method in sf::Text class.

diff -Naur LaurentGomila-SFML-396f675.orig/include/SFML/Graphics/Text.hpp LaurentGomila-SFML-396f675/include/SFML/Graphics/Text.hpp
--- LaurentGomila-SFML-396f675.orig/include/SFML/Graphics/Text.hpp      2012-07-13 12:09:11.000000000 +0200
+++ LaurentGomila-SFML-396f675/include/SFML/Graphics/Text.hpp   2012-07-14 04:25:41.000000000 +0200
@@ -86,10 +86,10 @@
     /// automatically be constructed from standard string types.
     /// So, the following calls are all valid:
     /// \code
-    /// text.SetString("hello");
-    /// text.SetString(L"hello");
-    /// text.SetString(std::string("hello"));
-    /// text.SetString(std::wstring(L"hello"));
+    /// text.setString("hello");
+    /// text.setString(L"hello");
+    /// text.setString(std::string("hello"));
+    /// text.setString(std::wstring(L"hello"));
     /// \endcode
     /// A text's string is empty by default.
     ///
 
Title: Re: SFML 2.0 RC
Post by: eXpl0it3r on July 14, 2012, 12:16:00 pm
Hi, just the case of the setString method in sf::Text class.
And? What are you trying to tell us with that? Or did I miss some talk about it? ???
Title: Re: SFML 2.0 RC
Post by: Hiura on July 14, 2012, 12:24:48 pm
He's pointing out typos in the doc.  (S -> s) ;)
Title: Re: SFML 2.0 RC
Post by: eXpl0it3r on July 14, 2012, 01:06:57 pm
He's pointing out typos in the doc.  (S -> s) ;)
Aha! I see! :D
Quite hard to spot if you don't know what to look for. ;)
Title: Re: SFML 2.0 RC
Post by: Laurent on July 14, 2012, 05:23:42 pm
Quote
Hi, just the case of the setString method in sf::Text class.
Thanks :)
Title: Re: SFML 2.0 RC
Post by: TheVirtualDragon on August 05, 2012, 06:06:32 pm
Hi, I just wanted to ask, is SFML 2.0 rc stable enough for use? As in, my application wont have too many problems?
Also, how many changes will there be between SFML 2.0 and 2.0rc? I am wondering because I don't want to have many changes when SFML 2.0 comes out and I link to it.
Title: Re: SFML 2.0 RC
Post by: eXpl0it3r on August 05, 2012, 06:22:13 pm
SFML 2.0rc is quite stable. The main part of the API is frozen and changes to the API will only happen if there's a really, really good reason for. So you can consider it as stable. The most recent bigger change was the removal of the default font. If you're using the SFML 2rc binaries just don't use the default font and you won't have to change a thing when SFML 2 finally gets released. (If that ever happens :P)

If you want to see what the changes are between the RC and the current state you can take a look at the commit history (https://github.com/SFML/SFML/commits/master) up to the 2.0-rc tag (https://github.com/SFML/SFML/tree/2.0-rc).
Title: Re: SFML 2.0 RC
Post by: mobai on September 05, 2012, 04:26:29 pm
I already asked in the chat and it looks like there's something between sfml and the drivers that doesnt work well...

The whole thing is explained here: http://en.sfml-dev.org/forums/index.php?topic=9074.0 (http://en.sfml-dev.org/forums/index.php?topic=9074.0)
Title: Re: SFML 2.0 RC
Post by: Foaly on September 06, 2012, 12:30:47 pm
I'm not sure, but i think i found an error in the documentation of sf::Shader...
If I create a shader like this:
sf::Shader shader;
shader.loadFromFile("Shader.frag", sf::Shader::Fragment);
and use it like it says in the documentation:
m_RenderTexture.draw(m_Circle, shader);
I get an error. It works when I do this:
m_RenderTexture.draw(m_Circle, &shader);

Same with the example that uses the renderstates. I have to pass the address not the value, like it says in the documentation.
Title: Re: SFML 2.0 RC
Post by: eXpl0it3r on September 06, 2012, 12:53:08 pm
m_RenderTexture.draw(m_Circle, &shader);
And that worked? :o

The draw function is taking the render states as reference, thus passing the adress to the function shouldn't work at all either...

See the two draw function declerations (http://www.sfml-dev.org/documentation/2.0/classsf_1_1RenderTarget.php#ab636d7363f6681077361ee274ba89a8d) and the header (https://github.com/SFML/SFML/blob/master/include/SFML/Graphics/RenderTarget.hpp#L197) to it.


Edit: I just now figured out how that all worked, since the documentation said that draw(obj, shader) is a short cut, but I couldn't see how it's being done, then I saw that the sf::RenderStates class has a constructor that takes a pointer to a sf::Shader and thus you indeed need to call draw(obj, &shader), which invokes that said constructor, creates a sf::RenderStates class and passes it as reference to the draw call. I don't know why the constructor takes pointers rather than references...
But if you use a RenderStates object yourself you shouldn't need to pass the adress. ;)
Title: Re: SFML 2.0 RC
Post by: Foaly on September 06, 2012, 01:03:04 pm
Yeah it works! Look closer :) Here is why: if you pass a shader the second argument to the draw function it is passed on to the constructor of the RenderStates, which has a constructor that takes a shader as a argument. Really nice shortcut :)

edit: But still, the constructor of the RenderStates only takes a pointer to a shader. So I think there is an error in the documentation.
Title: Re: SFML 2.0 RC
Post by: eXpl0it3r on September 06, 2012, 01:06:21 pm
Yeah it works! Look closer :) Here is why: if you pass a shader the second argument to the draw function it is passed on to the constructor of the RenderStates, which has a constructor that takes a shader as a argument. Really nice shortcut :)
Yep, noticed that myself... ;D

edit: But still, the constructor of the RenderStates only takes a pointer to a shader. So I think there is an error in the documentation.
Yep, it's a mistake, but I wonder why use a pointer instead of a reference?
Title: Re: SFML 2.0 RC
Post by: Foaly on September 06, 2012, 01:15:24 pm
Yep, noticed that myself... ;D
Yeah it is kinda tricky, but a really cool shortcut!
Yep, it's a mistake, but I wonder why use a pointer instead of a reference?
I haven't thought about that... Maybe there is a reason for it. We'll see what Laurent says :)
Title: Re: SFML 2.0 RC
Post by: Laurent on September 06, 2012, 01:20:23 pm
The reason is simple: null pointer = no shader.

I'm going to fix the doc, thanks ;)
Title: Re: SFML 2.0 RC
Post by: Foaly on September 06, 2012, 01:25:53 pm
... makes sense :D

No Problem. I'm glad I was able help :)
Title: Re: SFML 2.0 RC
Post by: Laurent on September 06, 2012, 04:51:19 pm
In fact it was already fixed, the online doc is just outdated.
Title: Re: SFML 2.0 RC
Post by: pdinklag on September 19, 2012, 07:42:41 pm
I got Windows 8 Professional from my university and will install it sometime later this week. So unless anybody has done this already, I will soon let you know if SFML works well on Windows 8. ;)
Title: Re: SFML 2.0 RC
Post by: Andrei15193 on September 25, 2012, 12:57:12 pm
I got Windows 8 Professional from my university and will install it sometime later this week. So unless anybody has done this already, I will soon let you know if SFML works well on Windows 8. ;)
It works, even on Intel GPU (I have a MSI U123 Wind with 1Gb of RAM and Intel Atom 1.66 Ghz and Intel GPU). If I try to compile and run the same code I have on Ubuntu it crashes (some OpenGL crash), so... go go Win8.

Also, I am using VS2012 Pro using SFML .dll files from VS2010 download, so far they work (RenderTexture, RenderWindow, Sprite, Events it's all I've tried out yet).

Off topic:
Before installing Win8, if you want to use Metro style apps you need a min 1024x768 screen res to run them. My notebook doesn't have that res but installing software the old fashion way and runing them from desktop works just fine.
Title: Re: SFML 2.0 RC
Post by: Groogy on September 27, 2012, 09:22:17 pm
It works just fine on Windows 8, even rbSFML does, already tried ;)

Though cmake don't like Visual Studio 11 yet(2012)
Title: Re: SFML 2.0 RC
Post by: eXpl0it3r on September 27, 2012, 10:56:27 pm
Though cmake don't like Visual Studio 11 yet(2012)
What do you mean by that?
I've no problems with VS11 and CMake. Do you have the latest CMake version?
Title: Re: SFML 2.0 RC
Post by: Groogy on September 27, 2012, 11:27:14 pm
Don't know, might have done something wrong cause it just didn't want to generate the needed files. Gave some error I don't remember but that didn't make sense.
Title: Re: SFML 2.0 RC
Post by: eXpl0it3r on September 27, 2012, 11:34:25 pm
Don't know, might have done something wrong cause it just didn't want to generate the needed files. Gave some error I don't remember but that didn't make sense.
Yeye it's always the fault of the software... :P ;D
Title: Re: SFML 2.0 RC
Post by: Contadotempo on September 29, 2012, 12:11:50 am
Don't know, might have done something wrong cause it just didn't want to generate the needed files. Gave some error I don't remember but that didn't make sense.
Are you using the express edition by any chance? It seems there was a bug with Visual Studio express 2012 and cmake 2.8.9
Take a look at this, it was fixed on cmake 2.8.10:
http://public.kitware.com/Bug/view.php?id=13348

And this for an alternative fix:
http://stackoverflow.com/questions/12434696/visual-studio-express-2012-and-cmake
Title: Re: SFML 2.0 RC
Post by: eXpl0it3r on September 29, 2012, 12:37:20 am
Are you using the express edition by any chance?
Well this could likely be, since I'm using Visual Studio 12 Premium (thanks university!). ;)
Title: Re: SFML 2.0 RC
Post by: cekota on September 29, 2012, 11:22:23 am
Hello,

in "include/SFML/Graphics/Transform.h" we have :

sfTransform sfTransform_Identity;

I have by error modified it. So after this modification it is not an identity matrix anymore.

"const" makes it unmodificable, but still if I provide it by error to a function like sfTransform_rotate() the function will apply silently while actually the operation has not been done without any error reported to the programmer.

So I would suggest to remove "sfTransform_Identity", and provide instead "sfTransform_getIdentity()" :

sfTransform sfTransform_getIdentity(void);

Cheers
Title: Re: SFML 2.0 RC
Post by: Laurent on September 29, 2012, 12:32:55 pm
Quote
"const" makes it unmodificable, but still if I provide it by error to a function like sfTransform_rotate() the function will apply silently while actually the operation has not been done without any error reported to the programmer.
Hum? Why would it apply silently? It will trigger a compiler error, that's the point of using the const keyword.
Title: Re: SFML 2.0 RC
Post by: cekota on September 29, 2012, 12:52:26 pm
Hum? Why would it apply silently? It will trigger a compiler error, that's the point of using the const keyword.

Just remember what CSFML is made for :)

Is it made mainly to write pure plain C ?
Or is its main purpose for something else ?
Title: Re: SFML 2.0 RC
Post by: cekota on September 29, 2012, 12:53:48 pm
and this is also why a function would be better.
Title: Re: SFML 2.0 RC
Post by: Laurent on September 29, 2012, 02:56:50 pm
I still don't get it.
Title: Re: SFML 2.0 RC
Post by: cire on September 29, 2012, 06:39:09 pm
I believe Cekota was suggesting sfTransform_Identity be accessed through a function that supplies a copy of it.

Currently it's not constant and may be changed by a user, and subsequent uses of the identity will (silently) fail to act as one would expect.  The function would make similar scenarios less likely.
Title: Re: SFML 2.0 RC
Post by: FRex on September 29, 2012, 07:20:04 pm
Quote
Yeye it's always the fault of the software... :P ;D
Or authors. :D
Your mileage may vary but software tends to work weird on some setups. On my laptop vc++2008's intelli sense works alright(generously speaking, I'm having problem with sfg shared ptrs). But on my pc, opening or closing a block with sharp bracket, using scope operator on class that just got a new function added ect. doesn't update itself and I must reopen the solution. There is no apparent reason to this(same windows, same installation, same settings, same files even).
Title: Re: SFML 2.0 RC
Post by: Laurent on September 29, 2012, 10:38:18 pm
Quote
I believe Cekota was suggesting sfTransform_Identity be accessed through a function that supplies a copy of it.

Currently it's not constant and may be changed by a user, and subsequent uses of the identity will (silently) fail to act as one would expect.  The function would make similar scenarios less likely.
But the const keyword solves the problem. That's what I don't understand (he says it doesn't).
Title: Re: SFML 2.0 RC
Post by: cire on September 30, 2012, 03:49:26 am
I don't know exactly what he meant there, either, unless he's paranoid enough to want protection against people casting away const, in which case -- good luck. 
Title: Re: SFML 2.0 RC
Post by: cekota on September 30, 2012, 02:06:53 pm
sorry, I thought it was so evident that CSFML is often used for building bindings to higher level languages, but it seems it is not.

indeed, if the variable is wrapped, then the const qualification is discarded
Title: Re: SFML 2.0 RC
Post by: Laurent on September 30, 2012, 03:35:40 pm
Ok, but... the binding will also make it const. CSFML is not supposed to solve potential mistakes in bindings that use it.

If I use a function and return a new copy every time it is called, it can even be worse: a binding that would not make the corresponding object const/readonly/whatever, wouldn't see it and it would "work" although the design has a major flaw.

This is purely a design issue, technical choices won't help. The only good solution is to make sure that the objects are const/readonly/... in all the bindings. So thank you for pointing out that they were not in CSFML :)
Title: Re: SFML 2.0 RC
Post by: cekota on October 07, 2012, 10:58:35 pm
Ok, but... the binding will also make it const. CSFML is not supposed to solve potential mistakes in bindings that use it.

If I use a function and return a new copy every time it is called, it can even be worse: a binding that would not make the corresponding object const/readonly/whatever, wouldn't see it and it would "work" although the design has a major flaw.

This is purely a design issue, technical choices won't help. The only good solution is to make sure that the objects are const/readonly/... in all the bindings. So thank you for pointing out that they were not in CSFML :)

Well, I don't want to make you change your mind, but I would like to understand, because your are an experienced programmer, and I'm a beginner, so I would really want to understand in order to improve my skills.

The problem is that I really don't see what I can do with a const sfTransform_Identity. If I want to use it I will copy it and then use some rotate and translate functions on the copy. So in this case I was thinking that sfTransform_getIdentity() would makes sens.

So please explain me what I'm supposed to do with this const sfTransform_Identity ?
Title: Re: SFML 2.0 RC
Post by: cekota on October 07, 2012, 11:01:01 pm
CSFML: include/SFML/Graphics/Texture.h:
CSFML_GRAPHICS_API void sfTexture_bind(const sfTexture* texture);

SFML: include/SFML/Graphics/Texture.hpp:
void bind(CoordinateType coordinateType = Normalized) const;

The parameter "coordinateType" is missing.
Title: Re: SFML 2.0 RC
Post by: cekota on October 07, 2012, 11:30:57 pm
In the SFML API, there are a lot of function that have default parameters.

Sometimes these default parameter are easy to find from the headers.
Sometimes there are several definitions of the same function so that tracking the default parameter has to be made by reading the source code of SFML, not the header anymore.

When wrapping CSFML this is quite a pain.

More over hard I don't like coding the default parameters in the wrapper because, maybe one day the default value would change, maybe in SFML 3.X.

It would be nice to provide some facilities to get these default parameters.

There could be several ways to do so, one simple possibility could be defining some variable, for example:


<Value_Type> <Function_Name>_<Param_Nane>_Default = <Default_Value>

sfTextureCoordinateType  sfTexture_bind_texture_default = sfTexCoordType_Normalized;

#define MAKE_DEFAULT_PARAM( func_name, param_name, param_type, default_value) \
  param_type func_name##_##param_name##_default = default_value;


MAKE_DEFAULT_PARAM( sfTexture_bind, coordType, sfTextureCoordinateType, sfTexCoordType_Normalized )

 
Title: Re: SFML 2.0 RC
Post by: Laurent on October 08, 2012, 07:53:43 am
Quote
The problem is that I really don't see what I can do with a const sfTransform_Identity. If I want to use it I will copy it and then use some rotate and translate functions on the copy. So in this case I was thinking that sfTransform_getIdentity() would makes sens.
If CSFML does the copy, then every user in every situation will be forced to do this copy. If I directly provide the object, then it's up to the user to decide if he wants to make a copy of it or not. There are many situations where you won't need to copy it, for example when you want to pass an identity matrix to a function that has a sfTransform argument.
So there's no problem, just more flexibility.

Quote
The parameter "coordinateType" is missing.
https://github.com/SFML/CSFML/issues/9#issuecomment-6586469
Title: Re: SFML 2.0 RC
Post by: cekota on October 08, 2012, 05:04:51 pm
If CSFML does the copy, then every user in every situation will be forced to do this copy. If I directly provide the object, then it's up to the user to decide if he wants to make a copy of it or not. There are many situations where you won't need to copy it, for example when you want to pass an identity matrix to a function that has a sfTransform argument.
So there's no problem, just more flexibility.

Oh, I see.
Thank you very much for taking time to instruct me :)

Quote
The parameter "coordinateType" is missing.
https://github.com/SFML/CSFML/issues/9#issuecomment-6586469

Oh, I see.
Then I'll remove it from my bindings.
Title: Re: SFML 2.0 RC
Post by: cekota on October 08, 2012, 05:10:45 pm
And what about providing the default parameters in an accessible way?

(as asked in my previous post)

While writing my binding, I've read sources of other SFML bindings. From comments, or svn commit messages (don't remember which) I have seen that this is not only a problem for me, but also for other binders.
Title: Re: SFML 2.0 RC
Post by: Laurent on October 08, 2012, 08:03:15 pm
Quote
And what about providing the default parameters in an accessible way?
Which parameters in which functions are not "accessible"? They are all explicitely documented. I think using macros would be quite ugly and make things even worse.
Title: Re: SFML 2.0 RC
Post by: cekota on October 08, 2012, 08:54:51 pm
They are all accessible by a human.
By accessible I mean by the code.

While trying to reproduce the C++ API in a wrapper using CSFML, we have to hard code the default values.

Then in a future SFML 3.0, if some default values change, the wrappers will remain with the old default values.
Title: Re: SFML 2.0 RC
Post by: Laurent on October 08, 2012, 11:17:19 pm
And how would your macros automatically keep the wrappers up to date? ??? (and what are these "wrappers" by the way?)
Title: Re: SFML 2.0 RC
Post by: fallout on October 16, 2012, 03:39:22 am
Not sure if this is a bug, but on Linux (Linux Mint), the tilde key doesn't seem to be recognized, but it's fine on Windows using code:

while ( event loop ) {
   if ( event.type == sf::Event::KeyPressed ) {
        if ( event.key.code == sf::Keyboard::Tilde ) {
            //blah
       }
   }
}
Title: Re: SFML 2.0 RC
Post by: Laurent on October 16, 2012, 07:55:12 am
Please search before posting:
https://github.com/SFML/SFML/issues/7
Title: Re: SFML 2.0 RC
Post by: Mario on October 28, 2012, 10:20:00 pm
Reinstalled my Ubuntu VM over the weekend and just noticed that CMake is no longer able to find the FindSFML.cmake file installed by SFML. It's obviously put into /usr/local/share/SFML/cmake, which I think has been different in the past? Is this intentional? (pulled from github on this Friday or so)
Title: Re: SFML 2.0 RC
Post by: Laurent on October 28, 2012, 10:35:43 pm
FindSFML.cmake is no longer installed by default, you must copy it.