¿Cómo se hace frameskip en Turbo BASIC?

Página 1/2
| 2

Por AxelStone

Prophet (2956)

Imagen del AxelStone

30-01-2015, 20:38

Buenas señores, esa es mi pregunta: ¿cómo se puede hacer frameskip en Turbo Basic? Tengo un problema, en determinadas circunstancias el juego que estoy haciendo excede la capacidad máxima de dibujado del VDP (4096 pixels por frame) y me gustaría que hiciera frame skip, es decir que usara 2 ciclos de reloj para procesar ese frame. ¿alguien que me pueda ayudar?

Gracias!

Login sesión o register para postear comentarios

Por Kai Magazine

Paragon (1373)

Imagen del Kai Magazine

30-01-2015, 21:49

No se si es lo que pides (porque no entiendo bien lo de que use 2 ciclos de reloj para procesar un frame) pero un frame skip se puede hacer de 2 maneras:

Por una parte tenemos toda la rutina lógica y matemática, que calcula la posicion de todos los graficos y personajes, tras procesar sus rutinas de movimiento y demas.

Por otra parte tenemos las subrutinas de dibujados de graficos; fondo, scroll, personajes, marcadores...

Si ambas están bien independizadas, puedes saltarte fotogramas de las siguientes maneras:

1- hay una funcion en basic para hacer multi tarea. Creo que es "on time gosub" pero no recuerdo ahora mismo. La usé en no name y nuts para hacer animaciones de colores o escritura de texto mientras el programa sigue en la rutina principal, pero se puede usar para que vaya a la rutina "matemática" cada cierto tiempo, y luego ir a las subrutinas graficas cuando la VDP haya terminado el fotograma anterior.
El resultado es como en los antiguos emuladores en los que, en un ordenador mas potente, o en una parte menos pesada del juego, el juego va mas suave, y en un ordenador menos potente o en una parte del juego muy pesada, va muy brusco, se salta muchos fotogramas, aunque la velocidad "matemática" es la misma (va mas brusco, pero no se relentiza).

2- El siguiente metodo tiene 2 variantes. Se trata de deducir matemáticamente (por la cantidad de personajes en pantalla o tareas graficas a realizar) si el siguiente fotograma será muy pesado o no, y entonces decidir si:
saltarte un fotograma (no ir a la rutina de dibujado en el siguiente ciclo) o aumentar la velocidad de toda la accion (puedes tener una variable "V" para definir la velocidad standard, y aumentarla y reducirla proporcionalmente para acelerar la accion sin necesidad de repetir todo el ciclo matematico (con su correspondiente consumo de tiempo) para luego dibujar el siguiente fotograma.

Esta última opcion de la segunda variante tiene la ventaja de que nos ahorramos repetir la rutina lógica, con lo que ganamos velocidad en el z80.
Este es el método que estoy usando para el motor de Action RPG tipo "secret of Mana".

Espero que te sirvan las ideas.

Un saludo y ANIMO!

Por Warchild

Paragon (1280)

Imagen del Warchild

31-01-2015, 01:57

Ese exceso de datos a copiar, ¿es poco, mucho, se puede dar en varios frames consecutivos?

Sin saber cómo lo estás haciendo ahora es un poco más difícil afinar. A ver si algo te sirve:

Una opción (que me "invento" porque saber no sé) quizá sería usar una interrupción de línea en la parte baja de la pantalla y empezar ahí el trabajo del VDP con las copias que van a la parte alta de la pantalla. Por así decirlo, sería como estirar un poco el vblank. Si aun va apurado, no actualizar marcador en ese frame. Pero habría que saber cuanto tiempo se comen las rutinas no gráficas para mirar de encajarlo todo lo mejor posible. ¿Tienes alguna referencia?

Puedes probar una cosa:
Al iniciar esas rutinas cambia el color del borde y cuando finalicen vuelve a cambiarlo. Creo que era así, de esta forma puedes ver en pantalla el tiempo que cosumen. Si ves que sobra, pues pal bote!

Por AxelStone

Prophet (2956)

Imagen del AxelStone

31-01-2015, 10:06

Hola señores, gracias a ambos por las respuestas. En determinados fotogramas llego a dibujar el doble, 8000 pixeles, de ahí el interés en usar justo 2 ciclos. Curiosamente lo primero que pensé fue la que Kai llama solución 2, una especie de frameskip programado de modo que en función de la carga en pantalla me salto la rutina de dibujado de algunos elementos (habia pensado en los más alejados, los que no provocan riesgo de colisión). Mira lo del cambio de color del borde no había pensado, aunque como te digo es el VDP el que va quemadillo casi seguro, la CPU sigue soportando lógica.

Aún así sería curioso ver si algún gurú sabe alguna rutina mágica que haga saltarse el ciclo actual a la CPU y aterrizar en el siguiente, básicamente que el frameskip lo haga el sistema.

Voy probando y os comento. Gracias nuevamente!

Por Warchild

Paragon (1280)

Imagen del Warchild

31-01-2015, 10:41

Y esa rutina mágica... ¿no sería un simple HALT?

Algo así:

-Rutinas de cálculo
-Compruebo si necesito 2 frames
No 》HALT 》Copia 4000 》GOTO Rutinas de cálculo
Sí 》HALT 》Copia 4000 》HALT 》Copia 4000+ 》GOTO Rutinas de cálculo

Si no entiendo mal, HALT es "no hacer nada hasta la siguiente interrupción" (explicao a mi manera), que sería la del vblank. Es decir, te situa al inicio del vblank. ¿O voy muy perdido? (que puede ser...)

Por AxelStone

Prophet (2956)

Imagen del AxelStone

31-01-2015, 14:07

Mmmm muy interesante lo que comentas, lo que pasa es que en verdad eso viene a ser ralentizarse en verdad no? Es decir en verdad he usado 2 ciclos para el dibujado a costa de dejar el juego congelado. Pero vamos los tiros van por ahí...

Ahora mismo ando experimentando con el sistema ese dinámico, lo que pasa es que es jodidillo por el tema del doble buffer, a veces quedan frames colgados que se han pintado en un buffer y no en el otro. En fin como todo supongo que es comerse el tarro...

Por Warchild

Paragon (1280)

Imagen del Warchild

31-01-2015, 19:18

A ver, es que si no haces el HALT te empezará a hacer las copias extras fuera de vblank y verás cositas feas en la pantalla. Y te iría con tirones bruscos ya que ni tardará siempre lo mismo en copiarlo todo ni empezará las copias en vblank. La única opción que veo para lo que pides sería prescindir de la bios, algo que no creo que pueda ser usando Basic... y lo que en realida pides es forzar el vblank (y yo creo que el vdp tiene su timing y el vblank llega cuando llega... si no no nos sincronizaríamos con él si no que le sincronizaríamos a él con nosotros jeje)

No dejas el juego congelado durante dos ciclos:

Ciclo 1: Rutina gráfica - rutina matemática - comprobar necesidad de frames - HALT

Si no necesito el segundo frame, el ciclo 1 se repite.

Si necesito segundo frame:

Ciclo 2: Rutina gráfica extra - rutina matemática - comprobar necesidad de frames - HALT

Y así forever... De esta forma sigues haciendo tus rutinas de cálculo tras la copia extra y el juego continúa normalmente.

Piensa que HALT no salta un frame entero si no lo que queda del frame actual. Te permite sincronizar con vblank, que es cuando quieres hacer las copias. Y tras hacerlas, sigues. Fácil, constante. No veo mayor complicación (preocupante que lo vea tan fácil... pero es lo que veo).

Los gráficos irán a dos frames sólo cuando sea necesario pero no pierdes la ejecución de las rutinas del juego... creo que es lo que necesitas.

'I# &H76

HALT! Es mi apuesta Smile

Por AxelStone

Prophet (2956)

Imagen del AxelStone

31-01-2015, 19:46

En el foro inglés han dado una solución curiosa basada en Time, échale un ojo Wink. Lo que mencionas de los altibajos de velocidad ahroa que lo mencionas era muy habitual en los juegos japoneses tipo Valis 2 o Ys 3, ¿no sincronizaban la pantalla o qué?

Por Kai Magazine

Paragon (1373)

Imagen del Kai Magazine

31-01-2015, 19:51

Si, warchild, esa opcion es parecida a la opcion 2-1 que doy mas arriba, pero con un añadido de pausa, que a efectos prácticos relentizará la accion en ciertas ocasiones (halt = pausa) cuando con "on interval gosub" el juego siempre va a la misma velocidad (a pesar de los fps) pero el problema es que se repite la rutina matemática, sobrecargando el z80.
Por eso vuelvo a insistir que, (a menos que no sea factible por el juego que intentas hacer, que no tengo ni idea, pero cuando mencionas objetos lejanos y cercanos, me imagino un "penguin adventure"), el sistema que optimiza mejor los recursos del msx (tanto z80 como vdp) es la opcion 2-2, una variable que aumente y reduzca la velocidad "matemática" del juego en base a una prediccion del tiempo de ejecucion del siguiente fotograma.

Esta opcion no es valida para un "penguin adventure" o similar, pero si para muchos otros motores graficos.

Lamentablemente no creo que pueda aportar una solucion mas detallada sin conocer la naturaleza del juego y entender la lógica que implica su rutina matematica y grafica.

Si quieres mandame un privado con los detalles esenciales para poder asesorarte mejor.

Saludos!

Por Warchild

Paragon (1280)

Imagen del Warchild

31-01-2015, 20:14

Observación sobre la "pausa". Esa "pausa" se hace cuando YA ESTÁ TODO HECHO. Es decir, he mirado teclado, hecho todos los cálculos y tengo todo listo para volcar gráficos. NO PIERDES NADA EN TU EJECUCIÓN. Si como dice AxelStone, la rutina de juego va sobrada, no hay problema. Si esta rutina te pisa el vblank, cagada. Pero le sobra tiempo. Si no tienes nada más que hacer en ese tiempo (porque ya está hecho) lo único que te queda por hacer es esperar el vblank para ejecutar la rurina gráfica. No hay "pausa", hay "no tengo trabajo", que no es lo mismo...

Sin más detalles no se puede afinar más, pero lo que dice es que vuelca 4000 bytes por frame y necesita volcar 8000 en dis frames. Sigue el hilo de ejecución que propongo y dime dónde dejas de hacer lo que se necesita. Está todo. No está buscando la forma de meter todo en un frame. Dos. Pues ahí están. Sin complicaciones.

Problema de ON INTERVAL GOSUB: ¿Por qué me ha de interesar que algo se ejecute cada X tiempo si YA LO ESTOY EJECUTANDO EN CADA FRAME? ¿Y de verdad quiero interrumpir una rutina gráfica? ¡Pero si para lo demás me sobra tiempo!
¿Y no tendré las interrupciones deshabilitadas durante el vblank? En fin, que no veo lo útil en este caso de usar ese sistema. Siempre te interesa ir al frame, no al segundo. Porque el vblank no va al segundo.

Por Kai Magazine

Paragon (1373)

Imagen del Kai Magazine

31-01-2015, 20:24

Correcto, estoy de acuerdo en eso Warchild.
Todo depende del motor que esté haciendo y de como lo esté haciendo.
No digo que la opcion "on interval gosub" sea la mejor.
Está genial para juegos que usan pequeñas subrutinas de estabilidad, que van sobrados de velocidad, y sobretodo usando Sprites, ya que te aseguras de que el protagonista vaya siempre a la misma velocidad (konami lo usa en muchisimos de sus juegos) pero no es factible para un juego con muchos copys.
Por eso digo que se tiene que usar con cuidado, y que depende del tipo de juego.
Para un juego hecho con copys, y con una rutina matemática pesada, insisto que, el sistema que optimiza mejor los recursos del msx (tanto z80 como vdp) es la opcion 2-2, una variable que aumente y reduzca la velocidad "matemática" del juego en base a una prediccion del tiempo de ejecucion del siguiente fotograma.

Página 1/2
| 2