Day 183: Sync delay and improved camera movement

Today I started by adding a different sync method to the network object. Now each one of them records the time of the last sent packet, and the next one is only sent after a certain delay.

Just for fun I then tried to position the cameras in a way that the four clients looks like windows on the same scene, so that moving a cube across a border of a window would make it appear in the adjacent window (as in the picture). While I was trying to do it I noticed that the camera only had forward and right movements, but not vertical movement. I fixed that (and it was quite painful due to the yaw and pitch convertions), but now everything works properly.

Day 182: Full syncronization

Today I mainly did refactoring work.
This included:
- Moving both the send and receive function to the scene, in order to give to the user the power to define his own network protocol
- Improve the system to convert data in network format
- Abstract the message class and make room for extensions
- Allow to have both a server and a client on the same time

In the picture the top left program is a server, but it is also a client now, and all the 4 programs are synced.

Day 181: Network synchronization working

I finally managed to fix the bug I had yesterday, and it was a pretty unexpected one. Basically calling push_back on the vector of local network objects caused it to reallocate memory, thus calling destructors and contructors which messed up everything. I replaced it with a list, and everything is working.
I also added a variable to each net obj to keep track if it has been modified or not. This helps to reduce the amount of data sent.
In the picture the three client are perfectly synced, while for now the server is not. I have to decide whether to implement the same client logic inside the server, or if it would be better to just have both a client and a server on the same machine. Probably I'll go with the second one.

Day 180: Moving objects across the network

Today I created a Message structure to be exchanged over the network, and I added to it a transform field. At each frame, every client sends the updated position of each network objects it own, and also receives positions from the server and updates the network objects that it doesn't own.
The system is still not working properly, and for some reason only a couple of clients at the time syncs correctly. In the picture, that's the case with the two right clients. The two cubes in the up-left corner are synced over the network.
Another thing I noticed, there is a delay of about .3 seconds in the sync, despite the stable fps and the local network. I'll have to figure out why.

Day 179: Instantiation over network

Today I started by creating a better Address class, which extends and improves sockaddr_in.
Then I spent most of the afternoon implementing a system to instantiate objects over the network.
The Scene class now has a virtual function that gets called whenever a new message is received by a client not already registered. I'll probably make this function more general, as a "handle_server_message" function.
In the datagrams are included the ip and port of the sender in a compressed form, and they are stored in each network_object, along with a local id, to get a unique reference across the network.
In the picture the top right client starts to send a packet, and gets registered on the server.
The bottom left client then sends a message, and the message is forwarded to the first client, because it is registered. The scene then instantiate the gameobject in the handler function and adds to it a mesh and material.

Day 178: NetworkObject and refactoring

Today I spent time trying to figure out how to make the system work. The main problem is to automatize the network communication so that it exchanges messages without having to code it in the scene class. A major challenge is to create the objects in every connected client. The idea I have to solve this problem is to give the scene a virtual function to call when a new object is instantiated over the network. This way I can control what to do when the event occurs.

Then I created the networkObject component, which will be the component that identify an object through the network, Every NetworkObject is identified uniquely by three pieces of data: owner_ip, owner_port, local_id.

In the afternoon I made a substantial refactoring of the DeferredRenderer and Game classes. They used to iterate through the game object every frame to get the active lights, model and network_ids. Now I added a static field to each of this components to keep track of every object of that type. Performance are a bit better, and the code is much easier to maintain.

Day 177: UDP chat

Today I managed to implement completely the chat in UDP.
Each client now gets registered with the server when it first sends a message to it.
I made it simpler by removing some error checking (i.e. if a message is received partially, because I think that UDP should grant that a datagram is always received fully).
I had a few problems with the template functions because for some reasons they were not compiled along the code, but in the end I managed to get them working.
The server still used a select, but it is only interested in its socket, since UDP is connectionless. Not sure if this is a good implementation, but for now I'll leave it like that.
In the picture the top right client starts to send a couple of messages (which are structures containing data), and he is the only one receiving them. Then the second client does the same, and both receives the messages, and so on.

Day 176: Working on UDP

Today I started implementing the exchange of data with UDP.
Also I created templated functions to exchange automatically structures.
Right now nothing is working and there is a lot of work to do before getting to a stable point.

Day 175: Improvement in non-blocking IO

Today I refactored everything and improved the server to properly handle non-blocking calls.
Now both the red and write method can occur over multiple frames.
I'm not 100% sure that they behave correctly, because on the LAN I automatically avoid most worst scenario cases.
The chat application behave exactly like yesterday in normal conditions.
I'm not sure of all the choices I made, and I'll probably change this classes again in the future.

Day 174: Select and Chat

Today I've worked really a lot on the engine.
I started by implementing the non-blocking communication on the server by using select. It is still not perfect because I've not really took into account the error handling.
For the client I'm not sure how to proceed, because the only way to handle non-blocking functions seems to be the select as well, but for a single socket program it seems a disproportionate solution.
In the afternoon I spent a lot of time refactoring the window system, and now I can set the size in a easy way at the beginning of the execution.
I then created two other dummy projects in order to have a server and three clients on screen, and I managed to implement a simple chat application that allows communication between the clients.
In the picture, if the resolution will allow it, it is possible to see the messages sent and received by each client, as well as the multiple connections accepted by the server.

Day 173: Connection class

Today I had very little time and I just implemented a barebone connection class that will be used by the server to handle a connection with a client.

Day 172: Refactoring

Today I learned how to use the select function to execute non-blocking call. When I tried to implement that I realized that many things in my implementation were out of place and unusable. So I made a big refactoring of the socket class and created the client and server classes.
Tomorrow I'll start from here to implement multi-client connections

Day 171: Send and Receive

Today I implemented TCP communication between the server and client process.
Now they both have a send and a receive function. Right now you don't have access to any advanced feature of TCP to make things very simple and userfriendly. I'll add those when (and if) they'll be needed.
Upon reception of a message TCP doesn't know its size, and to solve the problem I adopted a very simple solution, which is probably not the most optimized, but I don't care because I'll use TCP only for slow and reliable connections. Tomorrow I'll probably implement UDP, and that's where I'll try to squeeze every extra bit of performance I can.

In the screenshot the client is sending to the server an "hello" message after the other, which is then read and printed on server side.