DirectX vs SFML

[ravenheart]

I dont know if u understand german but this might be interesting for you:

http://c-plusplus.de/forum/viewtopic-var-t-is-265040-and-postdays-is-0-and-postorder-is-asc-and-start-is-0.html

in short:

sfml would be very slow compared to directX tested on WinXP and Win2000, this guy is wondering why

[Ashenwraith]

Looks like he forgot to SetFramerateLimit()

EDIT: I informed them

http://c-plusplus.de/forum/viewtopic-var-p-is-1884886.html#1884886

[tester]

Hi, I'm the guy from that other forum.

O.k., well, my intention was to test how SFML behaves in extreme situations. I took a background image of 320 x 240 pixels and a sprite of 16 x 32 pixels. And then I let the sprite walk from left to right as fast as possible. No framerates, no timers, just to see what the lib is capable of. This is my code:

Code: [Select]

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

using namespace std;

int main()
{
sf::Image backgroundImage, spriteImage;
sf::Sprite background, sprite;

backgroundImage.LoadFromFile("Background.bmp");
backgroundImage.SetSmooth(false);
background.SetImage(backgroundImage);

spriteImage.LoadFromFile("Sprite.bmp");
spriteImage.SetSmooth(false);
sprite.SetImage(spriteImage);

sf::RenderWindow screen(sf::VideoMode(backgroundImage.GetWidth(), backgroundImage.GetHeight(), 32), "SFML Test");

clock_t start = 0, stop = 0;

while (screen.IsOpened())
{
sf::Event event;

while (screen.GetEvent(event))
{
switch (event.Type)
{
case sf::Event::Closed:
screen.Close();
break;

case sf::Event::KeyPressed:
start = clock();
break;
}
}

if (start != 0 && stop == 0)
sprite.Move(1, 0);

screen.Draw(background);
screen.Draw(sprite);
screen.Display();

if (start != 0 && stop == 0 && sprite.GetPosition().x == backgroundImage.GetWidth())
{
stop = clock();

cout << (stop - start) * 1000 / CLOCKS_PER_SEC << " milliseconds" << endl;
}
}
}
As long as the window is in its original size, everything is quite fine. But now imagine someone has a screen resolution of 1280 x 1024 and wants to play the game in a maximized window. On my new QuadCore PC the speed is still acceptable. But imagine a person with a PC of 700 MHz. On this PC the movement takes more than three seconds.
What am I doing wrong? Setting a framerate limit made it even slower. Which is logic since this is an endurance test to see how fast the SFML could display the images. That's not a prototype of a real game, it's just a test.

[Laurent]

Hi

As long as the window is in its original size, everything is quite fine. But now imagine someone has a screen resolution of 1280 x 1024 and wants to play the game in a maximized window. On my new QuadCore PC the speed is still acceptable. But imagine a person with a PC of 700 MHz. On this PC the movement takes more than three seconds.

First, I don't think that "imagine" is really meaningful when talking about performances, I'd prefer real numbers

But ok, let's say that these "3 seconds" are the benchmark result. 3 seconds to perform 1280 moves gives approximately 2.3 ms per frame, right? 2.3 ms per frame is 430 frames per second. I don't see what's critical here.
Did I miss something?

Generally speaking, drawing one or two sprites is not a significant benchmark, because the results are polluted with the overhead of event / window handling. This is not significant when drawing a real scene because it happens once per frame regardless the number of sprites that you draw, but when you draw only one or two it becomes significant.

And 2.3 ms per frame is not really signficant too. I'd suggest that:
- you perform many tests (drawing strings, drawing sprites, drawing shapes, using rotations, alpha-blending, scale, ...)
- you draw a huge number of things

And after that, don't forget to test SFML 2 too, because it has better performances than SFML 1.6

[Ashenwraith]

Have you tried this test in fullscreen D3D vs fullscreen OGL?

I believe OGL has a weakness for windowed applications vs D3D.

[tester]

First, I don't think that "imagine" is really meaningful when talking about performances, I'd prefer real numbers

But ok, let's say that these "3 seconds" are the benchmark result.

They are. I tested it on a crappy PC with 700 MHz and 1280 x 1024 pixels.

3 seconds to perform 1280 moves gives approximately 2.3 ms per frame, right? 2.3 ms per frame is 430 frames per second. I don't see what's critical here.
Did I miss something?

These aren't 1280 moves, these are still just 320 moves. The original window resolution was 320 x 240. The sprite walks one pixel per movement. And this whole scene was just enlarged. I didn't enlarge the background manually and kept the sprite the same. The whole scene was drawn with 320 x 240 pixels and then it was enlarged for output. I didn't even have to do this myself, it's done automatically when you resize the window. So, logically, the sprite still walks 320 pixels, just that these original pixels are displayed bigger.

Generally speaking, drawing one or two sprites is not a significant benchmark, because the results are polluted with the overhead of event / window handling. This is not significant when drawing a real scene because it happens once per frame regardless the number of sprites that you draw, but when you draw only one or two it becomes significant.

Well, if I had a game with 10 sprites on the screen, the game would still not become faster.
When I did that test, I didn't care for the exact results. I just wanted to see if the game is still playable at a high screen resolution. And it seems that it isn't because the characters would start to move in slow motion. As I said, it was an extreme test. If the sprite had been slower than at a small window, but still faster than it would move in a real game, I could use it. But since the sprite moves slower than in a real game, any further tests are unnecessary because the actual performance wouldn't improve with more sprites.

Have you tried this test in fullscreen D3D vs fullscreen OGL?

No, it was both in window mode.

I believe OGL has a weakness for windowed applications vs D3D.

Well, it was supposed to be the worst case, so yeah. Also, in fullscreen mode I wouldn't need to care for stretching anymore because there I could simply change the screen resolution to 320 x 240 pixels and the game scene would fill the whole screen.

[Laurent]

I tested it on a crappy PC with 700 MHz and 1280 x 1024 pixels.

Which graphics card? Are your drivers up-to-date? Do you compile and run the application in release mode?

These aren't 1280 moves, these are still just 320 moves. The original window resolution was 320 x 240. The sprite walks one pixel per movement. And this whole scene was just enlarged. I didn't enlarge the background manually and kept the sprite the same. The whole scene was drawn with 320 x 240 pixels and then it was enlarged for output. I didn't even have to do this myself, it's done automatically when you resize the window. So, logically, the sprite still walks 320 pixels, just that these original pixels are displayed bigger.

Ok I missed that, sorry. But it's still more than 100 FPS, which is much more than what you need.

But since the sprite moves slower than in a real game

I don't get that. If you want the sprite to move faster, just make it move by more than 1 pixel per frame. The application itself runs fast enough at 100 FPS.

[Ashenwraith]

Well, it was supposed to be the worst case, so yeah. Also, in fullscreen mode I wouldn't need to care for stretching anymore because there I could simply change the screen resolution to 320 x 240 pixels and the game scene would fill the whole screen.

Most monitors do not even support a resolution that low and it's not widescreen so there is aspect stretching. There's a difference between writing a modern game and an emulator. 320x240 was for old televisions.

OpenGL and D3D operate MUCH better in fullscreen mode. Windowed mode is not for serious games that depend on performance. Who does benchmarks in windowed mode for a game?

[tester]

Which graphics card? Are your drivers up-to-date?

Why is that important? If framework 1 is fast enough and framework 2 is much slower, the main problem is probably not the graphic card.

Do you compile and run the application in release mode?

Ok I missed that, sorry. But it's still more than 100 FPS, which is much more than what you need.

Yeah, maybe you're right. But it still bothers me why this is slower than DirectX.

[Spodi]

Ok I missed that, sorry. But it's still more than 100 FPS, which is much more than what you need.

Yeah, maybe you're right. But it still bothers me why this is slower than DirectX.

Expecting SFML to be faster than DirectX, or even on the same level, is really asking for a lot. To be able to accomplish that, Laurent would probably have to write it so SFML uses DirectX when available, which would be a huge task, and pretty much destroy any manual interaction you may want to do with OpenGL.

SFML is definitely fast enough, especially for the simplicity and portability it gives. If it is not fast enough for you by the time your game is ready to ship, then there are two options:
1. Try to optimize code on your side.
2. Figure out where things are bottlenecking for you, then help find ways to optimize it in SFML so everyone can benefit.

[Mindiell]

Which graphics card? Are your drivers up-to-date?

Why is that important? If framework 1 is fast enough and framework 2 is much slower, the main problem is probably not the graphic card.

But what if your actual drivers are more improved with Framework 1 and not with Framework 2 ? With this case, openGL will be slower with any application, no ?

[Ashenwraith]

This is especially true for ATI who had very poor OpenGL support (and now has moderate).

Intel is really bad with everything, I wish they would stop making chips if they aren't going to make a decent driver.