Experimentos pintado de sprites en ensamblador

Chit chat general. Habla con los MojonTwins y con los amigos de los MojonTwins. Reza a Vah-ka. Delinque. Aviso: está PROHIBIDO tirarse peos fuerte. Si les cortas el pescuezo, vale.

Moderador: na_th_an

antoniovillena
Mensajes: 494
Registrado: Jue, 24 Oct 2013, 15:52

Experimentos pintado de sprites en ensamblador

Mensajepor antoniovillena » Jue, 05 Dic 2013, 17:06

Pues eso, que estoy tratando de exprimir al máximo el ensamblador para ver cuantos sprites se pueden pintar en un 48K a 50fps y sin mostrar parpadeos. Estoy hablando de 48K, en un 128K se pueden pintar muchos más gracias a la shadow screen.

La técnica que empleo consiste en esperar que el haz de electrones termine con el borde superior y empiece a pintar la zona visible de la pantalla. Más o menos estaríamos por el ciclo 14400 de los 69888. En este momento generamos el fondo, la porción de pantalla que he escogido es de 1/2 del área total. La idea es pintar en memoria de video línea por línea a una velocidad inferior a la del haz de electrones, así nos aseguramos de que no se produzcan parpadeos. Si adelantamos al haz de electrones éste mostraría en pantalla el fondo sin sprites.

Una vez acabamos de pintar el fondo (o de borrar los sprites del frame anterior) andamos más o menos por el ciclo 55400 (hemos empleado unos 41000 ciclos). Así que tenemos unos 14500 ciclos hasta llegar al fin de frame, más los 14400 ciclos del comienzo del frame serían unos 28900 ciclos para el pintado de frames y todo lo demás.

Las rutinas de pintado de sprites son muy rápidas porque trabajan con los sprites ya rotados, calculo que de media se tardan unos 2000 ciclos en pintar un sprite. Así que en teoría se pueden pintar 14 sprites, a lo mejor en la demo me quedo con alguno menos porque para mover las coordenadas de los sprites también se necesitan ciclos, ya os iré informando.

Usando estas rutinas como base para un engine supongo que dará para unos 10 sprites, tengo que acabar la demo para confirmarlo. Esto no nos sirve para mejorar la churrera, puesto que la zona visible de la pantalla es algo más pequeña, las pantallas son de 12x8 tiles frente a los 15x10 que tiene la churrera. Por ahora no son más que meros experimentos, a no ser que alguien se anime a crear un engine desde cero.

El TAP lo adjunto, lo que hago de momento es mostrar un sprite moviéndolo por el mapa con las teclas OPQA, más adelante sacaré otros sprites (enemigos) moviéndose aleatoriamente y rebotando con los bordes de la pantalla (sin ninguna interacción entre ellos ni entre el sprite protagonista).

Los archivos fuente son juego.asm, GfxBu.c, para compilarlo se necesita juego.bat y otro bat como este:

$this->bbcode_second_pass_code('', '
dmc GfxBu.c lodepng.c
GfxBu sprites.png sprites.bin 9c00
')

http://sourceforge.net/p/emuscriptoria/ ... %B1uelera/
Adjuntos
juego.tap
(14.63 KiB) Descargado 346 veces
Avatar de Usuario
D_Skywalk
Mensajes: 352
Registrado: Mar, 01 Oct 2013, 13:36

Re: Experimentos pintado de sprites en ensamblador

Mensajepor D_Skywalk » Jue, 05 Dic 2013, 20:01

O_O

Déjame oler :_d

Gracias por compartirlo men :**
David Skywalker
Weblog: http://david.dantoine.org
Avatar de Usuario
radastan
Mensajes: 692
Registrado: Vie, 20 Ago 2010, 12:54
Contactar:

Re: Experimentos pintado de sprites en ensamblador

Mensajepor radastan » Jue, 05 Dic 2013, 20:50

Está de vicio, una genial idea, pero tengo una pregunta. ¿Maneja interrupciones? es que el Beepola como que no se lleva bien para los FX.
antoniovillena
Mensajes: 494
Registrado: Jue, 24 Oct 2013, 15:52

Re: Experimentos pintado de sprites en ensamblador

Mensajepor antoniovillena » Jue, 05 Dic 2013, 21:56

No va por interrupciones, se podría sincronizar vía interrupciones pero se desaprovecharían unos 14000 valiosos ciclos por frame. No tengo ni idea de cómo meterle sonido, de hecho es bastante complicado meter sonido durante el juego, creo que beepola (en la Churrera) se usa para meter melodías en el menu.

Mi idea es terminar la demo y dejarla así para que cualquiera pueda examinar el código fuente y si puede aplicarlo en sus juegos. Meterle sonido volvería el código más difícil de entender.

Edito: Ah vale, no te había entendido bien. Nada se lleva bien con el sonido durante el juego en un spectrum 48k sin chip AY. No hay otra opción que intercalar código para generar sonido en mitad de las rutinas gráficas, hay que hacerlo de forma chapucera, no se puede tener bonito y modular y no hay ninguna solución estándar que valga para todos los juegos. Si quieres échale un vistazo al código del Manic Miner.
Avatar de Usuario
D_Skywalk
Mensajes: 352
Registrado: Mar, 01 Oct 2013, 13:36

Re: Experimentos pintado de sprites en ensamblador

Mensajepor D_Skywalk » Vie, 06 Dic 2013, 10:48

Super rápido, pero claro completamente en asm que está fuera de mis posibilidades XD

Debes estar sincronizado o es independiente como la splib? hay posibilidad de usarlo en C?

Gracias por compartirlo aun no entendiendo nada :wan:
David Skywalker
Weblog: http://david.dantoine.org
antoniovillena
Mensajes: 494
Registrado: Jue, 24 Oct 2013, 15:52

Re: Experimentos pintado de sprites en ensamblador

Mensajepor antoniovillena » Vie, 06 Dic 2013, 14:26

Todo es aprender, el asm es difícil, pero una vez le pillas el truco no es tan chungo.

Sí, va sincronizado. Además es un tipo de sincronización (por bus flotante) que sólo se puede hacer en un modelo 48k. A diferencia de la splib y de la mayoría de los engines, además de ser antiparpadeo, se muestran los sprites sin mezclar. Los sprites mezclados ocurren cuando el haz de electrones pasa sin haber completado el sprite en curso, con lo que se vería la mitad superior del sprite con dibujo, y la otra mitad con otro distinto.

Sí, hay posibilidad de embeberlo en C, por ejemplo en el z88dk, aunque primero quiero terminar la demo (que se vean un montón de sprites bailando por la pantalla) para ver sus posibilidades reales.
Avatar de Usuario
radastan
Mensajes: 692
Registrado: Vie, 20 Ago 2010, 12:54
Contactar:

Re: Experimentos pintado de sprites en ensamblador

Mensajepor radastan » Vie, 06 Dic 2013, 16:20

Antonio, creo que ya habrás pillado por mi otro hilo por donde van los tiros de mi curso de C: una librería que sea tan fácil de usar como si fuera BASIC. Lo que te propongo es hacer una versión de esta rutina en ese plan, evidentemente se perderá rendimiento por el camino pero ayudará a mucha gente a hacer su juego y a introducirse en el Z88DK sin miedo.

Yo voy a terminar de optimizar mis rutinas, las que trabajan a baja resolución, si te animas podemos meter las tuyas. Así cubrimos los dos tipos de sprites que pueden darse.
antoniovillena
Mensajes: 494
Registrado: Jue, 24 Oct 2013, 15:52

Re: Experimentos pintado de sprites en ensamblador

Mensajepor antoniovillena » Vie, 06 Dic 2013, 18:57

Las rutinas de sprites con máscara son todas muy parecidas, al menos la base es la misma:

$this->bbcode_second_pass_code('', '
pop de
ld a, (hl)
and d
or e
ld (hl), a
inc l
pop de
ld a, (hl)
and d
or e
ld (hl), a
inc h
')

Por ejemplo este código escribe dos líneas de 8 píxeles cada una, una a la derecha de la otra y se queda apuntando hacia abajo. Por cada byte se gastan 36 ciclos, y este tiempo marca la cota mínima que se puede alcanzar con sprites enmascarados.

Lo suyo sería para el tutorial adaptar unas rutinas siguiendo esta misma base pero más sencillas que las mías.
Avatar de Usuario
D_Skywalk
Mensajes: 352
Registrado: Mar, 01 Oct 2013, 13:36

Re: Experimentos pintado de sprites en ensamblador

Mensajepor D_Skywalk » Sab, 07 Dic 2013, 11:21

Yo por soñar, molaría ver una librería tan compatible (en modelos) como la splib (con las tres funciones que usamos), sin tener que contar ticks para que se pueda usar en z88dk y en sdcc... O quizás si véis que sería interesante una 48K y otra 128K (por eso de la shadow esa XD).

Pero vamos yo con eso a día de hoy, me apañaría perfectamente ^^_

Un Saludo y ponerme con asm más allá de modificar código, para adaptar cualquier chorrada (como he hecho en asylum)
... no me veo XD
David Skywalker
Weblog: http://david.dantoine.org
antoniovillena
Mensajes: 494
Registrado: Jue, 24 Oct 2013, 15:52

Re: Experimentos pintado de sprites en ensamblador

Mensajepor antoniovillena » Sab, 07 Dic 2013, 15:16

En 48k va a ser difícil con esta aproximación, tendría que ser con algo parecido a splib. El problema es que hay que generar todo el fondo y eso consume bastantes ciclos, unos 40.000, por esa razón la ventana visible es menor.

Sin embargo en 128k sí que se puede sin problemas de ventana y se pueden pintar muchos más sprites. La idea es sincronizar para conmutar la página de video al principio de cada frame, se puede hacer con interrupciones con lo la instrucción HALT. Si por lo que sea el número de sprites está en el límite en un momento dado no hay problema, se usan dos frames en lugar de uno en ese momento y el usuario casi no lo nota. El mecanismo sería, al comienzo del frame, conmutar de página de vídeo (entre la 5 y la 7), borrar los sprites en la página que no se ve actualmente (estarían 2 frames más atras de lo que corresponde) y pintar en la misma página los nuevos sprites, para finalmente hacer todo lo demás (detección de colisiones, actualización de marcadores, etc...). Si tardamos 2000 ciclos en pintar un sprite, pongamos unos 1500 (caso peor) para borrarlo, tendríamos un límite superior de unos 20 sprites en pantalla.

Pero ya te digo, no serían exactamente las 3 funciones que usáis porque todo va sincronizado. Por ejemplo la función de update (no sé cómo se llama) no haría falta ya que esto se hace automáticamente al conmutar de página de video.

Volver a “General”

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 17 invitados