Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Changes since version 2RC  (Read 5058 times)

0 Members and 2 Guests are viewing this topic.

Pap

  • Newbie
  • *
  • Posts: 14
    • View Profile
    • Email
Changes since version 2RC
« on: May 05, 2013, 04:59:13 pm »
Just installed version 2 (from source code, on a Linux 64-bit box), and, recompiled some code made with version 2RC. I noticed there are some changes. Specifically, sf::sleep(sf::milliseconds(1000)) seems to last much more than in 2RC.
Also, for some reason, sf::Event::KeyPressed.event.key.code doesn't seem to detect sf::Keyboard::Equal, or sf::Keyboard::Dash, while it still detects sf::Keyboard::Escape, for example, or arrow keys.

So the exact same code that used to run on version 2RC doesn't run as expected when recompiled with version 2. I noticed in the version 2 announcement that there is no change log yet, but I wanted to ask if other people also noticed the facts mentioned above, or maybe others I am not aware of yet.
« Last Edit: May 05, 2013, 05:04:10 pm by Pap »

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Re: Changes since version 2RC
« Reply #1 on: May 05, 2013, 05:06:22 pm »
Quote
on a Linux 65-bit box
Amazing :o

Quote
sf::sleep(sf::milliseconds(1000)) seems to last much more than in 2RC
There was no modification on this part of the API after the RC. Are you sure that it's not your environment that changed?

Quote
sf::Event::KeyPressed.event.key.code doesn't seem to detect sf::Keyboard::Equal, or sf::Keyboard::Dash
Same answer, no modification since the RC.
Laurent Gomila - SFML developer

Pap

  • Newbie
  • *
  • Posts: 14
    • View Profile
    • Email
Re: Changes since version 2RC
« Reply #2 on: May 05, 2013, 05:19:19 pm »
Are you sure that it's not your environment that changed?
I am actually using two computers right now, both have the exact same Linux version installed, and the exact same version of gcc and libraries required by SFML. One of them has SFML 2 installed, the other one has version 2RC. The difference on sf::sleep(sf::milliseconds(1000)) is more than apparent (lasts more than double the time it lasts in 2RC), and the compiled code doesn't respond on sf::Keyboard::Equal or sf::Keyboard::Dash, while several other keys do work. Note that the computer that has version 2 installed had version 2RC before, and the code worked exactly as in the other computer. I doubt it is a matter of environment.

The code is too complicated to be used as an example here, will try to make a simpler code demonstrating the differences mentioned above.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Re: Changes since version 2RC
« Reply #3 on: May 05, 2013, 07:22:56 pm »
You can check the commits between tag 2.0-rc and tag 2.0, in case I've forgotten something, but I'm pretty sure nothing changed at all.
Laurent Gomila - SFML developer

Pap

  • Newbie
  • *
  • Posts: 14
    • View Profile
    • Email
Re: Changes since version 2RC
« Reply #4 on: May 06, 2013, 04:04:11 pm »
It turns out it has to do with my environment, as Laurent said, but in a way I didn't expect: it seems that, for some reason, SFML renders windows very slowly on the my laptop (which is a more than decent computer otherwise). The following simple program should show a rotating red rectangle in a 800x600 window. The user can increase/decrease rotation speed by the up/down arrow keys, respectively:
#include <SFML/Graphics.hpp>

int main() {
  int delay=1;
  sf::RenderWindow window(sf::VideoMode(800,600),"Test");
  sf::RectangleShape square(sf::Vector2f(100,100));
  sf::Event event;
  window.clear();
  window.display();
  square.setOrigin(50,50);square.setPosition(400,300);
  square.setFillColor(sf::Color(255,0,0));
  while (window.isOpen()) {
        while (window.pollEvent(event)) {
          if (event.type==sf::Event::KeyPressed)
                switch(event.key.code) {
                case sf::Keyboard::Escape:window.close();break;
                case sf::Keyboard::Up:delay>0?delay--:delay;break;
                case sf::Keyboard::Down:delay++;break;
                default:break;
                }
          else if (event.type==sf::Event::Closed) window.close();
        }
        square.rotate(1);
        window.clear();
        window.draw(square);
        window.display();
        sf::sleep(sf::milliseconds(delay));
  }
  return EXIT_SUCCESS;
}
 
Normally, the rectangle should rotate very fast initially - so fast that you couldn't even realize it is a rectangle (on my desktop computer (with a Nvidia GPA) it looks like a circle, as the rotation speed is initially very high. Unfortunately, this is not the case on my laptop: even if I remove the line sf::sleep(sf::milliseconds(delay)); (so no delay at all between frames), it is still rotating very slowly. I can't think of any other reason than slow window rendering.
I suspect it has to do with the driver for my graphics card (an integrated Intel GPA). Note, however, that this laptop is able to run "heavy" 3D games that use OpenGL extensively, without any problem. So I am guessing something is wrong with the way SFML cooperates with OpenGL in that specific graphics card.

Attached, please find the log file from Xorg, in case it helps identifying the problem.

[attachment deleted by admin]

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Re: Changes since version 2RC
« Reply #5 on: May 06, 2013, 04:35:59 pm »
Have you measured the framerate? If it's 60, then it means that your graphics driver forces the vertical synchronization on -- not that SFML is slow ;)
Laurent Gomila - SFML developer

Pap

  • Newbie
  • *
  • Posts: 14
    • View Profile
    • Email
Re: Changes since version 2RC
« Reply #6 on: May 06, 2013, 04:52:38 pm »
Never said SFML is slow, it definitely isn't. On the other hand, my laptop's  graphics card is not bad at all (like I said I can play heavy 3D games without any problem). I am just guessing, but it seems that, in that specific computer, SFML windows are rendered slowly because there is an issue that must have to do with how SFML communicates with installed OpenGL, or vice-versa. I really don't know what else to do about that. Is there any way to get rid of the problem?

Note: not sure how I can check framerate, but I can run 3D games with 50-100+ framerate on that very computer (depends of the situation).


Raphman

  • Newbie
  • *
  • Posts: 40
    • View Profile
    • Email
Re: Changes since version 2RC
« Reply #7 on: May 06, 2013, 04:57:48 pm »
I'm pretty sure you can use fraps to check frame rate. I'm pretty sure I've done it, although I can't remember for sure.

Pap

  • Newbie
  • *
  • Posts: 14
    • View Profile
    • Email
Re: Changes since version 2RC
« Reply #8 on: May 07, 2013, 03:23:11 am »
Some more data, in case they would help detecting the problem:
  • Laptop pc, Fujitsu Lifebook A-series.
  • Operating system: Debian 7.0 ("Wheezy"), pure 64-bit (no "multi-architecture", only 64-bit libraries installed).
  • Installed versions of dependencies (some of them probably irrelevant to the problem but for the sake of completeness):
    libraryversionheader file
    libc6-dev2.13-38/usr/include/pthread.h
    libx11-dev2:1.5.0-1/usr/include/X11/Xlib.h
    mesa-common-dev8.0.5-4/usr/include/GL/gl.h  etc
    libglew-dev1.7.0-3/usr/include/GL/glew.h  etc
    libxrandr-dev2:1.3.2-2/usr/include/X11/extensions/Xrandr.h
    libfreetype6-dev2.4.9-1.1/usr/include/freetype2/freetype/freetype.h
    libjpeg8-dev8d-1/usr/include/jpeglib.h
    libsndfile1-dev1.0.25-5/usr/include/sndfile.h
    libopenal-dev1:1.14-4/usr/include/AL/al.h
  • SFML2 was compiled from source without any warnings or errors.
  • All SFML examples also compile and run without warnings/errors.
  • Graphics driver does not force vertical synchronization.
  • System is able to run 3D games that use OpenGL extensively without any problem on speed or whatever else; I can get frame rates 100+; apparently, graphics driver works very well.
Still, even compiling the simple test program I posted earlier, I get a very poor frame rate, so poor that I initially thought even keyboard was not responding properly. I use the laptop pc very frequently, and any programming using SFML will give results way slower than expected. Since graphics driver works very well, and SFML itself is fast, I cannot think of anything else than something is wrong concerning how those two cooperate. I might be wrong, but can't think of anything else causing the very low frame rate.

Any help on solving the problem is more than welcome.

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 11034
    • View Profile
    • development blog
    • Email
AW: Changes since version 2RC
« Reply #9 on: May 07, 2013, 06:16:02 am »
Use a profiler to figure out where the bottleneck is.
We can only make magically guess, you can in fact test things. ;)
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Pap

  • Newbie
  • *
  • Posts: 14
    • View Profile
    • Email
Re: Changes since version 2RC
« Reply #10 on: June 09, 2013, 11:02:18 am »
After several experiments, I can verify what I was suspecting: OpenGL works perfectly in this laptop, but for some reason the Intel driver for the graphics card (which is the official one) is not cooperating well with SFML, hence the very low frame rate.
Is there any way to switch to software rendering? Something similar to ClanLib's CL_SetupSWRender? This should increase frame rate significantly, I suppose. As it is now, I can develop an application that might work as expected in a given PC, but being very slow on another, just because of a driver issue. The user would then conclude my application is bugged or something. Switching to software rendering should be an option in such cases.

As far I know, software rendering in SFML was discussed in the past, but I'm not sure if it is implemented or planned.

Mario

  • SFML Team
  • Hero Member
  • *****
  • Posts: 879
    • View Profile
Re: Changes since version 2RC
« Reply #11 on: June 10, 2013, 10:35:13 am »
Unfortunately stuff like this aren't really new for some Intel drivers, even on Windows (try rendering to textures on an older Eee Pad for example...).

To force software rendering you should be able to simply set an environment variable, something like:

LIBGL_ALWAYS_SOFTWARE=1 ./your_binary

Pap

  • Newbie
  • *
  • Posts: 14
    • View Profile
    • Email
Re: Changes since version 2RC
« Reply #12 on: June 10, 2013, 11:51:16 am »
To force software rendering you should be able to simply set an environment variable, something like:
LIBGL_ALWAYS_SOFTWARE=1 ./your_binary
It works, in the sense there is a significant boost in fps, together with the usual drawback of software rendering, namely glitches. Better than nothing, I guess. Thank you for the tip :)

So, if I understand well, it is impossible to switch to software rendering using SFML itself?

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Re: Changes since version 2RC
« Reply #13 on: June 10, 2013, 11:57:02 am »
Quote
So, if I understand well, it is impossible to switch to software rendering using SFML itself?
No, this is beyond the scope of SFML. SFML uses the OpenGL abstract interface to draw things; whether the implementation used on a particular system is software or hardware is not its problem.
Laurent Gomila - SFML developer

Mario

  • SFML Team
  • Hero Member
  • *****
  • Posts: 879
    • View Profile
Re: Changes since version 2RC
« Reply #14 on: June 10, 2013, 10:19:35 pm »
It might actually be interesting to be able to query the status (hardware accelerated yes/no), so games or programs might scale their drawing accordingly. Although I'm not 100% sure there's a specific cap for this. What do you think?

 

anything