<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    Ta , dale bola a mi segundo mail nom&aacute;s, que lo mire mejor y ( nunca
    hice eso en python ) casi seguro <br>
    que es el recvfrom que te suelta cada 1000 bytes y todo va a los
    saltos.<br>
    <br>
    El otro tema dejalo para mas adelante&nbsp;<span class="moz-smiley-s4"><span>
        :-P </span></span><br>
    <br>
    <br>
    &nbsp;<br>
    <br>
    El 31/08/2010 10:19 p.m., Fabian Pe&ntilde;a escribi&oacute;:
    <blockquote cite="mid:4C7DAA10.6040507@adinet.com.uy" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      Otra que se me ocurre tambien , que por ahi vi un recvfrom ( 1000
      ) <br>
      Si no hay otro seteo por ahi que no vi , hasta que no tengas 1000
      bytes el recvfrom no te suelta.<br>
      <br>
      Si es asi tenes que tener alguna forma de normalizar el tama&ntilde;o de
      lo que lees , o sea si mandas coordenadas&nbsp; formatealas<br>
      para que siempre sean 3 o 4 digitos tipo para x = 5 , y =
      1024&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; envia 0005,1024 cosa que el tama&ntilde;o del envio para todos
      los mensajes<br>
      sea el mio asi el recvfrom te suelta ni bien recibe 1 envio del
      cliente.<br>
      Podrias tambien antes de enviar los datos enviar primero el tama&ntilde;o
      del paquete ( siempre un numero fijo&nbsp; de bytes ) 09 o 26 etc , y&nbsp;
      luego si<br>
      enviar los datos tal cual lo haces hoy.<br>
      Al recibir haces un revcfrom(2) obtenes el tama&ntilde;o y luego si
      recvfrom(tama&ntilde;o) para que nunca te tranque.Eso en una red local
      sin cambiar mucho el <br>
      juego como esta hoy ( nada de lo de las velocidades etc etc del
      mail anterior ) te debe mejorar mucho el comportamiento.<br>
      <br>
      <br>
      El 31/08/2010 10:06 p.m., Fabian Pe&ntilde;a escribi&oacute;:
      <blockquote cite="mid:4C7DA71A.8090307@adinet.com.uy" type="cite">
        <meta content="text/html; charset=ISO-8859-1"
          http-equiv="Content-Type">
        <title></title>
        Bue , una respuesta no muy trabajada. <br>
        Segun veo mandas a los clientes la posicion x,y de cada tanque a
        medida que estos se van moviendo.Eso te obliga a tener una
        velocidad de comunicaciones tal que te permita un movimiento
        fluido.<br>
        Yo creo que cada cliente debiera poder mover un tanque o bala
        por si solo dado un angulo y velocidad y recibir datos solo
        cuando alguno cambie de direccion.<br>
        En si toda la mecanica del juego , movimientos de tanques, balas
        , deteccion de explosiones suma de puntajes bla bla bla queda
        del lado del cliente y la mision del servidor es avisar cuando
        un nuevo tanque entra y su posicion inicial y avisar un cambio
        de angulo o detencion.<br>
        Fijate si cambia las cosas que en el servidor no tenes porque
        saber que una bala le dio a un tanque ya que no hay porque
        informarselo a nadie ( ya todos lo saben )<br>
        Esos cambios ( de concepto , que son los peores ) te permitirian
        mas independencia del rendimiento de la red.<br>
        <br>
        <br>
        Salu 2<br>
        <br>
        <br>
        <br>
        <br>
        <br>
        <br>
        El 31/08/2010 09:07 p.m., Flavio Danesse escribi&oacute;:
        <blockquote
          cite="mid:AANLkTi=2ZiLqV_CLrL_5F8CR1JTVqixx-nJ3LMc_x14Z@mail.gmail.com"
          type="cite">Suave con las respuestas por favor que me est&aacute;n
          agobiando a correos.<br>
          <br>
          <br>
          <br>
          <br>
          <br>
          <br>
          <br>
          <br>
          <br>
          <div class="gmail_quote">El 29 de agosto de 2010 19:38, Flavio
            Danesse <span dir="ltr">&lt;<a moz-do-not-send="true"
                href="mailto:fdanesse@gmail.com">fdanesse@gmail.com</a>&gt;</span>
            escribi&oacute;:<br>
            <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
              0.8ex; border-left: 1px solid rgb(204, 204, 204);
              padding-left: 1ex;">Bueno, tengo el juego andando en la
              red aunque me he encontrado con cosas bastante complejas.<br>
              <br>
              Gracias al c&oacute;digo de ejemplo que me mand&oacute; Andr&eacute;s, adapt&eacute;
              mi juego intentando seguir su modelo.<br>
              Sin este ejemplo no hubiera encontrado la manera de
              hacerlo, de modo que mi agradecimiento por tomarse un rato
              para construirlo y por aguantarme sobre todo.<br>
              <br>
              El problema que tengo en el c&oacute;digo es que demora mucho la
              actualizaci&oacute;n de los datos en los clientes y que los
              tanques de las m&aacute;quinas remotas, se ven a los saltos en
              los clientes locales, as&iacute; que no tiene nada que ver lo que
              pasa en el servidor con lo que pasa en los clientes y
              adem&aacute;s en todos los clientes las cosas son distintas. Se
              supone que debe pasar lo mismo en todos lados, de lo
              contrario es mejor jugar solo.<br>
              <br>
              Paso zipeado el c&oacute;digo que tengo hasta ahora, a ver si
              alguien tiene ganas y tiempo de mirarlo y encuentra alguna
              cosa que puada servirme de guia.<br>
              Como ver&aacute;n, deshabilit&eacute; todos los disparos para
              simplificar hasta resolver este tema. Para correr el juego
              deben ejecutar el archivo <span style="color: rgb(0, 0,
                153);">gtk_JAMtank_Ventana.py</span><br>
              <br>
              Una de las cosas que encontr&eacute; es que los clientes deben
              escribir obligatoriamente en el socket en cada pasada del
              bucle de pygame, de lo contrario, cuando el tanque est&aacute;
              quieto, todo se le enlentece (las balas por ejemplo), esto
              no debiera ser bueno porque estoy ocupando al servidor sin
              necesidad ya que si no hay cambios en el cliente, no tiene
              sentido actualizar sus datos en el servidor.<br>
              <br>
              De modo que, en el cliente, mientras el tanque local se
              mueva, todo anda bien, (menos los tanques remotos que
              saltan y se atrasan), si el tanque local se queda quieto,
              todo lo dem&aacute;s se enlentece.<br>
              <br>
              Seguramente estoy haciendo algo mal o me falta algo, me
              gustar&iacute;a que quienes sepan de redes, aunque no miren el
              c&oacute;digo, me expliquen si lo que trato de hacer es posible a
              este nivel, porque en una de esas estoy perdiendo el
              tiempo al santo bot&oacute;n.<br>
              <br>
              <b>Es decir:</b><br>
              <ol>
                <li>&iquest;Un juego en red se puede hacer medianamente bi&eacute;n
                  con estos recursos?</li>
                <li>&iquest;Est&aacute; a mi alcance? o se necesita seber muuuucha
                  cosa que yo no se?</li>
                <li>&iquest;Se puede hacer en python?</li>
              </ol>
              <br>
              <b>PD:</b><br>
              C&oacute;mo veo que en la lista se plantea una discusi&oacute;n sobre
              los tipos de juegos y adem&aacute;s se que aveces suena mal un
              nombre como CeibalWar (mi primer experiencia con pygame),
              supongo que habr&aacute; gente en la lista a la que le rechine el
              nombre de JAMtank de este juego, por eso quiero aclarar
              que este jueguito, al igual que CeibalWar son simplemente
              un pretexto para aprender "cosas nuevas" sobre python. No
              necesariamente son objetivo de desarrollo, de hecho
              CeibalWar nunca lo termin&eacute;, pero me permiti&oacute; hacer algo
              que funcionara con pygame. En el caso de JAMtank, he
              aprendido mucho m&aacute;s sobre pygame, mirando c&oacute;digo de
              gabriel, con ayudas e ideas de pablo en la captura de
              eventos y actualizaci&oacute;n de im&aacute;genes en pantalla y un
              aporte gigante de andr&eacute;s en lo referente a la red que
              hasta ahora hab&iacute;a sido una zona muy oscura de python para
              mi. Tambi&eacute;n aprend&iacute; mucho sobre hilos en python.<br>
              <br>
              Gracias a todo esto, reci&eacute;n ahora me animar&iacute;a a hacer un
              juego o actividad educativa sobre pygame y terminarlo,
              incluso, que permita la conexi&oacute;n en red, aunque un juego
              del tipo de JAMtank todav&iacute;a no podr&iacute;a por obvias razones
              (origen de este mail), sin embargo una actividad en red
              por turnos (tipo juego de cartas o de mesa), pienso que
              funcionar&iacute;a bien con lo poco que se sobre la red al d&iacute;a de
              hoy.<br>
              <br>
              Adem&aacute;s de esta aclaraci&oacute;n, aveces los nombres de los
              juegos pueden inducir a confusiones, nadie que haya jugado
              al War (pienso yo), lo catalogar&iacute;a como un juego violento,
              incluso JAMtank, dif&iacute;cilmente entrar&iacute;a en esta categor&iacute;a
              seg&uacute;n creo. Pero bueno, simplemente me interesaba aclarar
              que estos jueguitos son mis pretextos para aprender y no
              proyectos de desarrollos en si mismos.<br>
              <br>
              <b>PD 2:</b><br>
              En cuanto tenga un lugarcito, har&eacute; una guia de uso de las
              clases utilizadas en este juego, donde muestre como hacer
              para integrar la transmisi&oacute;n de datos por la red con un
              juego o actividad desarrollada en pygame, de forma que al
              menos quienes deseen aprender sobre el tema tengan un
              punto de partida con ejemplo sencillo y pr&aacute;ctico que
              funcione en la xo.<br>
              Explicar esto probablemente sea m&aacute;s dif&iacute;cil que hacerlo
              andar, pero creo que ser&aacute; el mejor aporte que puedo hacer
              a quienes est&aacute;n aprendiendo.<br>
              <br>
              <b>PD 3:</b><br>
              Un problema en pygame es la integraci&oacute;n con gtk, de hecho
              en el sitio de pygame se dice claramente que no es buena
              idea.<br>
              Es una l&aacute;stima porque de poder utilizar gtk se resulven
              muchos problemas y se ahorra tiempo ya que se pueden
              utilizar los botones, men&uacute;s, etc.<br>
              El adaptador pygame_sugar hace esto esto, utiliza como
              canvas de la ventana de la actividad al juego hecho en
              pygame, traduciendo la captura de eventos entre gtk y
              pygame a trav&eacute;s de un socket. Ahora, si se intentara hacer
              un juego o actividad compartida o multiplayer en red con
              pygame, la cosa se complica mucho porque adem&aacute;s de tener
              que utilizar el adaptador pygame-sugar habr&iacute;a que
              construir un wrapper para telephaty (un segundo
              adaptador).<br>
              <br>
              Todo esto adem&aacute;s, tiene el inconveniente de que, (de poder
              hacerlo), solo funcionar&aacute; sobre sugar, as&iacute; que lo mejor es
              usar pygame separado de gtk y la red sin tomar en cuenta
              las clases de sugar. Adem&aacute;s, considerando que en ciclo
              b&aacute;sico, (seg&uacute;n tengo entendido), las m&aacute;quinas vienen con
              sugar y gnome, me inclino a pensar que sugar pr&aacute;cticamente
              no se va a utilizar (en principio en ciclo b&aacute;sico), me
              parece que lo mejor es que las actividades que se
              construyan funcionen en gnome ya que en sugar se podr&aacute;n
              ejecutar o adaptar si es necesario, pero si se desarrolla
              espec&iacute;ficamente para sugar, desp&uacute;es se puede complicar m&aacute;s
              para que funcionen en gnome, ya que en gnome hay que
              utilizar gtk directamente por ejemplo, mientras que en
              sugar se puede utilizar clases de sugar que en realidad
              reimplementan clases u objetos de gtk.<br>
            </blockquote>
          </div>
          <br>
          <pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Olpc-uruguay mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Olpc-uruguay@lists.laptop.org">Olpc-uruguay@lists.laptop.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.laptop.org/listinfo/olpc-uruguay">http://lists.laptop.org/listinfo/olpc-uruguay</a>
</pre>
        </blockquote>
        <br>
        <pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Olpc-uruguay mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Olpc-uruguay@lists.laptop.org">Olpc-uruguay@lists.laptop.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.laptop.org/listinfo/olpc-uruguay">http://lists.laptop.org/listinfo/olpc-uruguay</a>
</pre>
      </blockquote>
      <br>
      <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Olpc-uruguay mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Olpc-uruguay@lists.laptop.org">Olpc-uruguay@lists.laptop.org</a>
<a class="moz-txt-link-freetext" href="http://lists.laptop.org/listinfo/olpc-uruguay">http://lists.laptop.org/listinfo/olpc-uruguay</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>