Messages

1

Window / Question about Window::SetFramerateLimit and Window::Display

« on: May 03, 2010, 11:50:37 pm »

This was just an example. I wanted to illustrate that it's a hack to use Sleep for a framerate limit because Sleep is meant to stop the whole thread. Even if in practice it's just some milliseconds, the GUI and the game screen are logically two different things. And if you want to stop the game screen, you should still not stop the GUI.

2

Window / Question about Window::SetFramerateLimit and Window::Display

« on: May 03, 2010, 10:19:27 pm »

I looked into the source code to check how the framerate limit works. And I saw that if a framerate is set, the Display function simply calls the Sleep function. And the Sleep function, in Windows, is a wrapper to the WinAPI Sleep function.
Now my question: Isn't that some kind of a hack? I mean, Sleep doesn't just suspend the graphic output inside the window, it suspends the whole application. So, let's say, to demonstrate the case, I program a game with one frame per second: I would expect the gaming screen to update once per second. But I would expect the window itself (resizing, moving, minimizing, closing etc.) to work as usual. But instead, of course, it only works once per second.

3

Window / Menus and dialog boxes

« on: April 30, 2010, 01:06:56 pm »

You mean I shall have two windows next to each other?

4

Window / Menus and dialog boxes

« on: April 30, 2010, 12:29:19 pm »

O.k., I did the menu now, but then I remembered that I somehow have to catch the events. That's why here's my next question: Does SFML provide anything like that?

Code: [Select]

SDL_EventState(SDL_SYSWMEVENT, SDL_ENABLE);

switch (event.type)
{
case SDL_SYSWMEVENT:
switch (event.syswm.msg->msg)
{
case WM_COMMAND:
if (LOWORD(event.syswm.msg->wParam) == ID_MENU_ITEM)
{
// ...
}
break;
}
break;
}

5

Window / Menus and dialog boxes

« on: April 30, 2010, 08:58:31 am »

In this case you wouldn't have the correct look-and-feel. If I intended to use a GUI inside the game area, I would program my own stuff anyway. After all, it won't be much: Keyboard input, screen resolution etc.

6

Window / Menus and dialog boxes

« on: April 29, 2010, 08:27:11 pm »

The problem is that your app is no loosing compatibility... Why use SFML therefore ?

What do you want to do exactly ?
Can't you use an existent GUI ?
EDIT : What about Qt or wxWidget ?

Well, I do want to write a game, yes. A GUI is not the primary goal, so Qt or wxWidgets are not necessary. It's just that Windows users don't want to enter command line parameters to configure the game options. That's why I would add a native menu and some modal dialog boxes to the Windows version. The game would still be platform independent since I'd enclose every Windows-specific stuff with #ifdef WIN32. And it would still behave identical on every operation system, only that the Windows users have a menu above the window and Linux users don't and need to use command line parameters to change options.
That's similar to the NES emulator FCE Ultra: Compile it as a native Windows and DirectX version and you get a typical Windows interface with a menu and dialog boxes. Compile it as the SDL version and, in Windows and Linux alike, you only have that crappy standard window and you have to enter the options at the command line. Everything from the same source package and with the same configure script.

But it's o.k. I found out a way to do the menu anyway: I'll just use EnumWindows, GetWindowThreadProcessId and GetCurrentProcessId. That will give me the application window as a HWND.

7

Window / Menus and dialog boxes

« on: April 28, 2010, 11:50:36 pm »

Because developping a GUI library involves a huge effort. Currently, there are more important, multimedia-related basic features to implement in SFML 2.

Well, I can of course understand why SFML doen't support it directly. But there should be at least a function to get the platform-dependent data of a window. Something like:

Code: [Select]

class Window
{
#ifdef WIN32
    HWND GetHwnd();
#elif defined UNIX
    UnixSomething1 GetThisStuff();
    UnixSomething2 GetThatStuff();
#elif ...
    ...
#endif
};In this case, even if certain functions are not supported, the programmer can still use them by working with the native frameworks of their operation system.

8

General / Compiling SFML

« on: April 28, 2010, 11:42:59 pm »

Don't you use Code::Blocks?

No. I compile directly under the command line.

There are no MinGW makefiles for SFML.

There should be. Even better, the makefile for Linux should be written in a way that it can compile both, the Linux and the Windows version with GCC.

9

Window / Menus and dialog boxes

« on: April 28, 2010, 02:39:10 pm »

Why not? How shall I create my menus now?

10

General / Compiling SFML

« on: April 28, 2010, 02:34:03 pm »

Yes, that's for Linux. But what if I want to compile with MinGW on the command line? The MinGW download only has the project files for Code::Blocks. And if I try to compile the Linux download with MinGW and MSYS, I get the following output:

Code: [Select]

make[1]: Entering directory `/home/User/SFML-1.5/src/SFML'
make[2]: Entering directory `/home/User/SFML-1.5/src/SFML/System'
g++ -o Clock.o -c Clock.cpp -W -Wall -pedantic -I../../../include -I../../ -O2 -
DNDEBUG -fPIC
Clock.cpp:1: warning: -fPIC ignored for target (all code is position independent
)
g++ -o Initializer.o -c Initializer.cpp -W -Wall -pedantic -I../../../include -I
../../ -O2 -DNDEBUG -fPIC
Initializer.cpp:1: warning: -fPIC ignored for target (all code is position indep
endent)
g++ -o Lock.o -c Lock.cpp -W -Wall -pedantic -I../../../include -I../../ -O2 -DN
DEBUG -fPIC
Lock.cpp:1: warning: -fPIC ignored for target (all code is position independent)

g++ -o Randomizer.o -c Randomizer.cpp -W -Wall -pedantic -I../../../include -I..
/../ -O2 -DNDEBUG -fPIC
Randomizer.cpp:1: warning: -fPIC ignored for target (all code is position indepe
ndent)
g++ -o Sleep.o -c Sleep.cpp -W -Wall -pedantic -I../../../include -I../../ -O2 -
DNDEBUG -fPIC
Sleep.cpp:1: warning: -fPIC ignored for target (all code is position independent
)
g++ -o Unicode.o -c Unicode.cpp -W -Wall -pedantic -I../../../include -I../../ -
O2 -DNDEBUG -fPIC
Unicode.cpp:1: warning: -fPIC ignored for target (all code is position independe
nt)
../../../include/SFML/System/Unicode.inl:32: warning: unused parameter 'Locale'
../../../include/SFML/System/Unicode.inl:68: warning: unused parameter 'Locale'
../../../include/SFML/System/Unicode.inl:68: warning: unused parameter 'Locale'
g++ -o Unix/Mutex.o -c Unix/Mutex.cpp -W -Wall -pedantic -I../../../include -I..
/../ -O2 -DNDEBUG -fPIC
Unix/Mutex.cpp:1: warning: -fPIC ignored for target (all code is position indepe
ndent)
In file included from Unix/Mutex.cpp:28:
../../../include/SFML/System/Unix/Mutex.hpp:32:21: pthread.h: No such file or di
rectory
In file included from Unix/Mutex.cpp:28:
../../../include/SFML/System/Unix/Mutex.hpp:76: error: `pthread_mutex_t' does no
t name a type
../../../include/SFML/System/Unix/Mutex.hpp:76: error: extra semicolon
Unix/Mutex.cpp: In constructor `sf::Mutex::Mutex()':
Unix/Mutex.cpp:38: error: `myMutex' was not declared in this scope
Unix/Mutex.cpp:38: error: `NULL' was not declared in this scope
Unix/Mutex.cpp:38: error: `pthread_mutex_init' was not declared in this scope
Unix/Mutex.cpp:38: warning: unused variable 'myMutex'
Unix/Mutex.cpp:38: warning: unused variable 'NULL'
Unix/Mutex.cpp:38: warning: unused variable 'pthread_mutex_init'
Unix/Mutex.cpp: In destructor `sf::Mutex::~Mutex()':
Unix/Mutex.cpp:47: error: `myMutex' was not declared in this scope
Unix/Mutex.cpp:47: error: `pthread_mutex_destroy' was not declared in this scope

Unix/Mutex.cpp:47: warning: unused variable 'myMutex'
Unix/Mutex.cpp:47: warning: unused variable 'pthread_mutex_destroy'
Unix/Mutex.cpp: In member function `void sf::Mutex::Lock()':
Unix/Mutex.cpp:56: error: `myMutex' was not declared in this scope
Unix/Mutex.cpp:56: error: `pthread_mutex_lock' was not declared in this scope
Unix/Mutex.cpp:56: warning: unused variable 'myMutex'
Unix/Mutex.cpp:56: warning: unused variable 'pthread_mutex_lock'
Unix/Mutex.cpp: In member function `void sf::Mutex::Unlock()':
Unix/Mutex.cpp:65: error: `myMutex' was not declared in this scope
Unix/Mutex.cpp:65: error: `pthread_mutex_unlock' was not declared in this scope
Unix/Mutex.cpp:65: warning: unused variable 'myMutex'
Unix/Mutex.cpp:65: warning: unused variable 'pthread_mutex_unlock'
make[2]: *** [Unix/Mutex.o] Error 1
make[2]: Leaving directory `/home/User/SFML-1.5/src/SFML/System'
make[1]: *** [sfml-system] Error 2
make[1]: Leaving directory `/home/User/SFML-1.5/src/SFML'
make: *** [sfml] Error 2

There should be a download for MinGW with a makefile to compile on the command line.

11

General / Compiling SFML

« on: April 28, 2010, 11:58:24 am »

What do I have to do to compile SFML from source? There is no configure file for GCC. Does that mean I have to include all source files manually to the project?

12

Window / Menus and dialog boxes

« on: April 28, 2010, 09:57:07 am »

Is there any way to add a menu to an SFML window? And is it possible to show dialog boxes with control elements on them? If no, is it possible to get the platform dependent data for the window (in Windows: HWND)?

13

General discussions / DirectX vs SFML

« on: April 27, 2010, 03:32:49 pm »

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.

14

General discussions / DirectX vs SFML

« on: April 27, 2010, 12:37:15 pm »

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.

15

General discussions / DirectX vs SFML

« on: April 26, 2010, 10:17:44 am »

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.