Messages

1

Network / Re: Multi-threading required for client and server, and thoughts on a proposed setup

« on: July 18, 2013, 05:39:05 pm »

Binary1248, I really appreciate the help. The logical course of action for me seems to be to just use simple TCP through prototyping, and if I see a good reason to switch to UDP with NAT Punch-through that option is definitely there.

I feel like this thread should be made into a sticky in the Networking category or something. There is a LOT of information here. When I get some basic stuff working, and a better handle on what is going on, I will likely write up a tutorial on the basics of the subject (with major credit to Binary obviously). There isn't a good place to get all this information in a logical format.

2

Network / Re: Multi-threading required for client and server, and thoughts on a proposed setup

« on: July 18, 2013, 05:21:29 am »

So, since this thread is already full of Networking-related questions, I have another one for you.

I want a player to be able to host a game for his friends to join. I have read a few articles on NAT punch-through, but this seems to only be done easily for UDP. It looks like all you need is a server that the host and clients can connect to, and that server will tell the clients how they should connect to the host in order to join his game. As I said, from what I understand, it isn't this easy at all if you want to use TCP. The best article I have found is this one :

http://www.mindcontrol.org/~hplus/nat-punch.html

Do you know of a way to solve this issue using TCP?

Thanks,
Charlie

3

Network / Re: Multi-threading required for client and server, and thoughts on a proposed setup

« on: July 17, 2013, 10:29:22 pm »

I was using them to ensure that my program didn't get stuck. Would you recommend I put a wait time on a selector? I just don't want to wait too long since you don't want a game to fall 1 second behind.

4

Network / Re: Multi-threading required for client and server, and thoughts on a proposed setup

« on: July 17, 2013, 09:52:53 pm »

How do you check if you have a successful connection between the client and server? I was basing it off of the values returned from the connect() and accept() functions.

The client's connect function returns "Not Ready", but the server's accept returns "Done". I was lead to believe that if the server's accept returns "Done", then the connection was successful. If that is the case, then why is the client saying it wasn't?

5

Network / Re: Multi-threading required for client and server, and thoughts on a proposed setup

« on: July 17, 2013, 07:29:57 pm »

So, the client handles the physics unless something like user input, is involved? Collisions and Gravity are all handled by the client? I assume you want to have some way for the server to make sure there isn't any fowl play going on.

6

Network / Re: Multi-threading required for client and server, and thoughts on a proposed setup

« on: July 17, 2013, 07:02:48 pm »

So, how is this setup then?

The server sends actual positions every physics frame at 30 physics frames per second.

I set it up with a one-frame lag by default, and then just interpolate between the last and most recent physical frames. Then if I incur lag from the server, then the client uses the previous correct frame to extrapolate a temporary "Current" , which I replace as soon as I get it from the server.

Does that make sense?

7

Network / Re: Multi-threading required for client and server, and thoughts on a proposed setup

« on: July 17, 2013, 05:12:52 pm »

Assuming your numbers are correct, the UDP argument seems pretty silly at this point. I was led to believe that TCP was MUCH slower in the end. In that case, I'll move forward using TCP.

Also, I'm not running simulation on every computer. I'm planning on just sending user input to the server, and receiving back any changes based on that input.

8

Network / Re: Multi-threading required for client and server, and thoughts on a proposed setup

« on: July 17, 2013, 03:50:34 pm »

OK, so that bring up another issue. You are speaking in relation to TCP. The way I understand it, you should never use TCP for real-time data in a game. I have read this from multiple sources. For example : http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/

Why don't you use UDP?

9

Network / Re: Multi-threading required for client and server, and thoughts on a proposed setup

« on: July 17, 2013, 03:00:07 pm »

Thanks for all the info. I read the packet tutorial, and I still have one question.

Let's assume I have something like the following code. If I am in the middle of handling physics, but one of my connection tries to send me data, what happens to that data? Is it just sort of cached in my socket until I get back there to handle it? If this is the case, what happens if I received 4 messages from one socket in the time it took to get back? I would assume I should expect this to happen.

while(serverIsUp)
{
    if (selector.wait(sf::seconds(10)))
    {
        // for each socket...
        {
            if (selector.isReady(socket))
            {
                socket.receive(...);
            }
        }
    }

    handlePhysics();
}
 

Thanks again for all the help. I want to make sure I understand what is going on.

10

Network / Multi-threading required for client and server, and thoughts on a proposed setup

« on: July 17, 2013, 04:21:48 am »

So, I'm trying to get a basic client-server setup working. I have looked at the provided example, but the server simply waits until it gets a request, responds, and then it will close at the next bit of user input.

I want to build a real working example where the server constantly simulates physics, until it receives a packet, and the client should draw graphics at all times while listening for packets from the server.

I would assume that the only way to solve this is for both the client and server to have separate threads for listening for connections.

I have a simple setup in mind that I would like input on. I can see some issues with this, which I will bring up as well.

Server :
-Has two threads, one for Listening/Processing packets, and one for constantly simulating physics.
-If it receives input, it makes this change in a thread-safe buffer that is available to the other thread.
-If it receives any information requests, the listener responds with the requested info.
-Server updates all clients with updated physics states at a regular interval.

Client:
-Has three threads, one for listening to the server, one for drawing graphics/game logic, and one for audio.
-There is a physical state buffer that is always updated on a regular interval with information from the server. this stores information about the entities that should be watched as they aren't at rest.

I do have some questions about this setup though.

-On the client, it seems that it requires at LEAST 3 threads, but what happens if your processor only supports 2 threads?

-Even if the computer can still handle all the threads, is one thread for networking enough? What if I need to send a packet to the server, at the exact time that the server is trying to send me a packet? Are both of our packets lost?

I appreciate any input you guys can give me, as I'm new to real-time network programming.

11

Window / Re: Call Keyboard::isPressed() in another class?

« on: October 10, 2012, 01:44:19 am »

I think what hurt me here is the assumption that Keyboard was handled similarly to an event. I looked into this last night, and I guess I either didn't look in the right place, or I missed the static keyword (dunno how). I know what static means, lol.

12

Window / Re: Call Keyboard::isPressed() in another class?

« on: October 09, 2012, 11:56:29 pm »

I looked over the docs, and I didn't see where it said I could call it from anywhere I wanted. I didn't test because I assumed it would be more difficult than that. Thanks for the help.

13

Window / Call Keyboard::isPressed() in another class?

« on: October 09, 2012, 10:56:42 pm »

Hey guys,
So I want to be able to call Keyboard::isPressed() in another class. Basically, I have a class that handles mapping keyboard and gamepad input. Do I need to have a pointer to my original sf::Window to call Keyboard::isPressed() ? If not, what do I need to pass to my class/function in order to check what keys are pressed?

14

Window / (SFML2) Possible to render OpenGL to a Window in a separate class?

« on: October 09, 2012, 03:18:16 am »

Hey guys,
So I am using OpenGL to draw to an sf::Window in SFML2. The general working setup is something like this :

while(window->isOpen())
{
    sf::Event event;
    while (window->pollEvent(event))
    {
        // Request for closing the window
        if (event.type == sf::Event::Closed)
            window->close();
    }
    window->setActive();
     
    //DO OPENGL STUFF HERE
           
    window->display();
}  

What I need to do is have a function inside another class that can actually handle the OpenGL portion of the code. Is this even possible in OpenGL? I tried doing something like this, but I get a SegFault when I try to call localWindow->setActive(); :

Renderer.h

class Renderer
{
private:
    Window* localWindow;

public:  
    Renderer(sf::Window* inWindow)
    {
        localWindow = &inWindow;
    }

    void draw()
    {
        localWindow->setActive();

        //OPENGL STUFF HERE!
    }  
}

Main.cpp

#include "Renderer.h"

sf::Window* window;
Renderer renderer(window);

void main()
{    
    //Create new Settings and Window to point "window" to.
    sf::ContextSettings settings;
    settings.antialiasingLevel = 4;
    settings.majorVersion = 3;
    settings.minorVersion = 3;
   
    sf::Window localWindow(sf::VideoMode(800,600), "OpenGL", sf::Style::Default, settings);
   
    window = &localWindow;
   
    graphics();
}

void graphics()
{
    while(window->isOpen())
    {
        sf::Event event;
        while (window->pollEvent(event))
        {
            // Request for closing the window
            if (event.type == sf::Event::Closed)
                window->close();
        }
        window->setActive();
         
        renderer.draw();
           
        window->display();
    }
}

15

General / Re: Correct way to handle physics time-stepping

« on: October 05, 2012, 11:47:03 pm »

Haha, my Physics engine isn't too complex. It just has a couple weird features, and uses Separating Axis Theorem to handle my collisions.

I believe my issue is that I was over-complicating the problem. I'll test my code out using your example and see how that works.

Thanks.