22 de septiembre de 2012

Recuperando velocidad... FPS

Debido al problema comentado en el post anterior, decidí compartirlo con la gente del Foro de GLBasic. Enlace aquí en castellano y aquí en inglés.

Y... bien, parece que he logrado reparar el problema...

Aunque creo que todavía puedo sacarle más FPS, actualmente tengo 45-60 FPS en casi la totalidad de la aplicación, salvo en la pantalla de juego, que depente de la cantidad de gráficos que contenga el mapa en cuestión... se queda en 30 FPS.

El tiempo de pintado de pantalla está actualmente en 0.5-1 ms para el juego normal y cae a 3,5 ms para las pantallas con más carga gráfica...

¿Dónde estaba el problema?

- Parece que al iPad1, le cuesta ejecutar con la misma velocidad que en ordenador, las rutinas gráficas de GLB tipo DRAWLINE, DRAWRECT, etc. He sustituído estas funciones por DRAWSPRITE / DRAWANIM que sí funcionan a velocidad aceptable.

- He PREcalculado las posiciones de los gráficos antes de pintar la matriz de mapas. Anteriormente realizaba los cálculos en el bucle de pintado de mapas, frenando así la velocidad del juego. La diferencia puede ser muy notable, os recomiendo hacer pruebas en vuestros loops si tenéis que calcular en tiempo real la posición de tiles, etc... Un cambio tan sencillo como añadir una suma en un loop puede hacer que el tiempo de render de una pantalla pase de 0,5 a 10 ms rapidamente.

- Para la rutina de dibujado de mapa, que es un bucle bastante largo debido a las dimensiones de mi mapa, he seguido el consejo de @Hardyx... con CREATESCREEN hago un solo cálculo y luego sólo tengo que pintar el sprite correspondiente al mapa... he pasado en esta pantalla de 50 ms a 0,5 ms...

19 de septiembre de 2012

Solo 18 FPS ?!?!?!

Acabo de realizar un test de compilación de la versión actual en iPad. (No con la última versión Beta 11.17x, que parece que da bastantes problemas, utilizo v 11.001 Fork).

Debido al nuevo motor que gestiona el mapa, parece que no puedo superar los 16-18 FPS. :-O

Tendré que realizar algunas pruebas en el bucle principal que gestiona el pintado del mapa (además del resto de objetos/botones/etc. que tengo en pantalla).

Quizás eliminando algunas "capas de transparencia" que aplico con la función ALPHAMODE solvente el problema y pueda conseguir más frames.

Con lo bien que funciona en el ordenador... ¿será por causa de la potencia del iPad 1?

17 de septiembre de 2012

El "log" de la partida...

Este fin de semana he estado trabajando en el "log" que incluye juego. Pretendo añadir una lista de todas las acciones realizadas por el jugador a modo de resumen.

La idea es utilizar la misma zona de pantalla donde muestro la información de los objetos/enemigos del mapa...

En la secuencia de capturas que publico se puede apreciar el "log" antes y después de recoger objetos en el mapa.

También incluyo la opción de mostrarlo a pantalla completa, con el mapa a la izquierda.

13 de septiembre de 2012

Por fin... GLB v.11.163 Beta

Tras el desastre sufrido por Gernot con su Disco Duro, parece que por fin ha podido restaurar/reparar los ficheros del proyecto.

El pasado 10 de Septiembre se publicaba el anuncio de la esperada versión 11 del entorno, donde se supone hay implementados los fix relativos a bugs de iCade, etc. detectados por @Dacarsoft.

Así que hoy toca probarlo en el iPad y comprobar hasta qué punto se han solventado los bugs detectados en la versión anterior.

(fichero log_e.gbas)
// 11.163 Beta
// Mac, Linux:
// AUTOPAUSE FALSE was ignored.
//
// Win32, WinCE:
// KILLFILE can also remove empty directories.
//
// Android:
// PLATFORMINFO$("DOCUMENTS") returns external SD card directory
// PLATFORMINFO$("APPDATA") returns internal storage (same as before)
// if you need the old documents, use PLATFORMINFO$("APPDATA")+"/.."
// PLATFORMINFO$("LANG") now returns java.util.Locale.getDefault().getLanguage()
// instead of getDisplayCountry()
//
// Core:
// SAVESPRITE - png does not include palette information (smaller files)
// ASR() always returns a positive number (treat input as unsigned int32)
// 3D:
// X_PRINT has optional kerning parameter.
//
// Compiler:
// ?ELSEIF implemented.
// Output of GPCxxxx error numbers for searching in the forums.

10 de septiembre de 2012

"Scrollando" el mundo...

Estos últimos días sin actualizar el blog, los he empleado en reparar un problema que encontré durante mis pruebas del gameplay.

Inicialmente, todo el diseño del juego, el movimiento del protagonista controlado por el jugador, así como los bots enemigos que aparecen, estaban pensados para una sola pantalla estática (tal como se ha podido ver en las capturas en este blog).

Utilizar una sola pantalla limitaba un poco mis espectativas en el diseño de los mapas. Siempre pensé en añadir algún tipo de mapa/sector que se interconectara con otra sala. Poner más salas no representó más problema que añadir una nueva "dimensión" a la matriz de datos de los mapas para poder soportar todas las pantallas.

Hasta aquí todo bien, siempre y cuando el diseño de los mapas estén a cargo del programador. En mi caso, al añadir la opción de Diseñar mapas propios, puedo encontrarme con un problema:

- Los mapas están diseñados como cuadrículas contiguas, de forma que cuando el jugador mueve el protagonista hasta el borde izquierdo de un mapa, se carga el mapa contíguo, y el jugador pasa a la posición más a la derecha del nuevo mapa.

Pero: ¿Qué hacer si se ha colocado un item/enemigo/obstáculo en esa posición?

Si es un ítem es sencillo, se recoge y se actualizan las variables en función de los beneficios/pérdidas del objeto en cuestión.

Si se trata de un enemigo, nos encontramos con el protagonista en la misma posición que un bot, por lo que correspondería empezar un combate... sin que el jugador se de cuenta de porqué y además sin opción a esquivar ó evitar el combate.

En el caso de un obstáculo, podemos detener el moviento del personaje ANTES de cargar el siguiente mapa, dejándolo en la posición X más a la derecha. Para el jugador será incomprensible el porque no se puede pasar al siguiente mapa (no sabe QUE hay en la posición contigua).

Tras consultarlo con algunos amiguetes, he decidido tomar la solución que creo es más elegante, aunque modifica en sobremanera el gameplay del juego. Se trata, tal como indica el título del post, en "scrollar"(desplazar/mover) el mapa por la pantalla, dejando al personaje protagonista siempre en la posición central, pudiéndolo mover en caso necesario hacia los bordes.

He tenido que reescribir todas las partes relativas al mapa y al control de movimiento, ya que ahora se mueve el mapa, y no el protagonista. Ahora cargo todo el mapa entero en memoria, y con una rutina de recorte, presento solo la posición actual en el mapa.

También se ha visto afectada toda la parte relativa al Editor, reemplazando el código relativo a los sectores, por un sólo mapa único... etc.

Espero tener en breve ya una muestra en vídeo de todo el trabajo, ahora toca modificar toda la parte de control de los enemigos... buffff.

5 de septiembre de 2012

Recordando Tapwave Zodiac 2

Hablando ayer con mi compañero de fatigas Javier, del proyecto monkeydreams.net (dominio cerrado), recordábamos las aplicaciones y juegos que habíamos desarrollado para la Tapwave Zodiac2 y dispositivos PalmOS.

Aquí unas fotografías de la máquina en cuestión con nuestros títulos ejecutándose... que buenos tiempos. ;D