Only one thread can draw to an ALLEGRO_DISPLAY. Typically you'd just send data to that thread using whatever method you want (sockets, messages, ALLEGRO_EVENTs) and have it draw whatever you need.

In your case, it's a little weird as split screen usually implies a single game process with multiple controllers without any networking. If you want multiple game processes on separate computers communicating via sockets then you typically don't need to use a split screen, although you still could. Either way in that case you'd still have a single thread doing all the drawing (and the game logic), and the only place where multi-processing would come up is exchanging the game state between the game clients and the server.

There's an example in Allegro (ex_enet_client and ex_enet_server) that illustrate how to write a networked game that you could use as an inspiration.

Maybe what's meant is split-screen where the other half is the "remote" site -- i.e. Tetris clone where you control one side but you still see what the other player is doing. In that case you would not be sharing displays at all.

How complicated it gets depends only on the requirements for the project. I can imagine a way to do it that needs no server and trivial network code. If both clients don't interact, then latency and conflicts are not a concern, basically you are playing a local Tetris on one side and the other side is a remote view updated by the sockets. In this case you are just simply observing the other character and the "server" in "server/client" is not needed. I can imagine that would be quite sufficient for learning about sockets.

If you have a low-latency, high-bandwidth connection (actually it would be infinite bandwidth, zero latency if you were truly fork()ing), then you could just send the whole game state on each tick over the socket, and the remote side would be nothing but a renderer of that game state. The renderer would be the same for local and remote sides, the only difference is you wouldn't call update from a timer on the remote state. You'd need to add a way to transmit deltas of state if bandwidth is low, and a way to predict future user input if latency jitty is high (if jitter is low, no worries -- just the games won't be in sync, which is OK if you are not interacting with each other).

In this scenario, you'd fork before you set up Allegro. Then each game would set up Allegro with one display, with the renderer drawing just half of the screen.

Thanks to all for the help!

Like gillius said, my idea was to make that the display show my tetris in the left-half of the screen and in the right-half appear the opponent's tetris. Something like a battle tetris for two players. What I made at the beginning was to fork, one process do all the game logic and print the graphics and the other process sends my tetris state and receive the opponent's tetris state, all with sockets. Both processes communicate with simple pipes (i need to use it too). But I dont know how can I print the opponent state in the "game logic" process every time it changes. The ony way I thought was to call the function that prints in every part of the code to refresh the oponent's state in the screen, but probably it isn't the best way.

Thanks again and be patients with me, I'm newbie.