<b>Gracias a ambos.<br><br>Pregunto:</b><br><br>¿Alcanza con mandar una cadena de longitud fija en cada envío?<br>¿Cúanto ocupa un caracter? Los Unicode, ocupan desde 2 a 4 bytes? no? Cómo se cuanto ocupará mi cadena?<br><br>
<br><br><br><div class="gmail_quote">El 31 de agosto de 2010 22:30, Fabian Peña <span dir="ltr">&lt;<a href="mailto:fapenia@adinet.com.uy">fapenia@adinet.com.uy</a>&gt;</span> escribió:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


  
    
  
  <div bgcolor="#ffffff" text="#000000">
    Ta , dale bola a mi segundo mail nomá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 <span><span>
        :-P </span></span><br>
    <br>
    <br>
     <br>
    <br>
    El 31/08/2010 10:19 p.m., Fabian Peña escribió:
    <div><div></div><div class="h5"><blockquote type="cite">
      
      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ño de
      lo que lees , o sea si mandas coordenadas  formatealas<br>
      para que siempre sean 3 o 4 digitos tipo para x = 5 , y =
      1024       envia 0005,1024 cosa que el tamañ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ño
      del paquete ( siempre un numero fijo  de bytes ) 09 o 26 etc , y 
      luego si<br>
      enviar los datos tal cual lo haces hoy.<br>
      Al recibir haces un revcfrom(2) obtenes el tamaño y luego si
      recvfrom(tamañ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ña escribió:
      <blockquote type="cite">
        
        
        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ó:
        <blockquote type="cite">Suave con las respuestas por favor que me está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 href="mailto:fdanesse@gmail.com" target="_blank">fdanesse@gmail.com</a>&gt;</span>
            escribió:<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ódigo de ejemplo que me mandó Andrés, adapté
              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ódigo es que demora mucho la
              actualización de los datos en los clientes y que los
              tanques de las máquinas remotas, se ven a los saltos en
              los clientes locales, así que no tiene nada que ver lo que
              pasa en el servidor con lo que pasa en los clientes y
              ademá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ó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án, deshabilité 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é es que los clientes deben
              escribir obligatoriamente en el socket en cada pasada del
              bucle de pygame, de lo contrario, cuando el tanque está
              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ás se enlentece.<br>
              <br>
              Seguramente estoy haciendo algo mal o me falta algo, me
              gustaría que quienes sepan de redes, aunque no miren el
              có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ón.<br>
              <br>
              <b>Es decir:</b><br>
              <ol>
                <li>¿Un juego en red se puede hacer medianamente bién
                  con estos recursos?</li>
                <li>¿Está a mi alcance? o se necesita seber muuuucha
                  cosa que yo no se?</li>
                <li>¿Se puede hacer en python?</li>
              </ol>
              <br>
              <b>PD:</b><br>
              Cómo veo que en la lista se plantea una discusión sobre
              los tipos de juegos y además se que aveces suena mal un
              nombre como CeibalWar (mi primer experiencia con pygame),
              supongo que habrá 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 &quot;cosas nuevas&quot; sobre python. No
              necesariamente son objetivo de desarrollo, de hecho
              CeibalWar nunca lo terminé, pero me permitió hacer algo
              que funcionara con pygame. En el caso de JAMtank, he
              aprendido mucho más sobre pygame, mirando código de
              gabriel, con ayudas e ideas de pablo en la captura de
              eventos y actualización de imágenes en pantalla y un
              aporte gigante de andrés en lo referente a la red que
              hasta ahora había sido una zona muy oscura de python para
              mi. También aprendí mucho sobre hilos en python.<br>
              <br>
              Gracias a todo esto, recién ahora me animaría a hacer un
              juego o actividad educativa sobre pygame y terminarlo,
              incluso, que permita la conexión en red, aunque un juego
              del tipo de JAMtank todavía no podrí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ía bien con lo poco que se sobre la red al día de
              hoy.<br>
              <br>
              Además de esta aclaración, aveces los nombres de los
              juegos pueden inducir a confusiones, nadie que haya jugado
              al War (pienso yo), lo catalogaría como un juego violento,
              incluso JAMtank, difícilmente entraría en esta categoría
              segú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é una guia de uso de las
              clases utilizadas en este juego, donde muestre como hacer
              para integrar la transmisió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áctico que
              funcione en la xo.<br>
              Explicar esto probablemente sea más difícil que hacerlo
              andar, pero creo que será el mejor aporte que puedo hacer
              a quienes están aprendiendo.<br>
              <br>
              <b>PD 3:</b><br>
              Un problema en pygame es la integración con gtk, de hecho
              en el sitio de pygame se dice claramente que no es buena
              idea.<br>
              Es una lástima porque de poder utilizar gtk se resulven
              muchos problemas y se ahorra tiempo ya que se pueden
              utilizar los botones, menú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é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ás de tener
              que utilizar el adaptador pygame-sugar habría que
              construir un wrapper para telephaty (un segundo
              adaptador).<br>
              <br>
              Todo esto además, tiene el inconveniente de que, (de poder
              hacerlo), solo funcionará sobre sugar, así que lo mejor es
              usar pygame separado de gtk y la red sin tomar en cuenta
              las clases de sugar. Además, considerando que en ciclo
              básico, (según tengo entendido), las máquinas vienen con
              sugar y gnome, me inclino a pensar que sugar prácticamente
              no se va a utilizar (en principio en ciclo básico), me
              parece que lo mejor es que las actividades que se
              construyan funcionen en gnome ya que en sugar se podrán
              ejecutar o adaptar si es necesario, pero si se desarrolla
              específicamente para sugar, despúes se puede complicar má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><fieldset></fieldset>
_______________________________________________
Olpc-uruguay mailing list
<a href="mailto:Olpc-uruguay@lists.laptop.org" target="_blank">Olpc-uruguay@lists.laptop.org</a>
<a href="http://lists.laptop.org/listinfo/olpc-uruguay" target="_blank">http://lists.laptop.org/listinfo/olpc-uruguay</a>
</pre>
        </blockquote>
        <br>
        <pre><fieldset></fieldset>
_______________________________________________
Olpc-uruguay mailing list
<a href="mailto:Olpc-uruguay@lists.laptop.org" target="_blank">Olpc-uruguay@lists.laptop.org</a>
<a href="http://lists.laptop.org/listinfo/olpc-uruguay" target="_blank">http://lists.laptop.org/listinfo/olpc-uruguay</a>
</pre>
      </blockquote>
      <br>
      <pre><fieldset></fieldset>
_______________________________________________
Olpc-uruguay mailing list
<a href="mailto:Olpc-uruguay@lists.laptop.org" target="_blank">Olpc-uruguay@lists.laptop.org</a>
<a href="http://lists.laptop.org/listinfo/olpc-uruguay" target="_blank">http://lists.laptop.org/listinfo/olpc-uruguay</a>
</pre>
    </blockquote>
    <br>
  </div></div></div>

<br>_______________________________________________<br>
Olpc-uruguay mailing list<br>
<a href="mailto:Olpc-uruguay@lists.laptop.org">Olpc-uruguay@lists.laptop.org</a><br>
<a href="http://lists.laptop.org/listinfo/olpc-uruguay" target="_blank">http://lists.laptop.org/listinfo/olpc-uruguay</a><br>
<br></blockquote></div><br>