Wow, programming sucks. I am going to forget this crazy non-sense and
follow my childhood dream: I am going to be a professional dinosaur.
------------------------------------------------------------------------
Nicholas J Ingrassellino
LifebloodNetworks.com <http://www.lifebloodnetworks.com/> ||
[email protected] <mailto:[email protected]>
"The idea that I can be presented with a problem, set out to logically
solve it with the tools at hand, and wind up with a program that could
not be legally used because someone else followed the same logical steps
some years ago and filed for a patent on it is horrifying."
- John Carmack on software patents
On 09/27/2010 04:53 PM, Jay Sprenkle wrote:
The overhead goes up as the packet size goes down. Check out this
write up for the gory details in an entertaining story:
http://www.tamos.net/~rhay/overhead/ip-packet-overhead.htm
<http://www.tamos.net/%7Erhay/overhead/ip-packet-overhead.htm>
On Mon, Sep 27, 2010 at 3:33 PM, Nicholas J Ingrassellino
<[email protected] <mailto:[email protected]>> wrote:
This just inspired me to do another test.
I am now only sending 1 out of every ~10,000 pixels. It still
takes about half of one second to receive ~50 pixels (7 byte
packets per pixel). All the CPU usage is on the client, not the
server. I am very familiar with this graphics library (Allegro)
having used it many times before. If I receive, discard the
packets, and do not render the pixels my CPU usage remains at
~100% leading me to believe it is /enet_host_service()/ and not
something having to do with rendering data onto the screen.
Is ~350 bytes split into ~50 unreliable, unsequenced packets still
too much?
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
