Organizar datos gráficos en vram... necesito consejo

Paragon (1297)

23-03-2015, 19:36

Estoy iniciando un proyecto de juego en ensamblador para MSX2 y tengo algunas dudas sobre qué distribución me conviene más para almacenar los gráficos en vram. Espero que me podáis aconsejar.

Teniendo en cuenta lo que se puede ver por ahí, pensaba que mi proyecto no sería muy exigente en lo que a velocidad gráfica se refiere. Os explico:

Básicamente se trata de actualuzar dos áreas de 48x32 píxeles y las posiciones de los sprites hardware.
Así pues serían 768 + 768 + 128 bytes = 1664 bytes.
¿Entrarían estas tres copias en V-blank? Tras repasar algun artículo sobre comandos vdp, tengo dudas sobre cuánto puedo meter en vblank. A 60Hz he visto cifras de unos 3500 bytes con el comando HMMM. Pero creo que esta cifra se refiere a un frame completo, no solo al vblank. ¿Es así? Si alguien me pudiera aclarar un poco esto, porque estoy hecho un lío... no quiero ponerme a programar algo que luego no se pueda mover, así que me gustaría tener clara la organización de los gráficos antes que nada.

By MsxKun

Paragon (1100)

27-03-2015, 00:21

Amos a ver, pero en que Screen?
Por tus números, Screen 5? Si es asi dos areas de 48x32 casi mejor copiarlas usando comandos del VDP, no copias directas a VRAM.
En todo caso, da para poquito. Muy poquito si quieres hacer algo que se mueva bien, 50 o 60hz. Porque si te conformas con unos patéticos 12 fps, en lugar de un juego tendras un SOPOR que será un suplicio intentar jugarlo y durará 30 segundos en el MSX hasta que se pulse el botón de Switch Off.

Casi mejor da detalles sobre qué ha de moverse y cúando y porqué, ya que dependerá de ello que te convenga más hacer unas cosas de una forma u otra, aunque ambas no diferirán demasiado si quieres no estirar más el MSX de lo que puede dar.
Y, ante la duda, haz la prueba. Pon el color del borde a un color justo al entrar en el vblank y antes de las copias, haz las idems, y vuelve a dejar el color del borde como estaba. Veras lo que te dura la copia y si te entra o no.

By assembler

Champion (404)

27-03-2015, 16:35

Si trabajas con doble buffer, no necesitas apurar, tendras todo el frame completo para dibujar, y solo tendrás que hacer un cambio de página visible en cuanto salte el vblank.

By AxelStone

Prophet (3105)

28-03-2015, 12:16

MsxKun wrote:

Porque si te conformas con unos patéticos 12 fps, en lugar de un juego tendras un SOPOR que será un suplicio intentar jugarlo y durará 30 segundos en el MSX hasta que se pulse el botón de Switch Off.

Jo le teneis la guerra declarada a los fps. No olvidemos que es un ordenador de 8bit, con limitaciones importantes y que no siempre es posible tanta fluidez. Por mencionar algún peso pesado, ningún juego de Konami (repito, NINGUNO) funciona a 60fps, todos corren de 30fps para abajo. Y muchos de los mejores juegos de MSX (RPGs sobre todos) funcionan a pellizcos pero mire usted, Xak me encanta.

Lo que si me parece tremendo es hacer un arcade que se mueva a saltos, tipo Valis 2, se supone que la jugabilidad debe ir por encima de todo en este género.

By Warchild

Paragon (1297)

29-03-2015, 14:54

Gracias por vuestra ayuda

Es en Screen 5, sí. Olvidé indicarlo.
La intención es conseguir 60/50 fps. En el peor de los casos sé que podría hacerlo funcionar a 30/25 fps. Eso me daría margen para adornarlo un poco a cambio de sacrificar esa velocidad. Más lento que eso significaría que estoy haciendo muchas cosas mal.

Se trata de actualizar en cada frame dos áreas de 48x32 píxeles.
Para restaurar el fondo necesitaría hacer dos copias más del área a restaurar.
También usaría sprites hardware, en cada frame se copiarían los 128 bytes de atributos.

Con el cambio de color de borde comprobé que el vblank no es el paraíso que yo soñaba Es lo que tiene pasar de la teoría a medio entender con la práctica chapucerilla... pero avanzo

Con la recomendación de assembler de usar doble buffering la cosa cambia bastante. Aunque toca reservar una página de video. Veamos si tengo claro como sería:

Tengo dos fondos: página 0 y 1. En las otras dos, los sprites software.
Para empezar, copio los sprites a pag 0 y la muestro.
Mientras la muestro, copio los sprites en su nueva posición en la página 1.
En vblank cambio a página 1
Mientras muestro la página 1, restauro el fondo de la página 0.
Copio los nuevos sprites a la página 0.
En vblank cambio a página 0.
Y repetir...

¿Necesitaría además de dos páginas, reservar una zona para guardar el fondo que tendré que restaurar, no?
¿Estoy entendiendo bien cómo hacer doble buffer?

Algunas cosas con las que veo que puedo ganar velocidad:

Sprites: Solo los necesitaría entre las lineas 104 y 170 más o menos. Fuera de ahí puedo desactivarlos.
Pantalla: 192 px de altura. Puedo reducir el area y tener la pantalla activa por ejemplo solo entre las líneas 16 y 180. Pero sobre esto no sé si gestionar cada interrupción de linea no se comería ya lo que pueda ganar. Tampoco tengo claro si desconectar pantalla influye en algo cuando las copias son en la zona no visible.

De momento, estoy llegando a hacer 3 copias de 48x32 + copiar atributos de sprites hardware. Aun sobra algo pero si con esto es suficiente, aun me daría para algun cambio de paleta o redefinir algun sprite sin problemas.

Ahora para las pruebas estoy esperando a que el vdp termine de ejecutar el comando para hacer la siguiente copia, pero entiendo que lo que debo hacer es darle trabajo a la cpu mientras el vdp está ocupado. Supongo que puedo ir añadiendo código y mirando cada tanto si el vdp ha terminado hasta acotar una "zona de seguridad" en la que sé que no podré usar el vdp. ¿Voy bien?

Tambien tengo que pensar en la mejor forma de restaurar el fondo para no cargar el vdp a lo tonto... a ver si atino un poco...

By AxelStone

Prophet (3105)

29-03-2015, 21:58

Un ejemplo vale más que 1000 palabras, el compañero assembler lo explicó perfectamente en los foros de Karoshi:

10 SCREEN 5
20 SET PAGE 2,2
30 CLS
35 REM INICIALIZAMOS EL SPRITE, ASEGURANDO QUE LO QUE NO ES SPRITE, TIENE COLOR 0
40 LINE (0,0)-(15,15),0,BF
50 FOR A=0 TO 7
60 CIRCLE(7,7),A,A
70 NEXT
75 REM CREAMOS UN FONDO TO GUAPO
80 SET PAGE 0,0
90 FOR A=1 TO 100
100 LINE-(RND(1)*255,RND(1)*212),RND(1)*8+7
110 NEXT
115 REM Y LO COPIAMOS EN LA PAGINA 1
120 COPY (0,0)-(255,212),0 TO (0,0),1
130 REM INICIALIZAMOS LAS VARIABLES
140 P=0
150 XB(0)=-1:YB(0)=-1
160 XB(1)=-1:YB(1)=-1
165 REM EMPIEZA LO BUENO
170 SET PAGE 1-P,P
175 REM EN EL PRIMER FRAME DE CADA PAGINA, NO RESTAURAMOS EL FONDO
180 IF XB(P)<>-1 THEN COPY(16+16*P,0)-(31+16*P,15),2 TO (XB(P),YB(P)),P
185 REM LEEMOS EL CURSOR Y ACTUALIZAMOS X E Y EN CONSECUENCIA
190 D=STICK(0)
200 X=X-(D=2)-(D=3)-(D=4)+(D=6)+(D=7)+(D=8)
210 Y=Y-(D=4)-(D=5)-(D=6)+(D=8)+(D=1)+(D=2)
215 REM HACEMOS COPIA DEL FONDO
220 COPY (X,Y)-(X+15,Y+15),P TO (16+16*P,0),2
225 REM DIBUJAMOS EL SPRITE 
230 COPY (0,0)-(15,15),2 TO (X,Y),P,TPSET
235 REM ACTUALIZAMOS LA X E Y DE COPIA DEL FONDO
240 XB(P)=X
250 YB(P)=Y
255 REM CAMBIAMOS LA PAGINA ACTIVA POR LA VISIBLE
260 P=1-P
265 REM PARA VER EL ESTADO DE LA PAGINA DE TRABAJO, CON ESPACIO
270 IF STRIG(0)=-1 THEN GOSUB 290
280 GOTO 170
290 SET PAGE 2
300 IF STRIG(0)=-1 GOTO 300
310 SET PAGE 1-P,P
320 RETURN

No necesitas guardar el background ya que se guarda justo el recuadro ocupado por el sprite y luego se restaura. Lo único sí, necesitas como VRAM de trabajo el doble de lo ocupado por el sprite, para almacenar el background de la P0 y P1. Me explico, si tu sprite es de 32x32 guardarás alternativamente en VRAM el background de P0 y P1 (las páginas con las que estamos haciendo el doble buffer), en ese código BASIC viene muy bien explicado.

By assembler

Champion (404)

29-03-2015, 22:11

Lo importante del asunto es tener en cuenta que cada sprite tendra unas coordenadas en cada pagina. Imagina un sprite que se mueve en diagonal abajo a la derecha desde 0,0
En el primer frame, pagina 0, copiamos el fondo de 0,0 y ponemos el sprite en 0,0
En el siguiente frame, pagina 1, copiamos el fondo de 1,1 y colocamos el sprite en 1,1
Al tercero, restauramos el fondo en 0,0, copiamos el fondo de 2,2 y ponemos ahi el sprite
Cuarto: restauramos en 1,1, copiamos de 3,3 y ponemos el sprite

Solo hay que considerar el caso inicial en el que no restauramos el fondo.

AxelStone, ni me acordaba de haber publicado ese codigo, y eso que no hace tanto tiempo...

Si tenemos varios sprites, hay que restaurar el fondo de todos los sprites, leer el fondo de cada sprite y dibujar todos los sprites.

By Warchild

Paragon (1297)

31-03-2015, 04:48

Ese listado va a ser una buena guía para mí. He pensado aprovechar que por las características del juego no necesito toda una página para el fondo. La acción se reduce a un área de 256x96 en la parte baja. Así que puedo tener en la página 0 la pantalla de juego con el marcador en la zona superior. En la página 1, una copia del fondo a partir de la linea 96 más otra copia de la zona de 256x96. En la linea 96 cambiaría de página y mostraría el fondo correspondiente en cada frame. Para restaurar el fondo usaría la copia extra de la zona de 256x96. Así no tendría que guardar el fondo antes de dibujar el sprite.

Ahora me toca controlar el tema de las interrupciones. He hecho alguna prueba pero de momento no me sale ni media... a ver si durante la semana soy capaz de usar interrupciones, con eso ya casi estaría listo el motor gráfico.

By MsxKun

Paragon (1100)

04-04-2015, 21:57

AxelStone wrote:

MsxKun wrote:

Jo le teneis la guerra declarada a los fps. No olvidemos que es un ordenador de 8bit, con limitaciones importantes y que no siempre es posible tanta fluidez.

Es posible si se tiene en cuenta, precisamente, que es un ordenador de 8bits y se hacen las cosas en consecuencia.
Lo siento, me gusta jugar comodo y sin desesperarme.

AxelStone wrote:

Por mencionar algún peso pesado, ningún juego de Konami (repito, NINGUNO) funciona a 60fps, todos corren de 30fps para abajo. Y muchos de los mejores juegos de MSX (RPGs sobre todos) funcionan a pellizcos pero mire usted, Xak me encanta.

Konami no eran de los mas pulcros en esos temas Existen mas cosas que Konami. De todas formas si alguien hace algo a la altura de algunos konamis y va a 30fps me dara lo mismo. Pero si va a menos me cagare en todo porque arruinar un juego prometedor por una experiencia de jugabilidad ruinosa seria una lastima.

En un juego de rol hay algo mas de manga ancha, pero si es muy lento, por bueno que sea, el ordenador sera apagado por aburrimiento, bastante antes de poder ver lo bueno que es.

AxelStone wrote:

Lo que si me parece tremendo es hacer un arcade que se mueva a saltos, tipo Valis 2, se supone que la jugabilidad debe ir por encima de todo en este género.

Gran ejemplo de lo que decia.

By MsxKun

Paragon (1100)

04-04-2015, 22:04

Warchild wrote:

Con el cambio de color de borde comprobé que el vblank no es el paraíso que yo soñaba

No lo es, no

Pero bueno, aun con todo eso, se pueden hacer cosas. Animo. Y, si has de elegir, ante todo que sea divertido.

By MsxKun

Paragon (1100)

04-04-2015, 23:16

Con todo lo anterior digo que:

- Primero, que sea divertido (hacerlo, jugarlo).
- Segundo. Antes de programar nada, ya has de pensar que necesita tu juego y como vas a afrontarlo. Elegir modo de pantalla, generacion, etc. Al empezar, al no tener todavia la experiencia para aplicar el criterio, pues se hace todo un poco a la vez, pero asi se aprende tambien Piensa que necesita tu juego y que no. Si te es imprescindible SC5 o te apañas en SC4, si esos copys que has de hacer han de ser de ese tamaño o pueden ser menores. Si, de necesitarlos, tal como te dicen, te apañas con un doble buffer y a 30fps (respetanto que siga siendo divertido) o no. O si esos 30fps se van a limitar al copy pero los sprites hardware pueden seguir yendo a 60fps. Etc.
- Tercero. Si empiezas, no te compliques, haz las cosas facil Ya tendras tiempo de liarte.
- Cuarto. Me remito al punto 1

Al final todo depende de como quieres que sea el juego y a quien va dirigido.