I think you’re going to get much response from the SDL community until you
provide a small code example of what you’re doing. Also, some operating
systems smallest grandularity for milliseconds is 10ms, so your ops may be
Also, 10ms is extremely reasonable for a game, and your slow down is
probably waiting for a response over UDP.
From here, I’d really recommend trying to understand the type of
prioritization you want your game to use to get the performance you think
you should be getting.
Think of it this way:
What type of data needs to:
- be sent and forgotten the fastest
- have a round trip the fastest
- be received the fastest
- be sent and forgotten at any speed
- be sent on a tround trip at any speed
- be received at any speed
For games, this will be your main types of sent data. The general paradigm
here is called channels, and you can think of them like road lanes. While
driving, you can appreciate the fast and slow lane, but you won’t
appreciate trying to be fast in the slow lane, or slow in the fast lane.
SDL provides very low level network access where writing a network engine
around it to prioritize packets may not be efficient (it can be done, but
it’s really a separate project altogether). There are libraries that
handle this, or some work arounds. For libraries, enet may be an excellent
choice to light weight, fast and prioritized messages.
If you want to go the SDL route, there is the easy way or the hard way.
The easy way is to just use a secondary socket connection over TCP. TCP is
very slow in comparison to UDP, but can provide you with a stable for data
that you don’t care about the speed (like text chat in game,
initialization/deinitialization, etc.), and leaving UDP for things you want
to be done faster (like updating a player position, physics information,
etc.). This is like a poor man’s two channel system, but it works, and can
guarantee if a client is connected (where UDP may not be able to give this
Going the hard way means implementing what some would call and networking
kernel, which may or may not run in a separate thread, and when you push
data through it to the server, you would want to mark the channel you want
it to go through, or some sort of priority marker.
To be honest, the hard SDL way is really not necessary when there are other
libraries that do the same job that have been tried and tested, which gives
you one less thing to deal with.
I’m hoping that helps you out a bit,
-AlexOn Sun, Feb 22, 2015 at 10:50 AM, Meldryt wrote:
i read that the winsock functions such as recvfrom() and sendto() could
be a problem. When i look into the SDLNet_UDP_Send code, there is nothing
that could cause such a huge delay than the sendto() function.
SDL mailing list
SDL at lists.libsdl.org