Messages

1

General / SFML freezes when mouse moves (VS 2010)

« on: August 25, 2011, 12:38:33 am »

I too am seeing this, in VS2005 / SFML2.

2

General / SFML does not show windows on x64

« on: March 30, 2011, 11:20:38 am »

And I guess the difference in API between 1.6 and 2.0 is fairly large too? So my choices are:
- Ship with an old version of the driver dll
- Do the merge from hell
- Upgrade to SFML 2.0 and rewrite my code accordingly.

I love SFML, it's been very good to me and I'm honestly very grateful for the work you've put in. But it sucks that your stable branch has a known crash bug that affects ~30% of your userbase which isn't going to be fixed.

At the very least it's worth putting a warning on the download page saying "if you want your app to work with ATI cards, use SFML 2". Or then promote SFML2 as the stable version and ditch 1.6 altogether

3

General / SFML does not show windows on x64

« on: March 30, 2011, 10:43:17 am »

Looks like I'm either merging the patch and recompiling from source then, or hoping someone else does.

4

General / SFML does not show windows on x64

« on: March 29, 2011, 11:58:13 pm »

I have the OP's problem in an app that doesn't open any GL windows, only the default console. It uses sf::Image, dynamically linked.

I upgraded to the Catalyst drivers pushed out by Windows Update and it stopped working.
I upgraded to the latest Catalyst drivers - released today - on AMD's website and it still doesn't work.
The workaround posted above, using 10.4's atigktxx.dll, works for me.

SFML 1.7 on Win7 x64 here. I can try to get a minimal code sample if it helps.

edit:\ Minimal code sample follows:

Code: [Select]


#include <iostream>

#include <SFML/Graphics.hpp>

int main(int argc, char **argv)
{
std::cout << "Main entry." << std::endl;

sf::Image img;
img.LoadFromFile("test.bmp");

std::cout << "Image loaded." << std::endl;

int i;
std::cin >> i;
return 0;
}


This prints nothing (not even "Main entry.") and hangs. Linking against sfml-graphics only with SFML_DYNAMIC defined.

5

Network / Binding two sockets to same port doesn't return false

« on: October 17, 2010, 11:41:44 pm »

Hngh, okay. I've already implemented my own checking for this, but at least it's in 2.0 for others

6

Network / Binding two sockets to same port doesn't return false

« on: October 17, 2010, 11:30:25 pm »

Fantastic, thanks a lot. Is that fixed in SFML 2 only or is it in the 1.6 download / 1.7 snapshot?

7

Network / Binding two sockets to same port doesn't return false

« on: October 17, 2010, 04:22:09 pm »

This thread says I should be getting a message on stderr if I attempt to bind two sockets to the same port. I don't (and have tested it's not an issue with my IDE by spewing my own text to stderr, which displays fine).

Additionally, the second (illegal) call to Bind() returns true. Surely it should return false if this is not allowed?

I'm on SFML 1.6, Win7 x64 if that helps.

8

Network / sf::Socket::Error when reading into a buffer too small

« on: October 03, 2010, 09:06:11 pm »

I guess it depends on the range of errors covered by sf::Socket::Error. If they're all recoverable and result in the loss of the packet, but don't have any further consequences (like the socket being closed), then I guess it's fine.

9

Network / sf::Socket::Error when reading into a buffer too small

« on: October 03, 2010, 07:31:39 pm »

I've done a little experimentation and it turns out that while you do get sf::Socket::Error, it also discards the message and the next call to Receive() will give you the next message. For some reason I thought it would get "stuck" attempting to read the same data into the buffer repeatedly, which was the cause of my frustration. So for my purposes I can simply set the buffer to be the maximum size of any valid message I expect to receive and anything bigger than that automatically gets thrown away.

However, there still remains the issue of not being able to tell it apart from a more "serious" error. I don't think it's right to treat "someone sent a malformed packet" the same as "the connection has been forcibly terminated".

10

Network / sf::Socket::Error when reading into a buffer too small

« on: October 03, 2010, 07:05:14 pm »

I have an SFML 1.6 non-blocking UDP socket which I am receiving raw data from. As per the example in the tutorial I am calling Skt.Receive(), passing in a buffer to fill. When the buffer is too small to fit the data, Receive() returns sf::Socket::Error.

Unfortunately I appear to have no way of distinguishing this (easily rectified!) error from more serious errors that may have occurred. WSAGetLastError() on Win32 returns a specific error code WSAEMSGSIZE when the buffer is too small, and a little research shows *nix puts EMSGSIZE in the errno variable to indicate the same issue. However, checking these rather defeats the point of using SFML for cross-platform compatibility.

So, in an attempt to do things "the SFML way": is there a way I can peek at the top message in the socket's recv buffer to determine how long it is? Or a way to get the socket to truncate the message and return the data up to the size I passed in (as the standard implementation of recvfrom() does)?

I could simply allocate an array of size 65516 (the maximum amount of data you can fit into an IP packet), but that's a really poor workaround.

Any tips, or should I break out the #ifdefs and write my own error lookups to catch this situation?

edit:\ Just noticed a similar thread here - I guess I'm doing it myself.

11

General / Disabling language extensions in MSVC causes errors in 1.6

« on: October 03, 2010, 06:00:30 pm »

To follow up on this - it's an issue with the MS headers. The latest SDK (Win7 7.1) is even worse than 6.1 (Server 2008) - the only issue I've had with SFML 1.6 is the network package (although I've not tried the Audio package yet).

I'm going to be creating a separate project for network stuff anyway, so I'll wrap SFML's functionality in that; then I'll only have to work with language extensions disabled in that project and not the others.

12

General / Disabling language extensions in MSVC causes errors in 1.6

« on: October 01, 2010, 12:09:59 am »

I'm not including any Windows headers in my project myself. The list of external includes I'm using, in order, are:

Code: [Select]

<GL/glew.h> - OpenGL extension handler
<SFML/Window.hpp>
<SFML/System/Clock.hpp>
<SFML/Graphics.hpp>
<SFML/Network.hpp>

Shuffling around the include order of these doesn't get me anywhere. I get the same errors (and some extra C4251 warnings thrown in for good measure).

edit:\ I've just checked and I can reproduce the issue simply by including SFML/Network.hpp in a single-file C++ project:

Code: [Select]

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

int main(int argc, char **argv)
{
std::cout << "Hello, world!" << std::endl;
return 0;
}

Gives me the same error with language extensions disabled.

13

General / Disabling language extensions in MSVC causes errors in 1.6

« on: September 30, 2010, 11:43:45 pm »

Apologies for the thread necromancy, but it's related so I figured I might as well.

I've just #included <SFML/Network.hpp> in my project. As well as a bunch of C4251 warnings (which I see in 2.0 you've just #pragma'd out, so I'll do the same locally), I am also getting this:

Code: [Select]

1>C:\Program Files\Microsoft SDKs\Windows\v6.1\include\ws2def.h(567) : error C2467: illegal declaration of anonymous 'struct'

The include tree that gets me there is as follows:

Code: [Select]

SFML/Network.hpp
SFML/Network/Ftp.hpp
SFML/Network/SocketTCP.hpp
SFML/Network/SocketHelper.hpp
SFML/Network/Win32/SocketHelper.hpp
winsock2.h
ws2def.h

Once again, if I disable language extensions the error goes away. I'm on VS2005 so I can't upgrade my Windows SDK any further than the 6.1 I'm already on. And Google turns up nothing of use at all, oddly enough.

Am I stuffed?

14

General / Disabling language extensions in MSVC causes errors in 1.6

« on: August 14, 2010, 11:36:40 pm »

Good news! I couldn't get the latest Windows SDK, because I'm on VS2005 and the Win7 one doesn't support it. But I downloaded the Windows Server 2008 SDK, pointed my VC++ Directories to the new location, and hurrah! It builds with language extensions disabled

Thanks for the tip, it was right on the money

15

General / Disabling language extensions in MSVC causes errors in 1.6

« on: August 14, 2010, 08:21:50 pm »

2. Has anyone got any tips on getting this to work on 1.6?

Don't know if it's true, but...
http://cboard.cprogramming.com/windows-programming/105719-errors-including-windows-h.html#post776204

Interesting, I'll take a look at that. Apparently the very latest (Win7) SDK doesn't play nicely with VS2005, which is what I'm on, but I'll try the Server 2008 one and see if that helps any. Thanks!