Pequeñas maravillas de ssh; redirigir las Xs a ssh.

Esto es una pijadilla, pero bueno.

Con ssh podemos establecer conexiones cifradas entre dos ordenadores diferentes, para ello hacemos (por consola, si, lo siento, habra  algun interfaz, seguro, pero no lo conozco):

ssh (usuarioconelquetequieresloggear)@(direccionipdelamaquinaremota) -p (puertodelamaquinaremota)

El parametro -p es opcional (si no lo cambias especificamente el puerto de destino es el 22, de modo que el ordenador siempre busca el 22 por defecto).

Como ejemplo quedaria el comando, para mi ordenador al que le he puesto el ssh en el puerto 7777:

iñigo@deep-blue:~$ ssh iñigo@192.168.1.144 -p 7777

Esto nos abre una consola del ordenador remoto en el propio.

A partir de esto se pueden hacer cosas que tienen gran utilidad como tuneles y tuneles inversos, pero para eso remito a delicious, en mi pagina (http://delicious.com/inigod) tengo, en el tag ssh un par de paginas muy descriptivas.

Otra cosa increiblemente util y que acabo de 'redescubrir' -sabia que se podia hacer pero no sabia que era tan sumamente facil- es redirigir las X-s

Q son las X-s? Son las ventanas que dibuja nuestro linux, a diferencia de en windows, el programa que dibuja las ventanas esta pensado como un servidor, con ello lo que se consigue es que las ventanas que se obtienen al ejecutar un comando puedan ser redirigidas a diversas pantallas, escritorios....

Pues bien, tambien se pueden redirigir al ssh simplemente añadiendo el parametro -X

iñigo@deep-blue:~$ ssh -X iñigo@192.168.1.144 -p 7777

De este modo podremos ejecutar programas en el ordenador remoto y apareceran las ventanas en el nuestro con solo ejecutarlos desde la consola resultante de ssh!!!

Esto es, por ejemplo:

iñigo@deep-blue-remoto:~$gimp

Nos abrira una ventana en nuestro ordenador con un gimp ejecutandose en el remoto....

Esto es bastante util para hacer asistencias remotas a alguien (yo, por ejemplo no se hacer todo por consola y reconozco que para la mayoria de cosas apenas es necesario, asi que lo probare con mi hermano y con amaiita) y para instalar cosas que requieren instalacion por ventanas (como weblogic 10 u oracle 10,  uno de los dos se instalo parecido cuando yo trabajaba en osakidetza, pero lo hicieron mas enrevesado...)

En fin, parece util.

Saliendo del caos

He andado liado con medicos y tal...

Pero bueno, algo hemos avanzado. He hecho que el programa que escribe el archivo con las coordenadas de los frames de las naves saque sus resultados por pantalla ademas de a archivo, se debera ejecutar para todas las imagenes, ya que crea un *.shp en /info con la informacion que obtiene de el archivo de imagenes...

En el protocolo que utilizo para pintar se han añadido la x y la y, asi como la anchura y altura -todas estas coordenadas dentro de la superficie de frames- que definiran a el frame que ha de dibujarse.... de modo que queda algo asi:

[imageindex, x, y, rect.x, rect.y, rect.w, rect.h, angle]

Tambien en algun momento tendre que unir varias naves en el mismo archivo, por aquello de no tener un monton de archivos abiertos, en memoria, a la vez. Esto puede hacerse añadiendo un parametro mas a el array que contiene la informacion de los sprites... y por ahora me parece una buena solucion...

Pero bueno, lo proximo es hacer *.shp para todos.

Lo siguiente, espero que sea introducir el tema de las explosiones por fin (asi me lo quito) que no tiene pq ser trivial, sobre todo teniendo en cuenta que debe dar salida a todo el tema de objetos no interactuables (con los que no se puede colisionar)... es mas, tal vez empieze haciendo un fondo (con la imagen que tengo de la estrella de la muerte) que se mueva lentamente..... mmmm

Bueno, por hoy vale.

PD: No se ve bien, esta el x-wing girando hacia la izquierda en el extremo izquiedo con su rectangulo detector de choques redimensionado.

Pequeñas cosillas

Hoy ha tocado afianzar cosillas:

He arreglado el fondo. Ahora coge cualquier imagen y va haciendo tiles dinamicamente con ella segun el numero de cortes que le quiera dar en X y en Y. Luego llama a un metodo -si es menester- para que haga un ciclo con la imagen. Este ya esta, aunque supongo que hare otro(s) para hacer fondos que no ocupen toda la pantalla, tipo estrellas, planetas, estrellas de la muerte... pienso que lo mas comodo sera hacer uno (o varios, por si quiero sobreimpresionar fondos que se muevan a diferente velocidad y crear sensacion asi de profundidad) y tratarlos como a los containers de naves (aunque sin buscar colisiones). Dibujados en el orden correcto tiene que ir bien...

Ademas he hecho que el programita que se ejecutaba aparte y que me daba las coordenadas y las medidas de los rectangulos que envuelven a los frames escriba sus resultados a un archivo (tal vez a un archivo por nave sea lo correcto, ya vere) y un metodo en utils que lo lee y lo carga en una lista. He guardado los datos en bytes, de modo que vaya poniendo todos los datos consistentes en tipo para cuando vayan por internet (imagino que no habra mucha diferencia entre mandar bytes a un archivo y a un ordenador remoto).

Por ultimo he convertido en privadas algunas propiedades de SpritezatedImage (que nombre mas horrible) con el consabido '__' de modo que pueda controlar el acceso desde fuera, vienen a ser las propiedades que indican el numero de sprites en y y x, la anchura y altura del frame (hasta ahora era constante y a partir de ahora sera un valor de un array) y las coordenadas y y x del frame dentro de la imagen con todos los frames.

Mañana, a parte de terminar el asunto de que se cojan las imagenes y sus rectangulos contenedores debiera pensar otro metodo para hacer el efecto de que las naves 'se tumben' ya que recibir todas las coordenadas de cada objeto en un array unidimensional y tratarlo como bidimensional... no se... ademas en mapas de frames que he obtenido por internet pareciera que utilizaran mucho mas la horizontal que yo... tengo que mirarlo....

PD: Ah! ademas he puesto un log por pantalla que me da los arrays que se dibujan y que definen a cada objeto que se dibuja:

Avantti ma non troppo

Llevo varios dias sin actualizar esto asi que tratare de ponerme al dia en orden cronologico:

Puse un fondo al matamarcianos el sabado, compuesto de un monton de sprites cuadrangulares que se pintaban todos e incluso escrolaban verticalmente...

El rendimiento cayo un monton, a estas alturas no deberia preocuparme de esto, pero bajo de unos 350fps de media a unos 50-60... Horrible... De modo que me plantee seriamente el tema de usar OpenGL desde ya, finalmente mejore el codigo y lo deje en sobre 80fps y me tranquilice...

Aun asi me decidi a terminar el motor.

Hoy lo he terminado y esta funcionando. Se le pasan:
[indice_de_imagen_convertida_en_un_array, x, y, coord_x_del_frame_a_pintar_en_la_imagen_de_frames, coord_y_del_frame_a_pintar_en_la_imagen_de_frames, angulo_a_rotar_la_imagen]

Es decir 6 enteros. El fondo lo dibuja tambien el motor pero en otro metodo independiente pendiente de terminar -no considero necesario pasar todos los datos de el fondo por internet ya que es una parte 'pasiva' y ademas cuando este la parte de internet disponible se podra pintar el fondo mientras se obtienen datos- y funciona todo en el mismo proceso (para jugar en red habra que implementar un proceso paralelo pero para jugar en local no es necesario).

Ademas ya empiezo a tener frames de xwings, awings, tie-figthers y tie-bombers, en cuanto vaya teniendolos bien los subo.

Voy a empezar a poner capturas de pantalla para que se vea como va cambiando... Pero eso mañana, me voy a ver flash-forward

Sprites

De vuelta con los sprites en la cabeza....

Y cuando me refiero a sprites me refiero a todos los frames que forman una animacion... y no a la imagen actual dentro de esa secuencia y sus coordenadas en la superficie... Reitero, menos mal que esto es solo para mi....

Me he dado cuenta que poner todos -o al menos muchos- de esos frames en cada imagen puede estar bien, claro que como pueden tener diferentes tamaños habra que cambiar un poco el codigo para que tome las coordenadas x,y del vertice superior izquierdo y as xf, yf del vertice inferior derecho (o sus altura/anchura, vaya), y no solo eso, lo peor: habra que sacar las coordenadas de cada frame a manija lo cual puede ser una autentica tortura....

Asi que esta tarde me he dedicado a hacer un scriptcillo que encuentre todas esas coordenadas por mi y me los deje por ahi en algun archivo como datos que pueda coger directamente el pograma.

Aun tiene sus limitaciones: Hay que separar las filas de frames con una linea de distinto color que el fondo y no me escribe datos a archivos... solo hace esto:








:)

Esta eliminado el color de fondo (magenta) y hardcodeado otro para q sea como en el juego, luego se pintan encima los rectangulos que he conseguido.

Los he conseguido haciendo una matriz de colores RGB con la imagen y recorriendola en X e Y en busca de no-magentas y no-verdes....

Este codigo lo tengo que subir pq la verdad es que me parece util...

No prolijo

Se acabaron los dias prolijos, llega la oscuridad, el miedo y las dudas...

Me he apuntado a la UNED, y una de las asignaturas que he cogido para este año versa sobre OpenGL, que esta muy bien, claro, pero pygame utiliza SDL, habia otra libreria (pyglt) que usa OpenGL pero me decidi por pygame por que siendo una aplicacion en 2D tenia la impresion de que iba a sobrar (y es una libreria mucho mas madura que pyglt). En fin, que tal vez algun dia haya que cambiar...
Solo se importa pygame desde 2 archivos, el main y el de images, en un futuro no se deberia usar desde el main pero todo se andara pq el de images se va a dividir en varios rapidamente... He pensado en hacer un wrapper de pygame pero en python he leido que no se deben meter capas alegremente si quieres rendimiento (no es que a estas alturas me importe el rendimiento como para cambiar nada, pero si como para no hacer cosas que lo penalicen)

He aprovechado para mover un par de cosas de sitio que me estorbaban y para meter comentarios.

Y hacer los papeles de la convalidacion de asignaturas de la UNED, claro.

Dudas que me han surgido: Basicamente los sprites;

-No se si rotarlos programaticamente (coger una imagen y hacerla un rotate(radians)) o coger imagenes fijas de los sprites con diferentes angulos....
-No se como colocarlos: todos en un gigantesco 'mapa de sprites' como se bajan usualmente de internet y solo abrir un archivo o divididos por 'nave'? La primera solucion parece optima, pero como hacer para recorrer el mapa si los rectangulos que ocupa cada imagen son de diferentes tamaños? Evidentemente se me ocurre como, pero no Como.
-No se (y esta muy relacionado con lo anterior) si meter todos los sprites del mismo tamaño y mover un rectangulo de imagen en imagen para simular movimiento o meter las imagenes Y los anchos el rectangulo que contiene la imagen del elemento en cada posicion... menos mal que esto solo lo leo yo... por el gran FSM.....

Cambiando sprites

Bueno, hoy tambien ha sido un dia prolijo:

Primero de todo y lo mas importante: ya tengo SVN. Estaba gestionando el historial de codigos a mano y realmente... apesta... Ahora tengo 6 .zips y 3 versiones en el repo :) Eso si, el repo esta en LOCAL, asi que no podre hacerlo publico mientras no pueda ponerlo en mi servidor (cosa para la cual, repentinamente, he perdido todo tipo de prisa). en fin...

He conseguido tambien un sprite a partir de modificar para ordenar segun mi conveniencia unos de: http://www.gamedev.net/community/forums/topic.asp?topic_id=495808 son de un tal 'Prinz Eugn' (son los de aqui al lado) y son libres, el tio solo quiere que le digan si lo utilizas y que le metas en los creditos... No lo voy a usar mas que a modo de pruebas pero he de reconocer que el tio es un artista del copon. Yo me he encabezonado y he hecho 2 sprites mas para la rotacion (eran 3) queda convincente... Es una lastima que me haya encabezonado con starwars... Estoy por mandarle un mail: Guy! I need a star-wars-ships sprites!

En lo que se refiere al juego: he conseguido separar la parte que calcula la posicion del sprite de la parte que calcula el sprite que debe dibujarse de todos los de la imagen y me ha quedado convincente. Lo he hecho como una superclase controlando el sprite a dibujar que es extendida por otra clase que calcula la posicion del Sprite.

He creado ademas una nueva clase 'SpriteStatus' que es uno de las propiedades de SpritezatedImage (nombre horrible que ha de cambiar) y que siguiendo el patron 'strategy' cambia el modo de recorrer la fila de sprites. De momento hay uno para el 'no hacer nada' y otro para el 'girar' (a izquierda o derecha solo depende del valor de Y). A priori parece bastante escalable... y lo peor es que funciona bastante bien, el avion ya gira a la derecha cuando va a la derecha y a la izquierda cuando va a la izquierda... :) Creo que lo he hecho de una manera bastante precaria y que voy a tener que mejorarla mañana o asi... pero por hoy vale.

Noto una necesidad IMPERIOSA de sprites de star wars....

Cambios varios -YA MATO!-

Hoy he hecho varios cambios:

Por fin he aislado completamente el render del draw en el defaultSprite, no tenia mucha enjundia pero había que hacerlo.

He creado mi propio sistema de colisionado, aun es muy básico, solo obtiene un choque rectangular bastante tosco -pero que queda sorprendentemente bien, aun así- para el futuro quedara, en caso de que lo vea necesario -que insisto que por ahora me convence- hacer subrenctángulos dentro de la imagen que contengan a la figura y que le den mas precisión. Definitivamente creo que voy a poder prescindir de la clase pygame.Sprite ya que el remove() que yo creía que automáticamente eliminaba el sprite de todos los grupos es bastante cutre... (hay que pasarle los grupos en los que puede estar)

Ya que he encauzado el tema de las colisiones que menos que probarlo... he implementado vida a las balas y a las naves y ya mueren... Esta bastante bien y es un punto muy propicio para hacer otro alto en el camino y ver que el codigo este quedando BIEN, así que supongo que lo próximo que tocare sera eliminar pygame.Sprite de mi programa.

Sprites, quiero sprites.... Procedo a reinstalar el Alliance y a sacar alguno...

El motor ha quedado enfilado pero aun no quiero meterlo pq se que me voy a liar con eso innecesariamente, primero que sea usable, luego ya funcionara en red...

Engine

Ahora me he puesto a hacer una nueva clase que contenga las imagenes y los rectangulos que se van a dibujar... Vale, eso se llama sprite, pero no acabo de ver que tenga que controlar las colisiones tambien... en pygame originalmente no se hacia en la clase sprite y seguramente si han evolucionado a ese modelo es por algo... pero ahora mismo a mi no me convence tal y como esta en mi juego....

Ademas tengo pensado que las imagenes tengan distintas filas de sprites para distintos estados, por ejemplo 3 para que si no se pulsa ningun boton el motor de la nave saque fuego moviendosse, 3 de la nave con distinta inclinacion a la derecha, 3 a la izquierda, 3 para la explosion.... introducire en esa clase la logica de cambio de fila y comportamiento (por ejemplo en la explosion, que despues de dibujar todos sus sprites ese objeto no tiene que volver a dibujarse...) a la hora de recorrerla en la nueva clase.

Funciona bien por ahora, tiene las imagenes, el numero de sprites en los que se divide la imagen en X, lo mismo en Y, el ancho y el alto de cada sprite... desafortunadamente por ahora los sprites solo avanzan en X

Ahora tengo que cambiar las imagenes por indexes de imagenes para allanar el camino de lo siguiente que tengo en mente:

Proximo TODO: Un motor

Se trata de un objeto al que se le pasan una serie de cosas que hay que dibujar a una cola y el las dibuja...

Tiene sus cosas buenas y sus cosas malas, a saber:

-Podre hacer que se pueda utilizar en red, con solo poner un protocolo que me mande objetos como los que interpreta el motor, lo cual puede parecer absurdo en un matamarcianos pero quien sabe, igual queda bien.

-Me van a sobrar bastantes cosas de pygame.sprite (por esto he dicho que no me convencia), al motor NO pueden llegar sprites ya que estos contienen una imagen (o una referencia a una imagen, vaya) y un rectangulo... y esas cosas ocupan mucho, o al menos no se cual es su tamaño, como para mandarlas por internet... tendre que hacer mis propias 'referencias' de imagenes en una lista interna con todas las imagenes y pasarle esta referencia, las coordenadas y las coordenadas del sprite a dibujar dentro de la imagen. 5 enteros, 2 + 2 + 1 + 1 + 2 bytes.

Esta hecho pero no probado, mañana le doy cera, solo hay que cambiar el draw the el DefaultSprite, el resto cambiado y funciona.

Haciendo un matamarcianos

Pues si.

Me ha dado por hacer un matamarcianos, y he decidido hacer un registro de todo lo que voy haciendo, todos los problemas que voy encontrando, todas las cosas que se me van ocurriendo, etecetera....

Vamos a comenzar con lo que uso:

He utilizado hasta ahora el mejor editor del mundo: VIm, pero a la hora de tener muchos archivos abiertos del mismo projecto no me acaba de convencer... Tengo que mandar un email a Jon a ver si me da alguna pista para lidiar ese problema.... Ahora uso eclipse con pydev, la libreria pygame y python 2.6. Tengo que poner subversion en mi servidor y algun dia, cuando consiga pasar el maldito router, hare publico.

Voy a probar algo llamado easyeclipse que parece ser que viene con todo lo que necesito... solo por probar....

En fin, el codigo:

Se compone de varios modulos, que a grandes rasgos son:

sprites: Tiene una extension de pygame.sprite (en python no hay interfaces) que actualmente se ocupa de renderizar y dibujar el sprite de la imagen que queremos.

ships: extienden a LivingObject, que es un objeto con una cierta velocidad, vida, y un numero maximo de disparos (una nave, actualmente). Hay diversos subtipos como son: PlayerShip, EnemyShip....

shots: son los distintos tipos de disparos... Actualmente solo hay un sprite.... pero esto cambiara

strategies: son las estrategias que van a usar los shots para causar destrozo, pueden seguir en linea recta, recalcular su velocidad para dirigirse a su objetivo....

images: la imagenes que se usan en los distintos sprites, como van a ser comunes tengo pensado ponerlas aparte de modo que pueda incluir en ellas la logica de calculo del sprite, no suena bien, lo se, pero me tengo que convencer de que no esta bien

main: tiene el bucle principal

Cosas curiosas:

NO puedo usar los cursores y el espacio por que interfieren entre ellas... tiene algo que ver con el metodo de fabricacion del teclado (literalmente con el diseño de este), de modo que se dispara con la x