Lo que se suele hacer para controlar la velocidad es el tiempo sobrante de nuestro codigo esperar a la interrupcion VBLANK que ocurre cuando se ha dibuja toda la pantalla, 60 veces por segundo en NTSC (60 Hz) o 50 en PAL... por lo que... nuestro juego irá a 60 o 50 fps.
Si no se controla la velocidad de esta forma, pasa como ocurria en los tiempos de los 286, que cuando ponias un juego antiguo en un 486 era injugable de lo rápido que iba. Otro problema es que nuestras rutinas sean muy exigentes y no den tiempo a esperar a la interrupcion sino que nos pasemos, por lo que el juego irá a menos fps, una ralentización vamos. SI nuestro juego vemos que continuamente está cayendo, podemos hacer que funcione a 30 fps o menos para que no veamos estos bajones, 30 pq simplemente es dividir por 2 la velocidad pero podrian ser 0, 15, 20... lo que nos de la gana. SI no hacemos esta espera, el juego se puede disparar mas de 100 fps tranquilamente si el codigo lo permite al no ser muy exigente con la cpu, aparte de ser una chorrada pq una tv nomral no emite tanta imagenes (una 100hz mas claro).
La super como tenia una cpu mas lenta es mas probables que veamos mas juegos a menos fps que en megadrive o neogeo por ejemplo.
EN el caso del oh mummy, el juego va a 60 fps en ntsc, 50 en pal, menos puntualemente en la esfinge con agua (raster de practicamente toda la pantalla) que baja a unos 50 en ntsc... en pal como ya está a 50 no se nota.
Espero haberme explicado xD