Messages

16

General discussions / Re: SFML 2.0 RC

« on: July 09, 2012, 11:03:07 pm »

Ah, good point. I guess it would still be a bit cleaner to replace Keyboard::Key(0) with Keyboard::Unknown though. I wouldn't only call it a "« problem »" though. :p
It is an issue that can limit the usefulness of KeyEvents quite a bit.

17

General discussions / Re: SFML 2.0 RC

« on: July 09, 2012, 10:44:54 pm »

I stumbled upon a problem while implementing an event-based remappable input system: SFML makes no distinction between unknown keypresses and "A" keypresses. While this might not be a big issue for QWERTY users, other keyboard layouts, particularly QWERTZ (which is what I am using) have lots of keys that are not correctly picked up by the sf::Window implementation and end up being incorrectly fired as "A" keypresses (specifically, the ÄÖÜß^<# keys on QWERTZ keyboards). I described the issue and a possible, hopefully non-API-breaking fix here. It basically involves adding an extra key (sf::Keyboard::Unknown or something like that) to the sf::Keyboard::Key enum and replacing instances of the bottom-catcher "return Keyboard::Key(0);" (which happens to be "A") in the sf::Window implementations with "return Keyboard::Unknown;".

This is quite a big issue in my opinion, and any kind of temporary "quick fix" would be better than having no way to eliminate incorrectly fired "A"-key events.

18

General discussions / Re: SFML 2.0 RC

« on: July 08, 2012, 03:31:46 pm »

Ah well, it's probably not worth trying to find a clean solution to this then. I'll just keep manually removing it myself then, it's not a big deal.

19

General discussions / Re: SFML 2.0 RC

« on: July 08, 2012, 11:47:06 am »

I have no experience with automatic building tools and how to supply them with parameters. What would adding something like a checkbox to cmake to toggle a certain compiler flag that switches inclusion of Arial.hpp for a project involve? How would it complexify the API? If it's too complicated, then it's probably not worth the effort for the potentially saved memory, but I will still keep manually commenting it out everytime I update SFML (which I do quite frequently throughout development). Even a compilation flag/macro (#define SFML_NO_BUILTIN_FONT?) without any cmake-visible option would help speed up that process.

20

General discussions / Re: SFML 2.0 RC

« on: July 07, 2012, 11:30:48 am »

Building without Arial.hpp makes libsfml-graphics.so 269 KB on my system, so the inclusion of a default font file does add quite some size bloat, looking at it in relative numbers (>100% of the original size). While in absolute numbers, ~300 KB may indeed not be that much, I imagine only a small number of people actually use it, as most of them actually want to switch to their preferred font or write a customized bitmap text renderer.
It looks more like a debug feature to me that is primarily used by people who want a quick prototype program without any other resources, but it is not really something anyone would use in a large-scale project. I actually was not even aware of its presence and always assumed SFML would fail to display text if you didn't load a ttf file, until I checked out the source code.

21

General discussions / Re: SFML 2.0 RC

« on: July 06, 2012, 01:38:35 pm »

Speaking of a built-in default font, it would be nice to have an easy way (perhaps some sort of compilation flag) to build SFML-Graphics without including Arial.hpp (or DejaVu.hpp if it's changed to that), without having to manually comment it out everytime. I personally never use sf::Text, as I have my own class that renders bitmap text, so there is essentially >300 KB of useless data in the graphics dll.

22

Feature requests / Re: Public extract() function for sf::Packet

« on: April 26, 2012, 01:03:48 pm »

Ah, sorry, I searched the forums only, forgot that the tracker was for suggestions too. :p

23

Feature requests / Public extract() function for sf::Packet

« on: April 26, 2012, 12:54:49 pm »

Hello,

I have recently switched from TCP/UDP mixed to UDP only networking code. The protocol I am designing for my project will have to be as optimized as possible, as ~20 packets per second will be transferred between server and client. I use strings quite frequently in the protocol, but when I checked out the way SFML handles strings, I saw that it actually stores 4 bytes for the string length in the packet, despite UDP having a maximum packet size of slightly less than Uint16's max value. Because I send quite a few strings per packet, ranging from 2 to around 10, the difference of bytes per second compared to if SFML would use 2-byte length markers for strings does add up to quite a bit (few hundred bytes per second), and when doing networking, memory optimization is highly important.

I thought I would just write a "ShortString" class that works just like a string, but has its max length capped at UDP's maximum packet size, and when appended to a packet using the bitshift operator overloads, the packet would just use sf::Uint16 for length rather than sf::Uint32. Appending the string works using the public append() function, but I can't find a way to extract the string efficiently. The internal method for extracting a string relies on a private class variable, so the only way to do it would be extracting the string char by char, which is obviously unoptimized and slow. So, I would like to propose a public function for sf::Packet that takes a length (the read position would be moved by that amount) and returns a const void * or const char * to "getData() + m_readPos" before the read position was moved. The function could be called "const char * sf::Packet::extract(std::size_t lengthInBytes)". This would effectively give the developers more control about extracting custom data types from packets, as the append function already makes it possible to insert any kind of data.

tl;dr: something like this:

const char * sf::Packet::extract(std::size_t lengthInBytes)
{
    if (!checkSize(lengthInBytes))
        return NULL;

    const char * ret = getData() + m_readPos;
    m_readPos += lengthInBytes;
    return ret;
}

24

Network / Re: Non-blocking TCP always returns Error when trying to connect to server (Windows)

« on: April 02, 2012, 04:23:34 pm »

No problem, I'm really glad I could help improve this great library!
Good luck with debugging the code, and keep up the great work!

25

Network / Re: Non-blocking TCP always returns Error when trying to connect to server (Windows)

« on: April 02, 2012, 02:02:37 pm »

Alright, I've nailed down the error to WSAGetLastError-code 10056, which is "socket is already connected". So I guess the Unix-like approach isn't quite applicable to Windows and connect() does not work as a polling function for non-blocking TCP sockets. Despite my knowledge about Winsock being virtually zero, I guess some research on how to properly deal with non-blocking TCP sockets couldn't hurt.

I will update this post once I find a possible solution.

EDIT:
Aaaaand already found something that looks very promising:
According to MSDN, you have to use the select() function to poll whether a non-blocking socket has successfully connected/is writable. It seems all you have to do is replace the connect() function with select() when working with a connecting non-blocking TCP socket on Windows. This will probably require some restructuring of the platform-independant part of the SFML socket code though, as you'll have to know when the socket is trying to "re-connect" to choose between calling connect() and select()...

EDEDITIT:
Actually, another approach would be to replace the current poll-ish system for the TcpSocket::connect() function with a single call to TcpSocket::connect() and then subsequent calls to TcpSocket::isReady() or something like that, just for non-blocking sockets. The Unix version of that code could maybe store the previous return codes to "remember" if it's ready or not. These are just my suggestions on how to possibly implement this, it's still up to you to decide if/how you are going to solve this issue.

26

Network / Re: Non-blocking TCP always returns Error when trying to connect to server (Windows)

« on: April 01, 2012, 09:09:27 pm »

Thanks for your response! ^^

I've been messing around with the timeout, and it didn't seem to have any effect.

I would love to help with testing/fixing this, but unfortunately I have no idea how WinSock works, and actually I'm not even sure what part of the code is causing the error, as "sf::Socket::Error" catches pretty much any kinds of implementation errors as well as various "higher-level" errors that can occur at all.

27

Network / Re: Non-blocking TCP always returns Error when trying to connect to server (Windows)

« on: April 01, 2012, 07:57:10 pm »

Sorry for double-posting here, I am not so sure what the rules on this forum are concerning that, but I really can't figure out what is wrong with my code, and this is kind of hindering the development/testing progress of what I'm currently working on.

I have checked out the SFML source code, and there are lots of possible causes for the sf::Socket::Error return value, so I couldn't really figure out the exact reason for why this error is occuring. Does anyone else here constantly get this problem when trying to work with non-blocking TCP sockets; i.e. is it a bug in SFML's Winsock implementation, a mistake in my code or just my Windows acting up?
A possible workaround for this is to set the socket as blocking when connecting, and then switch to non-blocking mode when sending/receiving. This only functions as a temporary workaround though, as it will lock up the application during the process of connecting, unless a thread is used. Besides, if it actually isn't just an anomaly on my system, it is probably supposed to work as the developer would expect it to rather than having to use a workaround like that.

TL;DR: Am I the only one having being unable to use connect() on non-blocking TCP sockets on Windows?

28

Network / Non-blocking TCP always returns Error when trying to connect to server (Windows)

« on: March 30, 2012, 09:22:47 pm »

Hello,

first off, my apologies for bothering with pretty much the same issue as last time again. I have been trying to compile my project for Windows, and everything is working flawlessly except for the client's TCP socket. Using a similar code setup as described in the previous thread about a related uncertainity, upon trying to connect, the non-Blocking TcpSocket first returns "NotReady" (as expected), but any subsequent calls to connect() result in "Error" being returned. The server can see the client connecting, but as soon as "connect()" is called client-side a second time, it seems to disconnect again. The following code example that resembles the one linked to before reproduces the issue for me: connecting to a valid server with a non-blocking TCP socket prints "Socket not ready" once and then enters an infinite loop of "Socket error":

Code: [Select]

int main()
{
    sf::TcpSocket netTCP;
    netTCP.setBlocking(false);
    while(true)
    {
        switch (netTCP.connect("localhost", 8989, sf::Time::Zero))
        {
        case sf::Socket::Done:
            std::cout << "Connection successful" << std::endl;
            return 0;    // success.
        case sf::Socket::Disconnected:
            std::cout << "Connection refused" << std::endl;
            break;
        case sf::Socket::Error:
            std::cout << "Socket error" << std::endl;
            break;
        case sf::Socket::NotReady:
            std::cout << "Socket not ready" << std::endl;
            break;
        default:
            std::cout << "Unknown Error" << std::endl;
            break;
        }
    }
}
Firewall exceptions and stuff are set up correctly, and the server can see the client connecting for a short moment, so it is probably a client-side problem. The same code works flawlessly on Linux.

Any help or information on what I might doing wrong here would be greatly appreciated.

29

Network / How to deal with non-blocking TcpSocket returning NotReady?

« on: February 24, 2012, 08:32:40 pm »

Ok, I'll do that, thanks for clearing this up!

30

Network / How to deal with non-blocking TcpSocket returning NotReady?

« on: February 24, 2012, 07:04:29 pm »

Hello,

right now, I am writing the networking code for my project and trying to figure out how to work with a non-blocking TCP socket for the client. Whenever I try to connect to my debug server, TcpSocket::Connect() returns Socket::NotReady, but the server can already see the connection and both server and client can send/receive packets. If I call TcpSocket::Connect() again, it returns Socket::Done. The different return values for the different socket functions don't seem to be too well documented, and checking the Unix implementation source code didn't help me much either since there seem to be various causes for Socket::NotReady.

I am using Crunchbang Linux and a quite recent SFML 2.0 (shortly after the time API change was committed), here is some example code that should reproduce the issue, provided it can connect to any TCP server running at the specified IP and port.

Code: [Select]

int main()
{
    sf::TcpSocket NetTCP;
    NetTCP.SetBlocking(false);
    switch (NetTCP.Connect("localhost", 8989, sf::Time::Zero))
    {
    case sf::Socket::Done:
        std::cout << "Connection successful" << std::endl;
        break;
    case sf::Socket::Disconnected:
        std::cout << "Connection refused" << std::endl;
        break;
    case sf::Socket::Error:
        std::cout << "Socket error" << std::endl;
        break;
    case sf::Socket::NotReady:
        std::cout << "Socket not ready" << std::endl;
        break;
    default:
        std::cout << "Unknown Error" << std::endl;
        break;
    }
}

Commenting out the "SetBlocking(false)" line prints "Connection successful". Changing the timeout does not seem to have any effect.
Should I just ignore the return value of Connect() if it's NotReady? If this is just a way for the socket to say, "I am connecting, wait until I am ready", I would like to know how to poll the socket status during that time, since sockets don't appear to have any kind of "IsReady()" function.
I tried searching the forums, and found someone who had a similar issue, but apparently it was related to the fact that they were using a SocketSelector, while this client-side code is only for a single TCP socket.

As always, any help or support is greatly appreciated. ^^