Ok, lets first do a little math. I’m going to assume a screen size of
1024x768, you might be using a larger or smaller size. I’m going to
assume a frame rate of 30 frames per second, most games run at above
60 FPS. I’m going to assume 32 bits per pixel. That comes out to:
102476832*30 = 754,974,720 bits per second per player. That’s 755
megabits/second
OK, lets try some more reasonable assumptions. A 640x480 image with 16
bit graphics at 30 FPS gives:
64048016*30=147,456,000 bits per second per player which means on a
gigabit lan you can maybe handle 4 to 6 players.
The numbers look pretty bad. You can improve them by compressing the
images using something like jpeg. Or, better yet you can compute the
difference between the current image and the last image and compress
and send only the difference. That is likely to get you to a
reasonable bit rate. You will still have problems any time a large
part of the image changes all at once.
Next problem: Your code assumes the image is in the the SDL_image
structure. It is not. It is pointed to by that structure. The pixel
data is stored in a separate array. You will need to look inside the
SDL_image structure to find the pixels.
It is always a good idea to do the math to get a feel for the real
numbers that control your project. Some people call it a
back-of-the-envelope computation, some call it a ROM (rough order of
magnitude) computation. It is always a good idea to do one.
Everybody goes though the experience of learning to do the math before
doing a project. This particular problem, doing everything on the
server and streaming the game to customers is very familiar to me
because once, long ago, while working for what is now AT&T (i.e. SBC)
I had to write a long formal research document explaining the problem
to a corporate VP who thought he had just come up with a way to make
billions of dollars 
by doing exactly what you are trying to do. At
the time, with the resources of a multi-billion dollar company, I came
the conclusion that it was just almost possible except for the problem
of latency.
I sill do not believe that this is a good way to do things, but it may
just be possible with current technology.
Bob PendletonOn Thu, Jun 25, 2009 at 7:16 PM, Lillefix wrote:
Hi, I am trying to make a networked multiplayer game in which the clients
sends the user-input to the server and the server actually does all the
calculations. I do also want the server to do all of the rendering axcept
for the last part of course. Therefore I make a SDL_Surface * which I blit
every player onto, in addition to the map. My problem is, however, how I a
supposed to transfer this surface.
This is my current send-code (from the server to the client)
memcpy(p->data, tempSurface, sizeof(SDL_Surface)); //Copy the surface to the
UDP-packet
p->len = sizeof(SDL_Surface); //Set the length of the data transferred
p->address = connections[i].address; //Set destination-address
SDLNet_UDP_Send(sd, -1, p); //Send it
and this is the recieving code (the client)
memcpy(clientScreen, p->data, sizeof(SDL_Surface));
I do however not believe that this is the correct way of doing it, as the
SDL_Surface struct contains a lot of pointers which will not be correct when
transferred etc.
So, is there any way to do this, or will I have to do something entirely
different?
View this message in context: Sending SDL_Surface via UDP
Sent from the SDL mailing list archive at Nabble.com.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
±----------------------------------------------------------