Siempre me ha sorprendido la serie Super Mario en Snes. Creo que se hizo principalmente en ensamblaje Z80. Pero como no había un reloj de tiempo real, ¿cómo demonios manejaron todos esos eventos sincronizados y animados con montaje y sin reloj de tiempo real?¿Cómo implementaron los deslizadores laterales clásicos los eventos temporizados y los desencadenantes de animación?
Gracias
Un concepto importante a tener en cuenta es la velocidad VSync. Esta es la frecuencia con la que el cañón de electrones del televisor (o el equivalente en los televisores modernos) termina de dibujar la pantalla, y viaja lentamente hacia la parte superior de la pantalla.
Debido a que esto sucede a una velocidad constante (60 veces/segundo en NTSC, 50 en PAL), la mayoría de los juegos utilizan como su temporizador, con código que es más o menos equivalente a esto:
void main() {
while(true) {
updateGame();
updateSprites();
waitForVSync();
}
}
Obviamente, esto está extremadamente simplificado, pero eso es lo que está pasando. Algunos juegos eran tan complejos que demoraron demasiado y pasaron por alto el período VSync. En ese caso, esperarían el segundo VSync, y por lo tanto funcionarían a 30 (/ 25) FPS.
A veces, notará que los juegos de NES se vuelven más lentos (por ejemplo). Esto es cuando la carga de trabajo es tan pesada que le faltan varios períodos VSync en un solo cuadro de acción.
Pero sí, eso es básicamente la forma en tiempo trabajó en las consolas mayores (En realidad, incluso muchas consolas más nuevas y juegos de PC utilizan el mismo sistema, no sólo viejas consolas!)
¿qué es esto 'moralmente equivalente' que sigues diciendo? No creo que signifique lo que piensas que significa. – JustJeff
Lo estaba usando de modo que "X es moralmente equivalente a Y" significa, aproximadamente, "X no es lo mismo que Y, y es probablemente bastante diferente, pero tiene un propósito similar". Después de investigar un poco, me doy cuenta de que lo estaba usando incorrectamente, por lo que lo editaré de mi respuesta. –
El Z80 soporta un número de alarmas de proceso - es posible uno de éstos estaba conectado a un temporizador periódico (por ejemplo, cada 10 ms.). Algunas consolas de juegos anteriores tenían un calendario relacionado con la actualización del escaneo de TV, por lo que es posible que se haya conectado. No conozco el SNES, así que estoy especulando sobre la base de cómo funcionaron otros sistemas contemporáneos.
wikipedia dice que el SNES era un sistema de 16 bits, por lo que no era un Z80, que es de 8 bits. En realidad dice que fue un 65C816
http://en.wikipedia.org/wiki/Super_Nintendo_Entertainment_System
(los anteriores enlaces habla de interrupciones de sincronización de vídeo, así que estoy probablemente en la dirección correcta Suponiendo que está correcta sobre el reloj de tiempo real)
Una técnica muy común utilizada en hardware antiguo era confiar en el mismo hardware de temporización utilizado para mostrar gráficos. El hardware antiguo literalmente transmite datos desde su puerto de gráficos (video compuesto, o más comúnmente RF) leyendo un valor de píxel de la memoria y colocándolo en el puerto, junto con algunas señales de 'sincronización', para controlar el cañón de electrones de escaneo en la televisión.
Lo bueno es que la señal de sincronización vertical, la que hace que la pistola oscile desde la parte inferior de la pantalla hacia la parte superior, generalmente está conectada a una interrupción de hardware en la CPU de la consola, y en ese momento , que ocurre exactamente 29,97 veces por segundo (casi 30 fps) ocurre en un momento en que no se envían datos a través del video, porque lleva cierto tiempo para que el rayo 'vuelva' a la parte superior de la pantalla. ¡Los cambios realizados en la memoria de video en ese momento serán sin parpadeo!
En la mayoría de los sistemas anteriores, no se hacía distinción entre campos pares e impares, por lo que la velocidad de cuadro de video era de aproximadamente 60Hz. También es interesante observar que en el Atari 2600, el procesador fue responsable de generar la temporización vertical, y las tasas de cuadros podrían ser superiores o inferiores a 60Hz, dentro de la tolerancia de un televisor. Uno de los chips (el "RIOT") incluía un contador descendente con un prescalar, que podía establecerse antes de ejecutar un fragmento de código que tardaría un tiempo incierto en ejecutarse, pero no hubo interrupciones. – supercat
Juegos, entonces como ahora, normalmente se ejecutan un ciclo de tiempo fijo (ver la respuesta de Mike Carons). Originalmente, esto era principalmente por conveniencia; su representación se sincronizó de todos modos con la frecuencia de actualización de la pantalla para evitar el desgarro, también podría ejecutar todo el procesamiento basado en el tiempo una vez por cuadro.
Hoy en día, la mayoría de los juegos avanzan en pasos discretos que son múltiplos de una frecuencia base, generalmente 50/60 Hz o algo así como 100 Hz; algunos títulos aún tienen sincronización VSync, pero la mayoría solo usa temporizadores regulares para esto ahora. Hoy en día usamos tiempos fijos por razones ligeramente diferentes: primero, los juegos tienen al menos cierta cantidad de simulación de física, y es muy difícil lograr una simulación física estable con tiempos variables, especialmente en aplicaciones en tiempo real como juegos, donde no puede arrojar fácilmente más potencia de cálculo mediante el uso de métodos de integración más precisos y similares. Segundo, si tienes cualquier tipo de modo multijugador en red de, debes asegurarte de que el juego permanezca sincronizado para todos los jugadores. Esto es casi imposible de administrar (y depurar) si todos están en un temporizador diferente y procesan eventos a un ritmo diferente. Obligar a todos a utilizar un paso de tiempo común hace que el problema sea más fácil de manejar en varios órdenes de magnitud, ya que puedes asumir que dos jugadores que comiencen en idéntico estado y reciban una entrada idéntica seguirán en idéntico estado 5 segundos después, incluso si los jugadores miran diferentes cosas o tienen máquinas diferentes, todo lo cual influye en la velocidad de fotogramas real en la que corre el juego (y, por lo tanto, también la velocidad a la que el juego puede procesar eventos).
No estoy seguro de lo que quiere decir con "reloj de tiempo real", pero las consolas que dependían del Z80 como procesador de propósito general también tenían hardware dedicado para animar sprites y reproducir sonidos. El Z80 solo estaba dando órdenes a estos. –
¡Me encantaría saber esto también! Siempre pensé que era más un "cuando X está aquí, Y hace esto" algo así. – James
Los juegos antiguos a menudo se sincronizan alrededor de la velocidad de cuadro de la pantalla en la que se ejecutan, por lo que actualizan sus sprites una vez por fotograma (es decir, 50hz o 60hz dependiendo de si es un sistema PAL o NTSC) – Laserallan