Messages

166

Feature requests / Iconified event or window state

« on: July 23, 2008, 10:13:08 am »

automatically pausing the game when it is iconified, for example. no need to waste cpu cycles while the game isn't being played.

167

Feature requests / Iconified event or window state

« on: July 23, 2008, 08:31:00 am »

I already asked in an older thread of mine (other topic), but would it be possible to add iconified/uniconfied events, or an IsIconified() function? I'm fairly sure that type of event exist for all supported systems...

168

General discussions / Idling a program

« on: July 23, 2008, 08:27:48 am »

blocking calls cause the os to stop the thread until a packet is available. this means no CPU cost at all while waiting for the packet. if you use polling with sleeping (as proposed), you'll be checking & rechecking (wasting cpu power) and if you sleep too long, you'll get the packet later than you would have using a blocking call.

169

General discussions / Idling a program

« on: July 22, 2008, 11:14:18 am »

the right solution would be to use blocking calls for receiving network packets...

170

SFML wiki / [Tutorial] Manage dynamic key binding.

« on: July 13, 2008, 04:29:49 pm »

I just converted the tutorial code to do what I was trying to explain in my previous post:

Code: [Select]


#include <iostream>
#include <boost/function.hpp>
#include <SFML/Graphics.hpp>
 
enum InputType
{
    KeyboardInput,
    MouseInput,
    JoystickInput
};
 
struct MyKeys
{
    InputType myInputType;
    sf::Event::EventType myEventType;
    sf::Key::Code myKeyCode;
    sf::Mouse::Button myMouseButton;
};

static bool operator<(const MyKeys& a, const MyKeys& b)
{
if(a.myInputType != b.myInputType)
return a.myInputType < b.myInputType;
else if(a.myEventType != b.myEventType)
return a.myEventType < b.myEventType;
else if(KeyboardInput == a.myInputType)
return a.myKeyCode < b.myKeyCode;
else if(MouseInput == a.myInputType)
return a.myMouseButton < b.myMouseButton;
else
return false;
}
 
bool TestEvent (MyKeys k, sf::Event e);
void Shoot (void);
void Jump(void);
void Use(void);
 
int main(int argc, char** argv)
{
//Variables for main
sf::RenderWindow App;
bool Running = true;
sf::Event Event;

//Variables for demo
typedef std::map<MyKeys,boost::function<void (void)> > BindingMap;
typedef BindingMap::iterator BindingIterator;
BindingMap Keys;
MyKeys key;
//Let's bind the left mouse button to the "Shoot" action
key.myInputType = MouseInput;
key.myEventType = sf::Event::MouseButtonPressed;
key.myMouseButton = sf::Mouse::Left;
Keys[key] = &Shoot;
//Let's bind the Return key to the "Jump" action
key.myInputType = KeyboardInput;
key.myEventType = sf::Event::KeyPressed;
key.myKeyCode = sf::Key::Return;
Keys[key] = &Jump;
//Let's bind the Left Control key to the "Use" action
key.myInputType = KeyboardInput;
key.myEventType = sf::Event::KeyPressed;
key.myKeyCode = sf::Key::LControl;
Keys[key] = &Use;
 
//Window creation
App.Create(sf::VideoMode(640, 480, 16), "config test");
 
    //Main loop
    while (Running)
    {
        //Manage Events
        while (App.GetEvent(Event))
        {
            //Using Event normally
 
            //Window closed
            if (Event.Type == sf::Event::Closed)
            {
                Running = false;
            }
            //Key pressed
            else if (Event.Type == sf::Event::KeyPressed && sf::Key::Escape == Event.Key.Code)
            {
Running = false;
}
else if (Event.Type == sf::Event::KeyPressed && sf::Key::A == Event.Key.Code)
{
std::cout<<"Key A !"<<std::endl;
            }
            //Using Event for binding
else
{
key.myEventType = Event.Type;
switch(Event.Type)
{
case sf::Event::KeyPressed:
case sf::Event::KeyReleased:
key.myInputType = KeyboardInput;
key.myKeyCode = Event.Key.Code;
break;
case sf::Event::MouseButtonPressed:
case sf::Event::MouseButtonReleased:
key.myInputType = MouseInput;
key.myMouseButton = Event.MouseButton.Button;
break;
default:
continue; // skip to next event
}

BindingIterator it = Keys.find(key);

// Binding for event found - execute bound action
if(Keys.end() != it)
it->second();
}
        }
 
        //Display the result
        App.Display();
    }
 
    //End of application
    return EXIT_SUCCESS;
}
 
void Shoot (void)
{
    std::cout<<"Shoot !"<<std::endl;
}
 
void Jump (void)
{
    std::cout<<"Jump !"<<std::endl;
}

void Use (void)
{
std::cout<<"Use !"<<std::endl;
}



171

SFML wiki / [Tutorial] Manage dynamic key binding.

« on: July 13, 2008, 02:24:25 pm »

I would also suggest using function pointers (or even better: also allow functors -> http://www.boost.org/doc/libs/1_35_0/doc/html/function.html )

Furthermore: I think you should 'invert' the way your key binding works. At the moment, you check for every possible action if it matches the current event. This is highly inefficient (and inflexible) IMHO. I think it would be a lot better to have a map indexed by events (or even better an unordered_map / hashmap) with appropriate actions for that event (in the form of functors/function pointers). That way, you receive an event, check if it is in the map/hashmap and execute the bound action. This would allow for easy extension and reduce the amount of work inside the loop drastically.

172

Window / 2 render windows?

« on: February 05, 2008, 11:15:18 am »

Ah, I didn't know that (I mainly use the Window+System packages).

173

Feature requests / Separate Window.Display from event polling

« on: February 04, 2008, 09:35:53 pm »

E.x. "is a mouse move or mouse click event inside a certain GUI element?" in the event thread and "draw a certain GUI element" in the graphics thread - both would be accessing some rectangle (x, y, width, height) which would then have to be made threads safe with a mutex which would then lower performance due to thread synchronization.

Please note that this only is some naive thinking from me - I've never really used a GUI system.

Some things might be shared (hard to avoid, but should be minimized as much as possible), but in this case for example, both accesses are read accesses, so they can be done in parallel. And for write accesses (which should never be caused by the renderer thread) we'd either have to lock, or find a lockless solution. Or use a pipeline approach. Or double buffer the GUI data. There are many solutions to these kind of problems, the hard part is figuring out which one's the best.

174

Window / 2 render windows?

« on: February 04, 2008, 07:34:22 pm »

I'm not entirely sure if I understood the problem correctly, but if you want two virtual windows inside a single real window, why don't you simply use glViewport?

175

Feature requests / Separate Window.Display from event polling

« on: February 04, 2008, 07:11:44 pm »

Hehe, that's what I actually do.

I don't really have time to add things to SFML, I don't have time for my own projects... :x
SDL ? No, thanks.
And as I use 2d drawing facilities of SFML, GLFW is not really usefull (as you said).

Thought as much. (Who in the right mind would use SDL if they can use SFML...)

Thanks for your suggestions l0calh05t.

No problem.

176

Feature requests / Separate Window.Display from event polling

« on: February 04, 2008, 06:19:07 pm »

btw, if you mainly want to save cpu time when no events are received you could do the following:

instead of:

Code: [Select]


while(running)
{
  while(GetEvent())
  {
    // process event
  }
}


which is obviously inefficient if you don't do anything except for processing events do the following:

Code: [Select]


while(running)
{
  if(GetEvent())
  {
     // process event
  }
  else
  {
    Sleep(0.01f); // sleep for 10ms
  }
}


This should lower cpu usage from 100% to ~2% (as long as there is no excessive processing associated with any specific event)

But if you really, really need passive event polling there are 3 options:
1) Add it yourself (should be easy enough)
2) Use SDL, despite it's somewhat large size, C-Style interface and LGPL license
3) Use GLFW, despite it's lack of support for multiple windows, C-Style interface and being only a framework for creating a valid GL context. (No audio, high-level graphics objects etc.)

177

Feature requests / Separate Window.Display from event polling

« on: February 04, 2008, 03:53:18 pm »

Ok. I haven't read the code and supposed poll was done every call. :oops:
Sorry.

I'll never have my passive waiting ! :cry:

EDIT : Yep, it's a different one Look at this one : Attente passive.

Ah, I see. Although I don't need passive waiting myself I see why you'd like to have it.

Under Win32 it's easy enough to wait for events, just use GetMessage instead of PeekMessage, similar commands should exist for X11 and OSX as well

178

Feature requests / Separate Window.Display from event polling

« on: February 04, 2008, 03:08:45 pm »

It's not actually a memory leak since it's the intended behavior.

Certainly not intended by the person who only wants to use asynchronous input :wink:

Splitting event handling from window display is a great suggestion, I've thought of it a few times, but your model isn't really adequate.

Polling the system through system calls (even if highly optimized) every time GetEvent is called is all but efficient.
I understand backward compatibility issues, but I submitted another suggestion a few weeks ago which aimed at the same system of SFML, so :
There could be two functions, PollEvents() et WaitEvents(), which would poll the event loop of the system. The two would add events to SFML events queue, as it currently is. WaitEvents would act as PollEvents do, unless the first poll is empty, if so, WaitEvents would enter in passive wait from the system.

The way it is done right now, is that GetEvent only polls system events when the queue is empty, so on average you will be polling system events twice every event loop (at the beginning and at the end). It is highly unlikely that this will become a bottleneck for your app.

EDIT: Which of your threads are you talking about? I only found http://sfml.sourceforge.net/forum-fr/viewtopic.php?t=419 but I assume you mean a different one?

179

Feature requests / Separate Window.Display from event polling

« on: February 04, 2008, 01:48:56 pm »

Understandable, but even if you do keep Event handling in Display, not calling GetEvent will still cause major problems. Why? Well, you'll have a queue to which you are consistently appending events at a fairly high rate, and if they are never removed from the queue this will cause one big memory leak...

180

Feature requests / Separate Window.Display from event polling

« on: February 04, 2008, 11:13:51 am »

If the only thing is to remove possible event handling from Display(), it can already be done without changing the code. As you say, the only drawback is that events won't be polled if the user forgets to call GetEvent. But I don't get the point of adding functions such as SetAutoPollEvents or PollEvents.

Ok, assume you remove event polling from Display (this is what you are suggesting, correct?), then how does GetEvent know if it already polled recently? (Hmm... maybe if events are polled whenever the Queue is empty... that should work) Assuming this problem is solved, what if someone only uses Asynchronous input? (IsKeyDown etc.) Eh... well, actually those have to do GetEvent anyways as they probably also need to know when the window is closed, so I guess that is no real problem.

Solving the problem with SetAutoPollEvents and PollEvents is merely what I would have done, but if you manage to solve this without making the API more complex  that would obviously be better.

EDIT:
I rewrote GetEvent to

Code: [Select]


bool Window::GetEvent(Event& EventReceived)
{
// Let the window implementation process incoming events
if (myWindow && myEvents.empty())
{
myWindow->DoEvents();
}

    // Pop first event of queue, if not empty
    if (!myEvents.empty())
    {
        EventReceived = myEvents.front();
        myEvents.pop();

        return true;
    }

    return false;
}


and removed

Code: [Select]


    // Make sure events have been processed
    if (myWindow && !myEventsProcessed)
    {
        myWindow->DoEvents();
    }
    myEventsProcessed = false;


from Display, and it seems to work and should be threadsafe (unless GetEvent is called from different threads but that would be pretty nonsensical anyway)