Topics

1

Graphics / window style changes

« on: November 27, 2007, 04:03:32 pm »

I updated to the svn code so I could get the loading stuff from archives support, and I noticed that the GUI system I'm using(guichan) was misbehaving, when it didn't previously.

After digging around a bit to find out what was up I noticed that what appears to have happened is that the style changes of the render window seems to have caused issue. For example, creating an 800x600 render window, creates an 800x600 window, but due to the title bar, the actual client area is not 800x600. Alt-printscreen to take a screenshot of the window in the svn version results in an 800x600 screenshot, when a similar screenshot in the release version produced an 806x625 screenshot, presumably accounting for the borders and title bar, and in that case my GUI was working flawlessly. Now with the changed style I presume, the actual client area is no longer the requested resolution, and as a result the rendering of the GUI is off a bit by expecting the render area to be 800x600, which also adversely effects mouse position->widget detection. The window implementation doesn't seem to account for this discrepancy in the requested and resulting resolution of the client area, so I can't tell the GUI renderer what the real width and height are to correct the problem.

Was this an intentional side effect of the style changings? A bug?

Thanks

2

Window / include files

« on: November 27, 2007, 06:52:58 am »

Is it just me or are there some old dangling headers in the include folder? For example, Window.hpp under include differs from the one under src, and by including the one from include it results in compiler errors. Same applies to RenderWindow. It's confusing and prone to errors being set up like this. If the directory structure is going to imply the seperation of source and headers it needs to stick to it, and only have header versions of user usable classes in the header folder, unless you mean to keep 2 copies of these files in sync, which is too prone to errors to be practical.

3

Network / Network functionality

« on: November 04, 2007, 08:24:41 pm »

Please forgive me if I overlooked this functionality, but it seems that the networking classes are lacking some pretty important functionality.

Threading the networking is overkill for many projects, so I was a bit surprised that there aren't any non blocking variations of the socket functions.

Additionally, it appears there is very little in terms of error reporting available for the sockets.

How do you check if a socket is connected? Like a SocketTCP::IsConnected.
How do you tell when a socket gets disconnected? Just returning false from Recieve and such is rather basic. How about some wrapped access to the actual socket errors ?

The blocking stuff is the biggest issue at the moment for me. It's not worth threading my current app for networking. I'd rather keep it polling each update, but I can't do that with the sfml networking as is. Any plans to improve this soonish?

4

Graphics / Renderwindow from an existing process

« on: October 30, 2007, 04:16:27 pm »

I posted this on the SDL mailing list, but in an effort to find an alternative to SDL I found SFML, and as much as I like it, it too suffers from the same problem I'm getting with SDL. I'm hoping this time there will be a workaround for the problem.

Hi all, new subscriber here.

This request might sound a bit odd but please bear with me.

Suppose you have a pre-existing program, in this case an existing game. Enemy Territory to be precise, or slightly more generically the Quake3 and Quake4 engine.

I've set up SFML to allow me to open an additional window from the same process to provide a canvas for debug tools and an attached gui for debugging and such. When I spawn the window, using sf::RenderWindow,  from within the game process the game stops rendering, presumably because it's an OpenGL powered game already, and maybe there can only be 1 OpenGL window to a process by default?

The question is, is there a way around this so one can spawn multiple OpenGL windows from a single process(and still have both render)? In my case I just want to prevent my SFML RenderWindow from breaking the game rendering. The game keeps running, I can break in the code and such, it's just the rendering appears to stop.

Any help greatly appreciated.