Sorry, I should have explained the non-ENet functions. rest(1) is one
millisecond (of course on Windows it is really five milliseconds).
blit() is for drawing the screen (in this case the pixel data I have
received so far). I think the rest are pretty self explanatory.
As I said, I got it working great when I removed ENet (and only ENet/did
not change anything else).
------------------------------------------------------------------------
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 07:44 PM, Jay Sprenkle wrote:
I assume "rest(1)" is a sleep function? for one second?
If so you're only checking for a key press packet once per second (and
only processing one packet, even if more are waiting).
On Sun, Sep 26, 2010 at 6:30 PM, Nicholas J Ingrassellino
<[email protected] <mailto:[email protected]>> 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);
}
_______________________________________________
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
