Messages

1

Window / Request: Move EventLoop processing to background thread

« on: April 01, 2012, 01:32:00 pm »

Hi,

currently when dragging the window with the mouse, the game stops (with most common implementations, atleast under ms windows), as the main thread hangs in the event loop.
By moving the event loop processing to a background thread this can be fixed.

My suggestion is to make this part of sfml.
Imo it's surely not a feature, that the game freezes when the window is moved.

Here is a sample implementation with C#, which atm is missing a method to stop the background thread. This could be implemented with a WaitEvent method with a timeout and then the main thread calls Dispose, which makes the background thread terminate as soon as it returns from the WaitEvent method:

public class ThreadedEventLoopRenderWindow : RenderWindow
{
    private ConcurrentQueue<Event> eventQueue = new ConcurrentQueue<Event>();

    public static ThreadedEventLoopRenderWindow Create(VideoMode mode, string title, Styles style, ContextSettings settings)
    {
         ThreadedEventLoopRenderWindow result = null;
         bool windowCreated = false;
        //the window must be created from the background thread
         Thread eventThread = new Thread(() =>
         {
                result = new ThreadedEventLoopRenderWindow(mode, title, style, settings);
                windowCreated = true;
                result.ProcessEvents();              
         });
         eventThread.IsBackground = true;
         eventThread.Start();
         while (!windowCreated) ;
         return result;
    }

        private ThreadedEventLoopRenderWindow(VideoMode mode, string title, Styles style, ContextSettings settings)
            : base(mode, title, style, settings)
        {
            SetActive(false);
        }

         private void ProcessEvents()
        {
            while (true) //replace this with sthg like while(!interrupted) and use a WaitEvent call with timeout
            {
                Event evt;
                bool ok = base.WaitEvent(out evt);
                if (ok)
                {
                    eventQueue.Enqueue(evt);
                }
            }
        }

        protected override bool PollEvent(out Event eventToFill)
        {
            return eventQueue.TryDequeue(out eventToFill);
        }
}
 

Note that for this to work the window must be created from a background thread.
That's the reason, why the constructor is private and a factory method is used to create.

If all this is implemented as part of sfml these ugly details can be hidden and fixed behind the same interface which was always used.
I think that many people find the default behaviour annoying.
With sfml thread classes and/or the new standard there should be a way to implement it in c++ as part of sfml.

Btw does this problem also occur on other OS'es than windows?

Another nice thing for the window class would be a method to make the window have focus (I think it's missing).

2

General / Precompiled SFML 1.6 for 64 Bit Windows

« on: November 26, 2011, 11:55:33 pm »

You can use the 32 bit version with an 64 bit os.
If you really want 64 bit then you will probably need to compile it yourself (it's not that hard).

3

Graphics / Vsync and Intel HD 3000

« on: November 22, 2011, 06:44:50 pm »

I have the same problem with my notebook with an intel hd graphics card.
I just use both Vsync and setframelimit, so it will work fine on every system.

4

General / [SOLVED]How to use MouseButton?

« on: November 15, 2011, 06:34:57 pm »

replace "Button" with "sf::Mouse::Button". Don't forget the namespace and the enclosing class.

5

General / SFML Complete Game Tutorial

« on: November 15, 2011, 05:17:23 pm »

I know this, but in this case he wanted <string> and not <cstring>:

Code: [Select]


#pragma once

#include "stdafx.h"
#include <string.h>  //<----
#include "IAudioProvider.h"

class SFMLSoundProvider : public IAudioProvider
{
public:

  SFMLSoundProvider();

  void PlaySound(std::string filename);  //<----- here std::string is used
  void PlaySong(std::string filename, bool looping = false); //<----- here std::string is used
  ...
};

With <string.h> you probably get the completely wrong things (c-string utility function without std namespace, whereas you want std::string in std namespace), so you should #include <string>
It probably works anyway, because somewhere <string> is included, maybe even <string.h> includes it with msvc, although this would be quite strange.

6

General / SFML Complete Game Tutorial

« on: November 14, 2011, 11:13:29 pm »

I really like your tutorials.

In the last one I found a thing you should change:

Code: [Select]

#include <string.h>
should be

Code: [Select]

#include <string> instead.

If you include it with the .h it is not placed in the std:: namespace afaik.

7

General / Trouble with sf::vector2

« on: November 11, 2011, 09:28:19 am »

what is your problem?

Code: [Select]


typedef sf::Vector2<double> Vector2d;

Vector2d vec(1, 5);
//and you are done.
//if you want to change the coords just do
vec.x = 42;
vec.y = 1337;


8

General / Pong game doesn't work when i SetFramerateLimit

« on: November 11, 2011, 09:24:47 am »

I use for movement sprite.Move(x, y*App.GetFrameTime());

You should not do that.

Rather do something like this:

Code: [Select]


const float UPDATE_INTERVAL = 10f; //10ms -> 100 ticks per second

 float restTime = 0f;

 while(app.IsOpened())
 {
     restTime += app.GetFrameTime();
     while(restTime >= UPDATE_INTERVAL)
     {
          restTime -= UPDATE_INTERVAL;
          Update(UPDATE_INTERVAL); //here you move your sprites and so on
     }
     Draw();
 }


it might be that when reducing the frame rate the move steps get too big so that you are missing a collision.
A fixed timestep is almost in any situation better than using the exact elapsed time.

9

Graphics / How does the Draw() work?

« on: November 10, 2011, 07:46:38 pm »

Why sfml then doesen't do it?
You just need to test for intersection with the view rect for every sprite before making the actual draw calls.

10

Window / OIS as an input system

« on: November 08, 2011, 11:10:57 am »

You also get the events from sfml when using PollEvent.

11

Graphics / Inconsistent movement?

« on: November 07, 2011, 11:13:16 pm »

You should use a fixed timestep.

I do it something like this:

Code: [Select]


const float UPDATE_INTERVAL = 10f; //10ms -> 100 ticks per second

float restTime = 0f;

while(app.IsOpened())
{
    restTime += app.GetFrameTime();
    while(restTime >= UPDATE_INTERVAL)
    {
         restTime -= UPDATE_INTERVAL;
         Update(UPDATE_INTERVAL); //here you calculate the offset and gravity and so on with a fixed timestep.
    }
    Draw();
}

The problem might be if you have functions which are proportional to time^2 and not to time then the interval matters and depending on the pc the interval can change. So you just need to set the update interval to a fixed time step (I usually do 100 ticks per second, you can adjust it to your needs).

12

General / Time as float?

« on: November 03, 2011, 11:38:12 am »

SFML 2.0 uses unsigned int.

You should not care for processor power which is needed to convert between float and (unsigned) int, it won't have a noticeable effect.

13

Network / Need help with simple UDP game

« on: October 23, 2011, 10:20:08 pm »

I don't think that using enet will reduce latency, if you are using udp anyway.
The main benefit of enet is that you can have reliable and unreliable messages.

I use sf::Packet because I somehow need to turn a struct or class into bytes.
If your class contains pointers it's not enough to just reinterpret_cast it into an byte array.
With sf::Packet you can turn the data component-wise into bytes.
The usage is as I already showed:

Code: [Select]


struct Data
{
  int a;
  int b;
  string s;
};

Data data;
sf::Packet toSend;
toSend << data.a << data.b << data.s;


To reduce input delay you could make the client react to the input immediately and later apply correction. It depends on the situation if that will work out or not.

14

Network / Need help with simple UDP game

« on: October 23, 2011, 04:31:06 pm »

I think your main problem is that on client side you only refresh the game state when you receive something.

You should use some extrapolation - let the actors on client side move in the direction they are facing and when you get a new snapshot from the server you apply a correction.
But don't just overwrite the position with the server position, this would not look good, but instead apply some smoothing.
What worked quite good for me was to reduce the distance between client and server pos by 10% every time you receive a snapshot.
Other things like speed acceleration and so on are directly taken from the server.

Using sf::Packet with other libraries is not that hard.

Just create a packet and put some data into it:

Code: [Select]


sf::Packet toSend;
toSend << xPos << yPos << xSpeed << ySpeed;


Almost every networking libraries has some method like Send(const char* bytes, int size);

You then do it like this:

Code: [Select]


thirdPartySocket.Send(toSend.GetData(), toSend.GetDataSize());


Similarly for receiving:
You will probably get some kind of buffer (maybe char array) from the library. You must make sure that the message is received as a whole, but that's usually not a problem as it's the way udp works and most libraries won't split your messages.
It could look like this:

Code: [Select]


char buffer[4096];
int len = thirdPartySocket.Receive(buffer, sizeof(buffer));
sf::Packet received;
received.Append(buffer, len);
received >> xPos >> yPos >> xSpeed >> ySpeed;


Udp is a good choice for you, but for some things like lobby or chat messages you will need reliability.
I would recommend using enet, as it allows you to specify which reliabilities you need for each communication channel.
Then use sf::Socket to serialize your data (turning them into bytes) and to deserialize it (turning them back into useful data).

15

Network / Two physical packets per sf::Packet?

« on: October 23, 2011, 02:21:27 pm »

Concatenating all the data in a single buffer would require a dynamic memory allocation, which is even worse.

I don't optimize when there's no need to. Do another benchmark if you want me to change this

First you a fearing dynamic allocations and then you don't care :-)
But it's not a problem. I never had problems with this, it was just a suggestion.

Hmm... ok, you should add an issue to the task tracker, and maybe I'll take a look at it for SFML 2.1

Done.