PDA

Ver la versión completa : Es Python demasiado lento para al GP2x?



davidgutierrez
08/12/2007, 15:56
Esta es la pregunta que me ha surgido durante el desarrollo de mi juego Sliding Puzzle 2x y quería conocer la opinión de otros foreros al respecto. En versiones anteriores del juego, se realizaban demasiados refrescos de pantalla innecesarios y se refrescaba toda la superficie de la pantalla en vez de refrescarse únicamente la zona afectada. Cuando lo ejecutaba en el ordenador no tenía ningún problema, pero al ejecutarlo en la GP2x me dí cuenta de que el juego no iba tan fluido como debería. Este problema ya está solucionado en la versión actual del juego donde solo se refresca la pantalla cuando es estrictamente necesario y solo la parte de la pantalla que se haya visto afectada.

Aún estoy aprendiendo a programar en Python y la verdad es que me encanta como lenguaje de programación (tanto por su simplicidad como por no tener que preocuparme de "los punterillos locos"), pero esta experiencia me lleva a plantearme si Python es un lenguaje adecuado para desarrollar juegos para la GP2x... Me vengo a referir a lo siguiente: está claro que con Python se pueden hacer juegos de tipo puzzle sin ningún problema (a las pruebas me remito), pero no es ningún secreto que es un lenguaje muy lento en comparación con los lenguajes compilados, por lo que no sé que tal se comportará en juegos de acción donde haya muchos objetos en pantalla o en juegos de plataformas plataformas con scrolling. En ambos casos habría que actualizar prácticamente la totalidad de la superficie de la pantalla muchas veces por segundo, por lo que el rendimiento se puede resentir enormemente.

Por otro lado, salvo error mío, el tiempo de arranque de Python en la GP2x es de unos 5 segundos (durante los cuáles la pantalla se queda en negro ANTES DE COMENZAR la ejecución del programa), un tiempo que para algunos será completamente inaceptable. En el hilo sobre mi juego, efegea comentaba que estaba trabajando en un programa en C++ capaz de lanzar scripts Python. Para mí es una gran noticia, ya que esto podría evolucionar en un "lanzador de scripts Python" que mostrase una animación de "cargando" (utilizando C++ y SDL) mientras se va arrancando Python en background. Así, al mostrarse la imagen de forma instantánea y no tener que esperar 5 segundos con la pantalla en negro, se consigue dar la impresión al usuario de que el juego está haciendo cosas desde un primer momento .


¿Alguien más ha desarrollado / probado otros juegos que hagan uso de Python en la GP2x? ¿Cuáles han sido los resultados? ¿Eran juegos de acción o de puzzle? ¿Creéis que Python es un lenguaje adecuado para hacer juegos? ¿Es Python demasiado lento o es la GP2x la que es demasiado lenta y con la "craignator" no tendría este tipo de problemas?


Sé que nadie tiene las respuestas "absolutas y verdaderas" a estas preguntas, pero quería conocer las impresiones del resto de foreros antes de iniciar el desarrollo de mi próximo juego, por si tengo que empezar a replantearme algunas cosas y empezar a mirarme tutoriales de SDL... [wei5]

Puck2099
08/12/2007, 16:22
También puedes echarle un ojo al Fenix o uFenix que, por lo que comentas, debe ser más rápido ;)

Saludos

josepzin
08/12/2007, 17:06
Supongo que el problema de Python es el mismo que Java... al ser un lenguaje interpretado tiene demasiados "pasos intermedios" que la velocidad de proceso de la GP2X no puede soportar...

DarkDijkstra
08/12/2007, 17:17
Espero que no sea muy lento porque yo estaba empezando a hacer cosillas en python para la negrita ; )

Hombre, lo de "lento"... obviamente es interpretado, y por muy buena que sea el intérprete, no podrá competir en velocidad con C y derivados. Pero claro, dependerá del programa a utilizar.
Python es una maravilla en cuanto a la comodidad para programar, pero claro, si para cualquier cosa usas diccionarios, pues obviamente irá más lento que usar arrays en C. Todo dependerá también de las "optimizaciones" en el código.
Por otro lado, supongo que estarás usando PyGame o algo similar, que usa SDL para todo lo que es el "pintado" y esas cosas. Piensa que, en un juego está por un lado la "lógica de juego" (la IA, modificación de "entidades" y el "mundo", cálculos de juego...) y por otro lado la representación (si, habría una tercera parte, la entrada por parte del usuario, pero la obviaremos). Más o menos se suele estimar que el 70-80% de la carga de trabajo está en la representación gráfica, pero si aqui python le pasa el trabajo sucio a SDL, tampoco será tan traumático.
Yo creo que teniendo cuidado y no "relajándose" a la hora de hacer un código más o menos eficiente, no debería de ser problemático el usar python. Y sino, piensa en que algunos juegos (pongamos Blade) usaban scripts de python a saco (aunque el "nucleo duro" del motor de juego fuese en C++). De hecho supongo que todo el motor gráfico y tal iria en C++, pero para scripts de IA y similar, python les iba de miedo.

dardo
08/12/2007, 18:00
Supongo que el problema de Python es el mismo que Java... al ser un lenguaje interpretado tiene demasiados "pasos intermedios" que la velocidad de proceso de la GP2X no puede soportar...Java y python son rápidos para ser lenguajes interpretados, pero aun así es lento. Ten en cuanta que las clases de java sepueden (deben) compilar para obtener los bytecodes que interpreta la máquina virtual. No es como un lenguaje de scripts a pelo.

La virtud y a su vez defecto de python es que tiene una librería matemática muy precisa (es bastante más precisa que cualquier otra que conozca). Es rápida para la precisión que aporta, pero aun así es lenta como para que sea rentable incorporarlo en sistemas empotrados de baja potencia.

¿Lo estás haciendo con pygame o con python así a pelo?

< - >

Espero que no sea muy lento porque yo estaba empezando a hacer cosillas en python para la negrita ; )

Hombre, lo de "lento"... obviamente es interpretado, y por muy buena que sea el intérprete, no podrá competir en velocidad con C y derivados. Pero claro, dependerá del programa a utilizar.
Python es una maravilla en cuanto a la comodidad para programar, pero claro, si para cualquier cosa usas diccionarios, pues obviamente irá más lento que usar arrays en C. Todo dependerá también de las "optimizaciones" en el código.
Por otro lado, supongo que estarás usando PyGame o algo similar, que usa SDL para todo lo que es el "pintado" y esas cosas. Piensa que, en un juego está por un lado la "lógica de juego" (la IA, modificación de "entidades" y el "mundo", cálculos de juego...) y por otro lado la representación (si, habría una tercera parte, la entrada por parte del usuario, pero la obviaremos). Más o menos se suele estimar que el 70-80% de la carga de trabajo está en la representación gráfica, pero si aqui python le pasa el trabajo sucio a SDL, tampoco será tan traumático.
Yo creo que teniendo cuidado y no "relajándose" a la hora de hacer un código más o menos eficiente, no debería de ser problemático el usar python. Y sino, piensa en que algunos juegos (pongamos Blade) usaban scripts de python a saco (aunque el "nucleo duro" del motor de juego fuese en C++). De hecho supongo que todo el motor gráfico y tal iria en C++, pero para scripts de IA y similar, python les iba de miedo.
Lógicamente, pues se puede editar los scripts sobre la marcha. Por ejemplo, el Blender tiene muchas extensiones en Python, aunque creo que no está desarrollado entero en phyton.

EN general python está sustituyendo a Perl en todos los sitios donde este se suele utilizar.