[Olpc-uruguay] Difícil la Red !!

Mar Ago 31 22:29:45 EDT 2010

Me presento. Mi nombre es Juan Carlos Escobar Samurio, soy estudiante del 3º
de Informática de la UTU. Este año nos enseñaron, aunque refiriendonos a
Visual Basic 6, de que cada caracter Unicode (los cuales en Visual basic se
declaran como string) ocupan un byte por caracter. Tengo la vaga idea de que
en ese caso puede que multiplicando la cantidad de caracteres por el tamaño
que ocupa un caracter en memoria podrían saber el espacio que ocupa en
memoria la cadena que escribas.

El 31 de agosto de 2010 22:54, Flavio Danesse <fdanesse en gmail.com> escribió:

> *Gracias a ambos.
>
> Pregunto:*
>
> ¿Alcanza con mandar una cadena de longitud fija en cada envío?
> ¿Cúanto ocupa un caracter? Los Unicode, ocupan desde 2 a 4 bytes? no? Cómo
> se cuanto ocupará mi cadena?
>
>
>
>
> El 31 de agosto de 2010 22:30, Fabian Peña <fapenia en adinet.com.uy>escribió:
>
>  Ta , dale bola a mi segundo mail nomás, que lo mire mejor y ( nunca hice
>> eso en python ) casi seguro
>> que es el recvfrom que te suelta cada 1000 bytes y todo va a los saltos.
>>
>> El otro tema dejalo para mas adelante  :-P
>>
>>
>>
>>
>> El 31/08/2010 10:19 p.m., Fabian Peña escribió:
>>
>> Otra que se me ocurre tambien , que por ahi vi un recvfrom ( 1000 )
>> Si no hay otro seteo por ahi que no vi , hasta que no tengas 1000 bytes el
>> recvfrom no te suelta.
>>
>> Si es asi tenes que tener alguna forma de normalizar el tamaño de lo que
>> lees , o sea si mandas coordenadas  formatealas
>> 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
>> sea el mio asi el recvfrom te suelta ni bien recibe 1 envio del cliente.
>> 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
>> enviar los datos tal cual lo haces hoy.
>> 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
>> juego como esta hoy ( nada de lo de las velocidades etc etc del mail
>> anterior ) te debe mejorar mucho el comportamiento.
>>
>>
>> El 31/08/2010 10:06 p.m., Fabian Peña escribió:
>>
>> Bue , una respuesta no muy trabajada.
>> 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.
>> 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.
>> 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.
>> 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 )
>> Esos cambios ( de concepto , que son los peores ) te permitirian mas
>> independencia del rendimiento de la red.
>>
>>
>> Salu 2
>>
>>
>>
>>
>>
>>
>> El 31/08/2010 09:07 p.m., Flavio Danesse escribió:
>>
>> Suave con las respuestas por favor que me están agobiando a correos.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> El 29 de agosto de 2010 19:38, Flavio Danesse <fdanesse en gmail.com>escribió:
>>
>>> Bueno, tengo el juego andando en la red aunque me he encontrado con cosas
>>> bastante complejas.
>>>
>>> Gracias al código de ejemplo que me mandó Andrés, adapté mi juego
>>> intentando seguir su modelo.
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>> Como verán, deshabilité todos los disparos para simplificar hasta
>>> resolver este tema. Para correr el juego deben ejecutar el archivo
>>> gtk_JAMtank_Ventana.py
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> *Es decir:*
>>>
>>>    1. ¿Un juego en red se puede hacer medianamente bién con estos
>>>    recursos?
>>>    2. ¿Está a mi alcance? o se necesita seber muuuucha cosa que yo no
>>>    se?
>>>    3. ¿Se puede hacer en python?
>>>
>>>
>>> *PD:*
>>> 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
>>> "cosas nuevas" 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> *PD 2:*
>>> 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.
>>> 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.
>>>
>>> *PD 3:*
>>> 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.
>>> 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.
>>> 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).
>>>
>>> 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.
>>>
>>
>> _______________________________________________
>> Olpc-uruguay mailing listOlpc-uruguay en lists.laptop.orghttp://lists.laptop.org/listinfo/olpc-uruguay
>>
>>
>> _______________________________________________
>> Olpc-uruguay mailing listOlpc-uruguay en lists.laptop.orghttp://lists.laptop.org/listinfo/olpc-uruguay
>>
>>
>> _______________________________________________
>> Olpc-uruguay mailing listOlpc-uruguay en lists.laptop.orghttp://lists.laptop.org/listinfo/olpc-uruguay
>>
>>
>>
>> _______________________________________________
>> Olpc-uruguay mailing list
>> Olpc-uruguay en lists.laptop.org
>> http://lists.laptop.org/listinfo/olpc-uruguay
>>
>>
>
> _______________________________________________
> Olpc-uruguay mailing list
> Olpc-uruguay en lists.laptop.org
> http://lists.laptop.org/listinfo/olpc-uruguay
>
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://lists.laptop.org/pipermail/olpc-uruguay/attachments/20100831/c62b7ca2/attachment-0001.htm 