Una de las limitaciones que posee Pygame, una librería para desarrollar juegos con Python, a la hora de dibujar sprites en pantalla es que sólo es posible hacerlo en coordenadas enteras. Esto, para algunos sprites pequeños, ej. partículas, es un salto demasiado grande y se ve feo en la pantalla. Will McGugan, de Where there is a Will, escribió un pequeño paquete que toma una superficie (un Surface) de Python y lo transforma en una superficie capaz de dibujar objetos con coordenadas fraccionales, justo como lo harías con OpenGL u otra librería 3D. Al hacer este procedimiento con el código de Will, el objeto mismo hace el cálculo de los subpíxeles, y combinado con la animación que le des al objeto el resultado es un movimiento muy suave, como lo demuestra un GIF de ejemplo a continuación:
Las pelotas de encima están dibujadas mediante sub-pixeles, y las pelotas de abajo con coordenadas enteras. La diferencia en la suavidad de movimiento es notable. Requiere el módulo Numpy para poder funcionar. También tiene la desventaja que el precálculo hecho a cada superficie requiere una buena cantidad de memoria, específicamente 9 veces más que una superficie normal para el nivel por defecto de precisión, por lo que es manejable para superficies relativamente pequeñas.
Vaya con lo de los subpixels, interesante. De todas formas, veo que estás hablando mucho de las Surfaces pero no comentas nada de la clase Sprites y para el cuteGod podría venir bien. La principal ventaja es el bucle de actualización, que puede llamar a todo un grupo de sprites de vez si utilizan la misma función de actualizado (y seguramente el terreno del cuteGod cumpla esta condición). ¿O ya conoces los sprites y te decidiste por las surfaces (que vienen directamente de las SDL)? Si es así, ¿por qué?
En cuanto a la NumPy, me «fastidia» tener que usar terceras librerías para que las cosas vayan rápidas. Precisamente alguno de los juegos que participó en la última pyWeek no me funcionó porque no tenía instalada Numerical, la versión anterior de Numpy. Le cogí algo de manía : )
Hola Luis,
Tu pregunta es muy buena. Hasta ahora en CuteGodChigüire he hecho los bloques del terreno como una extensión de Sprite, pero no he utilizado para nada su funcionalidad ni la de los grupos.
Los bloques de terreno son particulares en este juego en el sentido de que: a) No precisan de ninguna actualización de movimiento por sí mismas sino hasta que los muevo con el mouse, b) La información de su ubicación depende de World, la clase que representa el mundo. Debido a que los bloques se pueden mover, me parece que tiene más sentido mantener la información de su ubicación en World en vez de adentro.
Es por esas dos razones que hasta ahora no he utilizado grupos ni sprites para representar los objetos del terreno, sino que he programado las cosas a un estilo personal: esto me ha permitido aplicar una o dos técnicas que ya conocía para dibujar y hacer detección del mouse.
Sin embargo, puede que otros objetos como los personajes sí los haga como Sprites, de ser necesario. Es algo que no tengo planificado por ahora. Esta tarde debería salir el artículo de la segunda revisión del juego, y allí aclaro más detalles de lo que voy a hacer. Quizás si tenga que aplicar algunas movimientos suavizados del terreno pueda utilizar las funciones que ofrece Sprite. Esta es la ventaja de lenguajes como Python, que puedo cambiar las cosas sin tanto esfuerzo.
Ah, Numpy… Estuve entre este fin de semana y el lunes averiguando cómo utilizarlo, y me conseguí con el rollo gigantesco del cambio de nombre entre Numeric y Numpy, junto con varios problemas, como no conseguir funciones que están en Numeric pero no en Numpy. Esto se traduce en que instalé al principio Numpy, y estuve enredadísimo con problemas como que no reconocía que había una función matrixmultiply, y otras cosas. Al final tuve que resolver instalando Numeric, contra toda recomendación de actualizarme a Numpy, y todos contentos.
Igualmente necesito esta librería para poder realizar operaciones fundamentales sobre las imágenes que no puedo hacer de otra manera sin tener que echar el código yo mismo. Así que no me queda otra que seguir adelante con Numeric.
Espero haber respondido tus preguntas. Gracias y está pendiente otros artículos más con respecto al prototipo.
Saludos!