Proyecto de juego: Las Aventuras de Tolo

[Haplo]

Bueno, he cambiando sutilmente el nombre del protagonista a "Tolo", no he encontrado nada relevante que se denomine así pero si alguien tiene algo que aportar...

Respecto al estado del proyecto, he estado dándole un repaso a los gráficos y los sprites, ya que a día de hoy llevo casi 20KB y todavía faltan algunos. El tema de las máscaras ocupa un huevazo, pero sinceramente, no he visto manera de utilizar otro método como el que estoy usando y no tener que "duplicar" esa información aparte.
Matizo, hay métodos claro está, otra cosa es que sean razonablemente rápidos. Daros cuenta que trabajamos con 2 pixels por byte, en el momento que tenemos que comprobar bits todo se ralentiza y se complica cosa mala. La supuesta mejora de velocidad al no tener que pintar cuando se detecta el color máscara se va al carajo en cuanto hay que meter comprobaciones. Aparte que los pixels transparentes son muy pocos, por lo menos en mis sprites.

De momento el tamaño no me preocupa demasiado, teniendo en cuenta que tengo pensado tirar de modo 128k o acceso a SD para leer datos adicionales, aunque no he mirado nada de esto todavía

[Hark0]

¿acceso a la SD para carga....?

Un juego multicargas?

[Haplo]

Vamos avanzando

Una vez que me he aclarado con el tema de la paginación de memoria, la gestión de las interrupciones y el uso del shadow screen en modo Timex, ya empiezo a verlo más claro jejej
Básicamente, uso las interrupciones para actualizar coordenadas, restaurar el fondo y pintar los sprites en la shadow screen de una vez. El cambio de pantalla es instantáneo.
Uso las 2 pantallas disponibles en 4000h y 6000h.

También he progresado con la gestión de los sprites, ahora hay posibilidad de cambiar su velocidad de animación, la secuencia de frames y su desplazamiento relativo. En principio he previsto manejar en algunas pantallas hasta 16 sprites simultáneamente, pero aún estoy haciendo pruebas. Esto se está poniendo interesante.

Esta tarde se me ha ocurrido comprobar a cuántos FPS funcionaba el juego, tras probar algunas cosas, he puesto algunos "OUT (254),a" en sitios clave para que hacerme una idea del tiempo que tardan las rutinas principales.

Como esto se aprecia en funcionamiento, he aprovechado y he grabado un vídeo con el emulador, como siempre a 50 FPS y al 100% de velocidad.
Se trata de una pequeña demo donde se ven al protagonista manejado por teclado y 15 bichos saltarines controlados por la cpu, con varias velocidades.

Durante el vídeo se aprecian unas franjas en el borde que paso a explicar:

-Franja Verde: Tiempo que usa la rutina de actualización de coordenadas y de animación de los sprites.
-Franja Naranja: Tiempo que emplea la rutina de restauración de pantalla, borrando los sprites.
-Franja Violeta: Tiempo que emplea la rutina de impresión de los sprites en su nueva posición.
-Franja Amarilla: Fin de todas las operaciones, habilito la interrupción y vuelvo a la rutina de control del personaje (un loop que lee las teclas y hace algún chequeo de colisiones básico con los bordes)

En algunos momentos "congelo" los bichitos y sólo muevo al protagonista, para que se vea el impacto que tiene sobre la ejecución de la rutinas. Lógicamente la franja Verde casi desaparece, al sólo tener que gestionar un sprite.

Por último, he colocado un contador de las veces que se ejecuta la rutina de impresión de sprites. Cuando llega a 50, pone el borde de color rojo, cosa que se ve fugazmente en la franja amarilla inferior. Juraría que esto se produce una vez por segundo, lo cual parece indicar que son 50 FPS de velocidad de refresco.

De todas maneras hay cosas que optimizar, he tirado de registro IX a saco para no volverme loco y eso se nota, pero es algo que le meteré mano si hace falta al final.

Ya veremos que fino va todo cuando le meta toda la lógica de colisiones, las interacciones entre distintos tipos de enemigos y el protagonista, la animación de elementos del background (el agua por ejemplo), efectos de sonido y música...

Hasta la próxima actualización!

tolo.zip

(8.26 MiB) Descargado 231 veces

[Radastan]

Madre mía. técnicamente te cepillas lo que estoy preparando con creces.

[Mejias3D]

Impresionante Haplo

Qué Crack!

[antoniovillena]

Sí. Tiene muy buena pinta. Si te sirve de ayuda, te comento cosas que me ayudaron a optimizar en el engine FASE:

1) La rutina de borrado es más rápida si guardas lo que había antes de pintar. Yo esto lo hacía mediante la pila. El otro método es calcular lo que había antes leyendo del mapa y los tiles, pero es más lento.
2) No pintes todo el sprite, sólo la parte que hay que pintar. Si el sprite es de 16x16, habrá veces que sólo necesites pintar sólo la mitad. Esto te costará bastante implementarlo, pero te aseguro que es más rápido que el método de la máscara.
3) Hay cosas como los disparos que es mejor tratarlos aparte. Los pintas con XOR que es mucho más rápido, así la rutina de borrado es exactamente la misma que la de pintado y no necesitas almacenar nada del fondo.
4) Emplea técnicas agresivas como loop unrolling o PUSH/POP en lugar de LDIs para ganar ciclos adicionales

[Radastan]

Antonio, ya podrías sacar el engine de ZX Spectrum que te curraste pero para ZX Uno. No creo que te costara mucho, y menos con las interrupciones raster de las que gozas ahora. Preferiría dar soporte en mi kit a un engine de calidad como el tuyo.

[chernandezba]

Qué buena pinta tiene! Enhorabuena!
Me gusta mucho como te va quedando y me gusta casi aún más que haya sido desarrollado usando ZEsarUX

Sigue así, buen trabajo!

Por cierto quizá vaya a parlabytes, tengo que cuadrar agenda

Saludos
César

[Haplo]

Gracias Antonio, muchas de las cosas que comentas ya las hago y algunas hasta en modo extremo, por ejemplo, crear una rutina de pintado que no usa máscara en la parte central del sprite, así me ahorro 10 bytes por frame y acelero algo el proceso. Lo que pasa es que hay que tenerlo en cuenta al crear los gráficos y ordenar de cierta manera los datos.

Uso la pila o LDI según sea el caso, no siempre una es más rápida que la otra. Siempre ando con la calculadora de estados en la cabeza jejej

Optimizaciones como ésta son las que mencionaba en anteriores post que me generan rutinas poco estándar y adaptables para otros juegos. Cosa que si cumplen las que publica Radastán.

No tengo que guardar el fondo porque ya está guardado todo desde el principio, lo único que hago es restaurar desde esa copia "original". Es bruto en cuanto a consumo de memoria, pero más rápido también.

Lo de los disparos y similares, también había decidido usar una rutina específica tanto para control como el pintado. El tema de hacerlo con XOR... tengo que mirarlo, no sé que tal quedaría estéticamente.

[antoniovillena]

Radastan, gracias. Reescribir el engine para el modo radastaniano no es tarea fácil, se me ocurrió en su día pero no creo que lo haga a corto/medio plazo. Pero parte de las ideas las puedes emplear depurando desde la demo.

Haplo, ya te dije que no es algo trivial lo del pintado de sprites. Yo uso una utilidad ad-hoc en C que me convierte los gráficos y me los ordena de la forma que yo quiero. Por ejemplo para pintarlos empiezo por arriba y voy a la derecha, luego bajo una línea y sigo hacia la izquierda, y así sucesivamente durante un número par de líneas. La longitud de la línea, el número de líneas y el offset donde empezar la línea siguiente son datos que extraigo del mismo stream que los sprites, de esta forma no tengo que hacer una rutina para cada sprite.

Lo de guardar el fondo en bruto es muy bestia. Lo mejor es utilizar un stream donde guardes los bytes que vayas machacando. Si haces la rutina de borrado en orden inverso (de abajo hacia arriba desde el último sprite pintado hasta el primero) recorriendo es stream como si fuera una pila (si guardaste con push, restauras con pop) obtienes la pantalla libre de sprites empleando menos ciclos de CPU y menos RAM.