1
Network / Network functionality
« on: June 13, 2008, 06:19:58 pm »
Cool thanks
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1] 2
2
Network / Network functionality
« on: May 27, 2008, 07:08:26 am »
Checkin in again. I noticed the SetBlocking function has been added, so I've decided to give it another go.
So I SetBlocking(false) on a listener tcp socket, on the port I'm interested in. The problem now seems to be that SocketTCP::Accept doesn't return anything special to designate that there is no pending connection.
I would expect that when a non blocking listener socket is listening on a port, that each frame you can poll any pending connections and create them. At that point you'd have a SocketTCP for the clients connection, seperate of the listener socket. I presume that works if you use blocking sockets, but the non blocking socket support is incomplete in that regard, unless I'm missing something.
Calling SocketTCP.Accept on the non blocking listener socket right after Listen seems to return a normal error code(Done) as if it actually accepted a new connection immediately. I expect an immediate return, being non blocking, but how is the user expected to know when new client connections are opened?
Edit: Debugging a bit, it appears the problem is due to the
SetBlocking(true);
in the constructor SocketTCP::SocketTCP(SocketHelper::SocketType Descriptor)
When accept fails, with an error, this causes IsValid() to be == false, which causes SetBlocking to create a new socket with the following
// Make sure our socket is valid
if (!IsValid())
Create();
Simply remove the SetBlocking from that constructor and it allows Accept to properly fail and return NotReady
So I SetBlocking(false) on a listener tcp socket, on the port I'm interested in. The problem now seems to be that SocketTCP::Accept doesn't return anything special to designate that there is no pending connection.
I would expect that when a non blocking listener socket is listening on a port, that each frame you can poll any pending connections and create them. At that point you'd have a SocketTCP for the clients connection, seperate of the listener socket. I presume that works if you use blocking sockets, but the non blocking socket support is incomplete in that regard, unless I'm missing something.
Calling SocketTCP.Accept on the non blocking listener socket right after Listen seems to return a normal error code(Done) as if it actually accepted a new connection immediately. I expect an immediate return, being non blocking, but how is the user expected to know when new client connections are opened?
Edit: Debugging a bit, it appears the problem is due to the
SetBlocking(true);
in the constructor SocketTCP::SocketTCP(SocketHelper::SocketType Descriptor)
When accept fails, with an error, this causes IsValid() to be == false, which causes SetBlocking to create a new socket with the following
// Make sure our socket is valid
if (!IsValid())
Create();
Simply remove the SetBlocking from that constructor and it allows Accept to properly fail and return NotReady
3
Graphics / Strange Sprite Activities when using STL data structures
« on: December 14, 2007, 01:53:13 am »
Try storing a block* in your vector instead of the entire object.
4
Graphics / window style changes
« on: November 28, 2007, 03:26:33 am »
You're right, my bad. It's all good.
5
Graphics / window style changes
« on: November 27, 2007, 05:21:13 pm »
Is there a way I can get similar results out of the current version that I was getting previously? I would like a specified resolution of the client area, and not have the border and title bar effect that, even if it means the window itself is a bit larger. I haven't dug around to look for what exactly made it work that way before. Do you recall what does that?
When I run Quake 4, or HL2 in a window, and probably most games, I get a window larger than the specified resolution, so that the render window is the specified resolution, and not clipped by the title bar or border as sfml currently does.
When I run Quake 4, or HL2 in a window, and probably most games, I get a window larger than the specified resolution, so that the render window is the specified resolution, and not clipped by the title bar or border as sfml currently does.
6
Graphics / window style changes
« on: November 27, 2007, 04:33:03 pm »
Arg, turns out it was something simple enough I overlooked at first glance.
In WindowImplWin32.cpp
in the constructor, under
// In windowed mode, adjust width and height so that window will have the requested client area
change if(Fullscreen) to if(!Fullscreen)
In WindowImplWin32.cpp
in the constructor, under
// In windowed mode, adjust width and height so that window will have the requested client area
change if(Fullscreen) to if(!Fullscreen)
7
Graphics / window style changes
« on: November 27, 2007, 04:14:27 pm »
Btw, I'm using
new sf::RenderWindow(sf::VideoMode(800,600), "Window", sf::Style::NoStyle);
in the new svn code, and
new sf::RenderWindow(sf::VideoMode(800,600), "Window", sf::RenderWindow::Fixed);
in the old
win32, xp if it matters
new sf::RenderWindow(sf::VideoMode(800,600), "Window", sf::Style::NoStyle);
in the new svn code, and
new sf::RenderWindow(sf::VideoMode(800,600), "Window", sf::RenderWindow::Fixed);
in the old
win32, xp if it matters
8
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
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
9
Window / include files
« on: November 27, 2007, 03:37:20 pm »
Yea sorry about that. I thought it was isolated to 1 file but when I noticed it in another I elevated it to a forum post. It doesn't make much sense that you'd maintain 2 copies of headers, but whatever, now that I know the intent I can work around it and sync them myself.
10
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.
11
Feature requests / Gui package
« on: November 23, 2007, 09:30:30 am »
I've implemented guichan on top of SFML, which is a nice and very lightweight GUI library. It's not a fully skinnable and complex GUI system, but it's perfect for my needs. It has most of the normal GUI widgets(buttons, text boxes, text fields, radio buttons, check boxes, drop downs, windows, etc), and it's really easy to extend and add to, fast, and free of dependencies.
Heres some screens of my current usage.
http://www.omni-bot.com/wiki/index.php?title=Debug_Window
Heres some screens of my current usage.
http://www.omni-bot.com/wiki/index.php?title=Debug_Window
12
Feature requests / File manager
« on: November 09, 2007, 02:45:44 am »
Considered using PhysFS? Maybe with a C++ wrapper ? It's a pretty nice file system I use for a couple projects.
13
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?
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?
14
General discussions / Less formats vs less dependencies ?
« on: November 02, 2007, 02:34:35 pm »
SOIL supports plenty of the major formats, so I hope it gets to replace devil in SFML. Because I am impatient I went ahead and replaced devil with it in my local copy of the code and it was very simple. Now I'm free of external dependencies(I'm not using the sound libraries atm).
15
Graphics / Renderwindow from an existing process
« on: November 01, 2007, 02:44:21 pm »
SFML only uses opengl correct? It doesn't have an alternative 2d more like SDL does it? Reason I ask is that I'm rendering mostly a GUI(using http://guichan.sourceforge.net/), and when I tried OpenGL as a renderer in SDL, it actually performed slower than when I used the SDL 2d renderer(direct draw I think). I'm especially concerned about the need to do these expensive context switches every frame and that I might be taking a step backwards performance wise. Is there an alternative to the context switching you know of?
Pages: [1] 2