I apologize in advance for being blunt, but if you are sending 1 pixel
per packet, and sending entire 800x600 pixel frames this way (one pixel
at a time), I am speechless. Seriously, do not do that, ever, never
ever, never ever ever. You should be sending the entire framebuffer in
one packet if you need to send each frame reliably, or if you can afford
lossiness, in unreliable 1KBish screen tiles even better. You should
also be not using up more than 3 bytes per pixel, and where possible
compressing that to less - though ENet's built-in PPM compression will
actually help there.
Lee
On 09/26/2010 04:30 PM, Nicholas J Ingrassellino wrote:
I am running a little experiment in C++ using ENet v1.3.0 with MSVC
2k8. What I am attempting to create is a pure dumb terminal-style
application where all video is done on a remote server and sent to the
client while the client only sends over key presses. Yes, yes, I know;
I am reinventing the wheel and half the people reading this do not
approve. It is just an experiment I am doing for kicks.
My issue lies in ENet's CPU usage. I had noticed that during the
receiving/drawing step my client CPU usage went to 100% and was
reacting way too slow to do what I want to do. After a while I have
narrowed the problem down to ENet. I even went as far as taking ENet
out of the picture to be sure it was not something else using
simulated data as if it were received from the server (IE virtually
not changing my client main loop). Just so I have gone on the record
as saying it the client, once ENet is removed from the picture, can
draw an image, pixel by pixel, 60 times a second without breaking a sweat.
My server is sending 7 bytes (payload, of course) for each pixel. At
800x600x24 I am aware this is a hell of a lot of data but it is still
eating a lot more CPU than I figured it would on the client. The
server gets all the data off in a timely fashion but the receiving
side can not get it nearly as fast as it was sent so it ends up
backing up really quickly. The client code looks like this:
while ( !main_loop_exit ) {
acquire_screen();
blit(buffer, screen, 0, 0, 0, 0, buffer->w, buffer->h);
release_screen();
if ( keypressed() ) {
unsigned char key_next = readkey() & 0xff;
ENetPacket *packet = enet_packet_create(&key_next,
sizeof(unsigned char), ENET_PACKET_FLAG_RELIABLE);
enet_peer_send(peer, 0, packet);
}
if ( enet_host_service(client, &event, 0) > 0 ) {
if ( event.type == ENET_EVENT_TYPE_RECEIVE ) {
_putpixel24(buffer, ((PACKET_PAYLOAD
*)event.packet->data)->x, ((PACKET_PAYLOAD
*)event.packet->data)->y, makecol(((PACKET_PAYLOAD
*)event.packet->data)->r, ((PACKET_PAYLOAD
*)event.packet->data)->g, ((PACKET_PAYLOAD
*)event.packet->data)->b));
enet_packet_destroy(event.packet);
}
else if ( event.type == ENET_EVENT_TYPE_DISCONNECT )
main_loop_exit = true;
}
else
rest(1);
}
Any input on how I can speed up ENet's processing of packets would be
greatly appreciated. I think ENet is a perfect fit for this project on
paper if I can just figure out how to make it sing.
------------------------------------------------------------------------
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
_
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
