Moderador: Sir Cilve Sinclair
Hark0 escribió:Me lo imaginaba... a 50fps... ni que fuera una xbox...
pd/ot: ¿sigues escribiendo el juego de "trenes"?
climacus escribió:Hark0 escribió:Me lo imaginaba... a 50fps... ni que fuera una xbox...
pd/ot: ¿sigues escribiendo el juego de "trenes"?
Pues sí, gracias a la gran ayuda de hikoki, por cierto. Lo que pasa es que se me ocurrió una idea de cómo hacer un scroll en alta resolución y ya me lié.
Pero en cuanto consiga esto, lo retomo. Ya tengo hechos diez niveles. Espero que para después de verano esté acabado.
antoniovillena escribió:Te ha quedado muy bien, conseguir un scroll de 24 caracteres de ancho a 50fps es todo un mérito. Yo creo que le queda poco para ser viable. Optimizando la rutina de sprites puedes conseguir más altura en la zona jugable (16 ó 18 caracteres) o tener más en pantalla, pero vamos que 5 sprites está bien para cualquier juego.
antoniovillena escribió:Te muestro el código del bucle principal del Cobra, la columna de la derecha son los ciclos.
El primer call ($9f94) sincroniza con el ciclo cero (lo hace vía interrupciones cambiando el bit 7 del registro R). El call $95fe es el que se sincroniza con el borde superior. Justo el call que viene después $9c8a es el que vuelca el fondo ya scrollado. Dos calls más abajo, $9ae3, es donde se pintan los sprites. El resto no nos importa demasiado porque no se pinta en pantalla. Como acabo en el ciclo 23341 en realidad he usado 1 frame y un tercio del siguiente, esto puede ser porque cuando he depurado el personaje está parado y no hay que rotar los tiles para el scroll, o que hay pocos enemigos, no lo sé.
El caso es que aunque uses 25fps, el haz de electrones va igual de rápido, por lo que tus rutinas de volcado de scroll+pintado de sprites deben consumir menos de un frame, y al acabar el pintado de sprites no debes superar los 14300 ciclos si no quieres que haya parpadeo. En la práctica puedes acabar por debajo de este valor siempre y cuando todos los sprites se pinten antes de que pase el haz de electrones (si lo pintas por orden de cordenada Y de arriba a abajo puedes acabar a la altura del sprite más bajo)
hasta acabar de pintarlo. En realidad hay 2 formas distintas de codificar un mismo sprite, en una de ellas empiezo una línea antes con la máscara a cero. Como pinto líneas de 2 en 2 en algunos casos se dan bytes a máscara cero que no puedo evitar, no pasa nada. Cuento los bytes de las 2 formas de codificarlo y me quedo con el que ocupe menos (casi seguro será también la forma más rápida de pintarlo). antoniovillena escribió:Si te sirve de ayuda para mejorar tu rutina de pintado de sprites, te comento la forma en la que yo lo hice en mi engine. Se trata de pintar lo justo pero sin gastar ciclos de más intentando ahorrar, es decir, tienes que llegar a un término medio. Yo llegué a ese termino medio generando los sprites rotados con un programita en C que me analizaba las máscaras y me generaba las 8 versiones rotadas del mismo sprite. Si un byte del sprite tiene la máscara a $FF no me molesto en pintarlo, me lo puedo saltar puesto que ahí no hay nada que pintar. Hay una optimización posible para sprites más grandes en los que con máscara $00 puedes copiar directamente el byte, saltándote el AND y el OR, pero para 16x16 se da en muy pocos casos la máscara $00, con lo que gastaríamos más ciclos tratando de optimizar de esta forma.
El recorrido del sprite lo hago de izquierda a derecha, luego bajo y luego regreso de derecha a izquierda. Luego repito este proceso (pintado de dos líneas) las veces que sea necesario (hasta
Otra ventaja de esto es que la comprobación que se hace después del INC H no hay que hacerla todas las líneas, sino que se hace cada 2 líneas, ya que sabemos que en las líneas pares basta con incrementar para ir a la siguiente línea. El código fuente está aquí:
https://github.com/DSkywalk/fase/tree/master/engine
Pero no te recomiendo que lo leas, es mejor que lo intentes por tí mismo con lo que te he dicho. A parte que mis rutina es más lenta porque aparte de pintar el sprite guarda el fondo que hay detrás (para que el borrado de después sea más rápido).
climacus escribió:Hay una cosa que no veo muy clara con lo de no pintar los gráficos con máscaras $FF. Te ahorras ciclos si te encuentras algunas, pero si no, sumas los ciclos de la comprobación. No crees que en la gran mayoría de las veces no va a haber máscaras con $FF? A mí me salen cuando el sprite está en rotación cero y alguna línea por ahí del sprite que no tenga gráfico. Pero no sé si sale muy a cuenta. Los sprites tienen más probabilidades de estar rotados que sin rotar y si tienen muchas líneas del gráfico a cero es porque son pequeños (p.e. una bala).
He comprobado el asunto y mi rutina tarda unos 3400 ciclos en imprimir un sprite.
Comprobando si la máscara es $FF, me tarda unos 400 más. Es cierto que mi sprite no tiene líneas $FF... y lo he probado con el sprite en estado de rotación
De todas formas, me parece muy interesante y lo tendré en cuenta.
Otra cosa que no veo es por qué guardas el fondo de los sprites, si en cada frame dibujas todo el fondo entero.
Miraré la forma que dices de guardar los sprites, que también parece chulo.
Muchas gracias.
antoniovillena escribió:
Por eso te digo, que hay veces que el overhead que introduces es mayor que los ciclos que te ahorras, todo depende de cómo lo implementes.
En mi caso la comparación de las máscaras con $FF lo hago desde el generador de sprites (programita en C), vamos que el Z80 no tiene que comprobar nada, solamente pintar. El overhead que se introduce es una serie de contadores que van en el mismo stream de bytes/máscaras, pero es mínimo. Digamos que tengo 3 rutinas distintas de pintado, una que me pinta 2 líneas de ancho 1 bytes, otra de ancho 2 bytes y la última de ancho 3 bytes (con sprites de 16x16 es lo máximo que necesito). Lo que tengo que codificar en cada grupo de 2 líneas es cuál de estas 3 rutinas voy a usar y cual será el offset a aplicar (entre 4 posibles) para las siguientes 2 líneas.
Si lo necesitas te explico exactamente el formato que uso y te separo la parte de C que genera los sprites rotados partiendo del PNG con sprites/máscaras. Con eso te daría para unos 12 sprites (supongo que quedará entre 2000-2500 ciclos, la actual tiene 3000 pero contando que guardo los bytes del fondo, y eso tú no lo necesitas).
Código: Seleccionar todo
drawl pop de
ld a, (hl)
dec bc
ld (bc), a
and d
or e
ld (hl), a
inc l
pop de
ld a, (hl)
dec c
ld (bc), a
and d
or e
ld (hl), a
inc h
updpaint
pop de
ld a, (hl)
dec bc
ld (bc), a
and d
or e
ld (hl), a
dec l
pop de
ld a, (hl)
dec c
ld (bc), a
and d
or e
ld (hl), a
inc h
dec ixl
jr nz, drawl
Código: Seleccionar todo
drawl 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
updpaint
pop de
ld a, (hl)
and d
or e
ld (hl), a
dec l
pop de
ld a, (hl)
and d
or e
ld (hl), a
inc h
dec ixl
jr nz, drawl
Código: Seleccionar todo
MACRO updpaint
ld a, h
and $07
jp nz, .upd&$ffff
ld a, l
add a, $20
ld l, a
jr c, .upd
ld a, h
sub $08
ld h, a
.upd
ENDM
antoniovillena escribió:No uso Seven Up, trabajo directamente con archivos PNG, con GIMP, pero se puede usar cualquier herramienta tipo Photoshop. Te he aislado el archivo que te convierte de png a binario, si lo quieres compilar bájate lodepng.c y lodepng.h de esta web. Cuando smooth es 0 se generan 4 rotaciones por cada sprite, si es 1 se generan 8.
Pincha aquí para bajar el archivo
El código Z80 te va a ser más complicado de descifrar porque contiene mucho código condicional, lo mejor es que te mires la demo y vayas depurando bajo emulador. No obstante el código que te imprime los sprites va desde draw9 hasta draww en este archivo:
https://github.com/DSkywalk/fase/blob/m ... engine.asm
A modo de ilustración, esta es la parte que imprime 2*ixl líneas para un ancho de 2 bytes:Código: Seleccionar todo
drawl pop de
ld a, (hl)
dec bc
ld (bc), a
and d
or e
ld (hl), a
inc l
pop de
ld a, (hl)
dec c
ld (bc), a
and d
or e
ld (hl), a
inc h
updpaint
pop de
ld a, (hl)
dec bc
ld (bc), a
and d
or e
ld (hl), a
dec l
pop de
ld a, (hl)
dec c
ld (bc), a
and d
or e
ld (hl), a
inc h
dec ixl
jr nz, drawl
Quitándole la parte que almacena el fondo, se quedaría así:Código: Seleccionar todo
drawl 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
updpaint
pop de
ld a, (hl)
and d
or e
ld (hl), a
dec l
pop de
ld a, (hl)
and d
or e
ld (hl), a
inc h
dec ixl
jr nz, drawl
Ah, y updpaint es esta macro:Código: Seleccionar todo
MACRO updpaint
ld a, h
and $07
jp nz, .upd&$ffff
ld a, l
add a, $20
ld l, a
jr c, .upd
ld a, h
sub $08
ld h, a
.upd
ENDM
Usuarios navegando por este Foro: Amazon [Bot], Google [Bot] y 24 invitados