31 de diciembre de 2012

Cerrando el año 2012...

Fin del tercer año de vida del blog. Muchas espectativas de cara al año que viene... con ganas de terminar definitivamente algunos proyectos que han quedado postergados... e iniciar algunos otros...

Sea como sea, cerramos el año con muchas ideas de cara al año 2013... esperemos poder cumplirlas todas... ;D

15 de noviembre de 2012

Modificando enlaces...

Cada X tiempo toca repasar los enlaces del blog. En esta ocasión he añadido una sección nueva llamada ZX Spectrum y he movido los enlaces relativos a ese apartado.

He aprovechado además para eliminar algunos links que parece que ya no apuntan a ninguna web.

20 de octubre de 2012

Retomando ElectricRPG...

Tras el paro comentado en los anteriores post, es el momento de continuar con el desarrollo del juego ElectricRPG. Toca recordar lo que funciona y lo queda por retocar... así que de momento voy probando cosas...

 

- Importar mapas (inbox iOS) funciona perfectamente.

- Gestión de mapas (importar/exportar) desde iTunes OK.

- La velocidad de la app es más que correcta (40 fps).

- Efecto de explosión enemigos correcto.

- RAM ok. Parece que la optimización de la rutina de Render ha dado sus frutos.

- Nuevo editor de mapas Ok.

 

Y continuo trabajando... ;D

Aprendiendo a programar un Emulador (DCPU-16) - GAME OVER

Se acabó el juego!

Para este "proyecto rápido" me había marcado un tiempo máximo de desarrollo de unos 15 días más o menos...

En los pocos ratos que he podido escribir (y entender primero) el código necesario para emular el funcionamiento de una CPU, he conseguido programar con éxito varias cosas:

- Main loop bastante decente controlando el tiempo de los ciclos de las instrucciones.

- Interpretación correcta de los word, así como las instrucciones y los operandos A y B.

- Control de lectura/escritura en Registros, Pila y RAM.

- Implementación de sistema de vídeo gráfico con Set de carácteres Ascii según especificaciones.

 

Desgraciadamente, he alcanzado el límite de tiempo, así que de momento aparco este asunto, pero con la intención de retomarlo en un futuro... y terminarlo.

Aunque no he podido llegar a terminar el programa al 100%, me siento bastante satisfecho con todo lo aprendido en este tipo de programación... creo que ahora estoy más cerca de entender completamente el funcionamiento de un procesador en su nivel más bajo...

En un futuro... MÁS!

17 de octubre de 2012

Aprendiendo a programar un Emulador (DCPU-16) -4

Nueva captura de mi emulador en la que se aprecian los pequeños avances en cuanto a control del programa en sí.

He añadido una rutina de control de teclado para poder modificar la posición PC y los valores de la RAM.

16 de octubre de 2012

4 de octubre de 2012

Aprendiendo a programar un Emulador (DCPU-16) -2

Bueno, como se puede ver en la captura, ya tengo montado una CPU en su estado más básico.

El mainloop funciona correctamente, aunque para DEBUGGEAR bien controlo el bucle con una pausa en espera de tecla... así voy viendo COMO está leyendo la RAM y si los registros y tal se actualizan como corresponden...

He implementado los registros, y tengo también una rutina que muestra el estado de RAM y VIDEO-RAM.

He introducido también en la RAM el código de un "Hello World", para ir comprobando que interpreto bien las instrucciones (esto ya lo tengo)... y hacer los cálculos/operaciones/lo que sea de dichas instrucciones (en lo que estoy).

Para el tema de sincronizar el vídeo me quiero basar en la info que se muestra aquí. (Es más/menos lo que comentaba @jepalza en un post) ;)

Pego el texto que me interesa del link aqui:

Con el fin de emular estas tareas deberás ejecutarlas tras el número apropiado de ciclos de CPU. Por ejemplo, si la CPU se supone que corre a 2.5Mhz y el display usa una frecuencia de refresco de 50Hz (estándar para el vídeo PAL), entonces la interrupción VBlank ocurrirá cada:

2500000/50 = 50000 ciclos de CPU

Si asumimos que la pantalla entera (incluyendo VBlank) es de 256 scanlines de alto y 212 de ellas son mostradas en el display (las otras 44 caen en el VBlank), entonces obtenemos que nuestra emulación debe refrescar un scanline cada:

50000/256 ~= 195 ciclos de CPU

Tras eso, debemos generar una interrupción VBlank y no hacer nada hasta que se haya acabado con el VBlank, es decir, durante:

(256-212)*50000/256 = 44*50000/256 ~= 8594 ciclos de CPU

Calcula cuidadosamente el número de ciclos de reloj necesarios para cada tarea, y entonces utiliza el divisor común mayor para InterruptPeriod, ajustando todas las otras tareas a él (no tienen porqué ejecutarse en cada expiración del contador Counter).

Las especificaciones de DCPU-16 difieren de las que se muestran en este ejemplo, así me tocará adaptarlas. ;)

OPS! Acabo de descubrir un pedazo de bug.... estoy cruzando el byte alto / byte bajo cuando leyo una posicion de RAM. Vaya cag*da!!! :P

*Solucionado!!! :D

Aprendiendo a programar un Emulador (DCPU-16) -1

¿Cómo se escribe un programa que emula un ordenador?

Picado por esta curiosidad, y animado por los post del foro Zonadepruebas cuyo tema es Proyecto ZDP-80 - Nuestro microordenador desde cero [#01], he decidido intentar escribir un emulador de la computadora DCPU-16.

Enlace en el foro donde consulto COMO implementar este tipo de programación. (Aprendiendo a programar un Emulador (DCPU-16)).

Muy interesante, recomiendo visitar los hilos sobretodo si eres una persona amante de la electrónica y los ordenadores. ;D

2 de octubre de 2012

Cambio de mes... y pausa breve.

Entrando en Octubre... voy a hacer una pequeña pausa en el proyecto para sumergirme en una "aventura nueva" relacionada con la programación y los emuladores...

Si no hay problemas, en breve más información.

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

28 de agosto de 2012

Dos nuevas "features"...

He añadido dos tonterías al código encargado de dibujar la pantalla de juego:

- Posibilidad de añadir un borde negro: El editor incluye una nueva opción que permite activar un "marco" negro en la zona exterior del mapa. Pienso que puede ir muy bien para mapas tipo cueva y/o laberinto.

- Scroll entre sectores: Otra nueva "feature" que he añadido al juego es el efecto de desplazamiento de pantalla cuando pasamos de un sector a otro. Creo que este efecto de transición introduce al jugador en el mapa de forma más "inmersiva" al ir visualizando el nuevo sector poco a poco.

Nuevo Editor...

Debido a que no estaba del todo contento con la distribución de las diferentes opciones y botones del editor de mapas, he decidido darle un nuevo diseño a este apartado.

He rediseñado los paneles laterales. Ahora se pueden añadir tantos paneles como se requiera, quedando las pantallas más limpias y con más "espacios en blanco" evitando así una saturación de botones.

Si se comparan estas capturas con las anteriores relativas al editor, se pueden apreciar las sutiles modificaciones. Internamente el código es nuevo 100%.

27 de agosto de 2012

34 días sin novedad...

Con el Agosto quemando sus últimos días, me reincorporo a mi puesto de trabajo. :-/

Han sido bastantes días de no publicar nada en el Blog, de leer mucho, programar algo en GLB, pasear, salir, etc. en definitiva, intentar desconectar...

No vuelvo con las manos vacías; en breve publicaré en el blog los cambios que he realizado al juego... que no son pocos. ;D

23 de julio de 2012

Probando el juego en Linux (x86)

Aprovechando que la placa Raspberry Pi utiliza como sistema operativo una distribución Linux modificada para procesador ARM he descargado la versión de escritorio de Ubuntu (x86).

Tras compilar en GLBasic, he comprimido en ZIP la carpeta resultante distribute y posteriormente he copiado dicho fichero al escritorio de Ubuntu.

Si se ejecuta directamente la aplicación nombre.linux no observaremos ningún mensaje de error ni tampoco movimiento alguno por pantalla.

Hay que activar la pestaña "Permitir ejecutar el archivo como un programa" en las propiedades de permisos del fichero nombre.linux.

Además, hay que descargar la librería libSDLMixer para que las aplicaciones compiladas con GLBasic funcionen en Linux. (Siempre y cuando NO tengamos instalada la librería).

Afortunadamente desde Ubuntu y su aplicación Instalación de Software, podremos encontrar el paquete dentro de Herramientas para Desarrolladores, con lo que no es necesario utilizar el terminal para nada.

Tras esta prueba, estoy más cerca de ver el juego funcionando en el televisor a través de Raspberry Pi...

20 de julio de 2012

Raspberry Pi Fedora Remix, OK

Probada la distribución Fedora Remix para el RPi. He detectado algunos problemas de Login cuando se reinicia la placa SIN desenchufar de la toma de corriente, así que para que todo funcione correctamente, hay que apagar completamente el RPi.

Por otro lado estoy elmininando de la distribución todas aquellas aplicaciones "innecesarias". En las capturas se puede apreciar el navegador Firefox funcionando...

Página en raspberrypi.org con la información sobre esta Distro.

Enlace a Fedora.

4 de julio de 2012

Raspberry Pi primer arranque, OK

He podido probar la placa. Tenía un poco de miedo de que algo no funcionase bien, pero como se puede ver en las fotos, ha sido grabar la SD y conectar. Perfecto.

Para el asunto de la corriente, utilizo un cargador de móvil LG, 5V 0,7A. USB a MiniUSB.

"Unboxing" Raspberry Pi

El nuevo "juguete" de la casa... el Raspberry Pi.

Ahora solo necesito un poco de tiempo para ponerlo en marcha... y a programarlo con GLB, por supuesto.

:D