<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Blunt is good.<br>
<br>
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.<br>
<br>
<b>This is purely a exercise of the mind with a little code to back it
up.</b><br>
<br>
Compression and related topics will come later when I have the basics
figured out.<br>
<div class="moz-signature"><br>
<hr style="height: 1px;">
<p><span style="font-weight: bold;">Nicholas J Ingrassellino<br>
<a style="text-decoration: none;"
 href="http://www.lifebloodnetworks.com/" target="_blank">LifebloodNetworks.com</a></span>
|| <a style="text-decoration: none;"
 href="mailto:nick@lifebloodnetworks.com">nick@lifebloodnetworks.com</a></p>
<p style="font-size: 75%;">"<span style="font-style: italic;">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.</span>"<br>
- <span style="font-weight: bold;">John Carmack</span> on software
patents</p>
</div>
<br>
On 09/26/2010 08:41 PM, Lee Salzman wrote:
<blockquote cite="mid:4C9FE838.3050400@cox.net" type="cite">
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
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.<br>
  <br>
Lee &nbsp; <br>
  <br>
On 09/26/2010 04:30 PM, Nicholas J Ingrassellino wrote:
  <blockquote cite="mid:4C9FD793.8050302@lifebloodnetworks.com"
 type="cite">
    <meta http-equiv="content-type"
 content="text/html; charset=ISO-8859-1">
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.<br>
    <br>
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.<br>
    <br>
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:<br>
    <blockquote>while ( !main_loop_exit ) { <br>
&nbsp;&nbsp;&nbsp; acquire_screen(); <br>
&nbsp;&nbsp;&nbsp; blit(buffer, screen, 0, 0, 0, 0, buffer-&gt;w, buffer-&gt;h); <br>
&nbsp;&nbsp;&nbsp; release_screen(); <br>
      <br>
&nbsp;&nbsp;&nbsp; if ( keypressed() ) { <br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; unsigned char key_next = readkey() &amp; 0xff; <br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; ENetPacket *packet = enet_packet_create(&amp;key_next,
sizeof(unsigned char), ENET_PACKET_FLAG_RELIABLE); <br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; enet_peer_send(peer, 0, packet); <br>
&nbsp;&nbsp;&nbsp; } <br>
&nbsp;<br>
&nbsp;&nbsp;&nbsp; if ( enet_host_service(client, &amp;event, 0) &gt; 0 ) { <br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; if ( event.type == ENET_EVENT_TYPE_RECEIVE ) { <br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; _putpixel24(buffer, ((PACKET_PAYLOAD
*)event.packet-&gt;data)-&gt;x, ((PACKET_PAYLOAD
*)event.packet-&gt;data)-&gt;y, makecol(((PACKET_PAYLOAD
*)event.packet-&gt;data)-&gt;r, ((PACKET_PAYLOAD
*)event.packet-&gt;data)-&gt;g, ((PACKET_PAYLOAD
*)event.packet-&gt;data)-&gt;b)); <br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; enet_packet_destroy(event.packet); <br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; } <br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; else if ( event.type == ENET_EVENT_TYPE_DISCONNECT ) <br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; main_loop_exit = true; <br>
&nbsp;&nbsp;&nbsp; } <br>
&nbsp;&nbsp;&nbsp; else <br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; rest(1); <br>
}<br>
    </blockquote>
    <br>
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.<br>
    <div class="moz-signature"><br>
    <hr style="height: 1px;">
    <p><span style="font-weight: bold;">Nicholas J Ingrassellino<br>
    <a moz-do-not-send="true" style="text-decoration: none;"
 href="http://www.lifebloodnetworks.com/" target="_blank">LifebloodNetworks.com</a></span>
|| <a moz-do-not-send="true" style="text-decoration: none;"
 href="mailto:nick@lifebloodnetworks.com">nick@lifebloodnetworks.com</a></p>
    <p style="font-size: 75%;">"<span style="font-style: italic;">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.</span>"<br>
- <span style="font-weight: bold;">John Carmack</span> on software
patents</p>
    </div>
    <pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
_
  </pre>
  </blockquote>
  <br>
  <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
ENet-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ENet-discuss@cubik.org">ENet-discuss@cubik.org</a>
<a class="moz-txt-link-freetext" href="http://lists.cubik.org/mailman/listinfo/enet-discuss">http://lists.cubik.org/mailman/listinfo/enet-discuss</a>
  </pre>
</blockquote>
</body>
</html>