Experimentos pintado de sprites en ensamblador
Publicado: 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/
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/