¿Cómo se hace frameskip en Turbo BASIC?

Página 2/2
1 |

Por Warchild

Paragon (1280)

Imagen del Warchild

31-01-2015, 20:38

No digo que dijeras que fuera la mejor opción, solo que es una opción que en este caso complicaría la cosa y es innecesaria porque la rutina de juego tiene tiempo, no necesito excluir nada en ningun frame. Solo controlar si en ese frame me toca hacer una copia extra o no, solo varía la parte gráfica. El resto se ejecuta enteramente igual necesites copia extra o no.

Diría que la opción apuntada en el foro en inglés con TIME es equivalente a HALT. Es decir, hasta que no acabe el frame, no hace nada. Podrías preguntarlo y salimos de dudas (más que nada porque escribir ' I# &H76 es más fácil que lo del if-then... vamos, por perrería pura XD)

Por AxelStone

Prophet (2956)

Imagen del AxelStone

31-01-2015, 20:39

No es un penguin adventure Wink . En principio estoy tirando de copys a piñón, no tenía grafista que se currara los sprites, así que ya tiro adelante con lo que hay Tongue . Mi idea es tener algo listo en los próximos meses, a ver si puedo enseñar algo.

Por osises

Master (237)

Imagen del osises

04-02-2015, 16:23

Hola a todos. No he programado nunca en TB, pero si mucho en MSX-Basic y otros dialectos de Basic.

La idea de utilizar on x gosub es muy buena en este caso. Me explico con un ejemplo teórico:

- Por un lado tenemos un bloque de código que se ejecuta ciclicamente. En este deben estar los cálculos que afectan a los cambios gráficos, cambios de sprites, redibujado de áreas gráficas, etc. Vamos, los cálculos matemáticos basicamente.
- En una subrutina, invocada con on x gosub, tenemos todo el código que hace efectivos los cambios gráficos, es decir, basicamente escritura a VDP.
- El truco está en el uso de on x gosub. El valor x se puede utilizar como un switch que direcciona el flujo del programa a la subrutina a la que apunta, dependiendo si queremos en un momento dado redibujar la pantalla o no. Por eso hay que crear una lógica, que sea muy liviana, que permita determinar si se dibuja, valor x=1 por ejemplo, o no se dibuja, x=0.

Con esto podemos tomar varios caminos. Uno, sencillo, consiste en alternar los valores cero y uno en la variable x, donde las veces pares tendrá 1 y en las impares 0. Con esto dibujamos la pantalla la mitad de veces. Si hace falta reducir el refresco más se pueden utilizar 3 ó más valores, depende de cada caso.

Otra técnica es la de contar tiempos de ejecución. Consiste en averiguar, un poco a ojo para no complicarse, cuanto tiempo es necesario que sobre para que la pantalla se redibuje con eficacia. Dicho de otro modo, hay que averiguar cuanto tiempo lleva todo el proceso, cálculo y dibujado, y determinar cuanto tiempo queda después de los cálculos para dibujar. Si queda suficiente tiempo se dibuja, x=1 en on x gosub; si no queda tiempo entonces no salta a la subrutina, x=0 en on x gosub, y repite de nuevo la tarea cíclica, es decir va otra vez al proceso de cálculo.

En esta segunda técnica se complica mucho todo. Por un lado, si no se redibujan los gráficos, sobrará tiempo que si no se ocupa con algo producirá una aceleración en el siguiente recálculo. Si en una segunda pasada se vuelve a determinar que no hay tiempo para escritura a VDP, evitar otra vez seguida (o varias) que no se actualicen los gráficos provocará saltos en las animaciones. Una forma un poco elegante de corregir esto es ir acumulando los tiempos que sobran para determinar si todos juntos son suficientes para el proceso de escritura a VDP. Esta técnica se puede afinar mucho en código máquina, aunque es una pasada el esfuerzo para ello, pero en Basic... no se, habría que probar.

Hay más técnicas que se pueden utilizar, que son variantes de estas. Por ejemplo se pueden utilizar las interrupciones del sistema, pero eso solo para código máquina.

Espero que os sirva como ejemplo práctico para lo que quereis implementar. Y ánimo, que todo tiene solución.

Por osises

Master (237)

Imagen del osises

04-02-2015, 16:54

Añado un detalle que no he explicado.

Cuando se trabaja con doble buffer, toda la tarea de saltar fotogramas se complica. Por un lado hay una primera fase en la que se actualizan los gráficos en la página no visible, es decir, se "construye" a base de cópias o movimientos de datos en la VRAM. El segundo paso consiste en copiar todo el contenido procesado a la parte visible, con la técnica adecuada en cada caso.

Pues bien, dependiendo de como funcione la técnica de programación implementada (cada autor es un mundo), podría no ser rentable saltarse la primera fase, ya que tendría efectos no deseados en los gráficos (basura en pantalla o áreas no redibujadas).

Por eso es muy recomendable ejecutar siempre la primera fase y verificar desde ahí si el tiempo sobrante permite la siguiente fase.

En otras ocasiones no hace falta, pero como digo depende cómo se ha creado la lógica de funcionamiento del programa para implementar los recursos necesarios y así evitar que se produzcan estos errores en los gráficos.

Saludos,

Oscar

Por AxelStone

Prophet (2956)

Imagen del AxelStone

05-02-2015, 23:07

Jo menuda currada te has dado Shocked! . En el foro inglés el compañero Kai expone lo del ON X GOSUB con un ejemplo práctico, la verdad es que la gente ha quedado contenta con el método. Yo al final he usado un camino más sencillo, he usado la implementación basada en TIME para ajustar la tasa a 30fps porque me interesaba Wink

Página 2/2
1 |