Blunt is good.
My disclaimer in my first message was meant to pose this as an
experiment. This is a proof of concept kind of thing and nothing more.
The idea is to develop an alternative to sending hold frames (or only
the deltas). Much like VoIP does not suffer from some missing data I
want to do a little work on how much an image would suffer from the
smallest discrete unit (a pixel) missing unexpectedly. Look at my
experiment as anything other than academic-- or a what if-- and you miss
the point.
*This is purely a exercise of the mind with a little code to back it up.*
Compression and related topics will come later when I have the basics
figured out.
------------------------------------------------------------------------
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/26/2010 08:41 PM, Lee Salzman wrote:
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
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
