Vivimos en un universo audible. Aunque la principal orientación sensorial del Homo Sapiens hacia el mundo físico es visual, la especie no habría durado mucho sin la capacidad de oír cómo se partía repentinamente una ramita, y es poco probable que hubiera llegado a mucho si hubiera tenido que negociar tratados por correo escrito solamente. Los duelos entre naves en Star Wars no le habrían mantenido despierto por mucho tiempo si realmente se hubieran librado en un espacio silencioso. Tampoco jugaría mucho tiempo en su computadora personal si los sonidos que salen del altavoz fueran superfluos, irritantes o, por lo demás, deficientes.

El sonido es un ingrediente esencial. La combinación correcta de lo visual y lo auditivo hace que los buenos juegos sean buenos. Si va a escribir un juego para computadora personal, debe saber cómo quieres que suene y cómo lograr que suene de esa manera.

La mayoría de las computadoras requieren tiempo de microprocesador para la generación de sonido, ya sea mediante codificación en lenguaje ensamblador o una llamada de función a alguna rutina de sonido proporcionada por el sistema operativo. En ambos casos el problema es el mismo: el procesamiento de gráficos y las rutinas de cálculo deben detenerse mientras dure el sonido. Teniendo en cuenta el tiempo que esto añade a la ejecución del programa, no es de extrañar que el programa promedio arroje al usuario a un agujero negro cada vez que está ocupado.

El Sistema De Sonido Del Atari. Cuando la gente de Atari diseñó su sistema de computadoras domésticas, no simplemente metieron un microprocesador 6502 en una caja. También crearon tres chips de soporte -Antic, Ctia y Pokey- para compartir las funciones que normalmente proporciona el 6502 por sí solo. La versatilidad integrada en estos chips es tremenda; Tienen desplazamiento (scrolling) fino horizontal y vertical, control de luminancia del color, generación de sonido, movimiento de gráficos de player/missile y detección de colisiones, y una serie de otras operaciones de E/S diversas. En cada uno de ellos, los chips de soporte reciben sus instrucciones del 6502 y luego las llevan a cabo mientras el microprocesador pasa a tareas más esotéricas.

La generación de sonido es un buen ejemplo del poder inherente a este diseño. Pokey maneja cuatro canales de sonido programables de forma independiente, cada uno con sus propios registros de frecuencia, volumen y tono. Los programas pueden pasar el parámetro correcto a estos registros y el hardware continúa produciendo el sonido solicitado hasta que el programa le da instrucciones diferentes. Las técnicas de programación avanzadas pueden ampliar la gama de tonos disponibles, proporcionar una resolución de frecuencia más alta, insertar filtros de paso alto en los canales 1 y 2 y omitir completamente los generadores de tonos para crear formas de onda diseñadas a medida.

Sin embargo, muchas aplicaciones pueden ser manejadas adecuadamente por el intérprete del Basic de Atari.

La Instrucción SOUND. El Basic de Atari se comunica con Pokey mediante la instrucción SOUND C,P,D,V donde C,P,D y V son expresiones para los siguientes parámetros:

C: Canal de sonido. Las voces están numeradas del 0 al 3.

P: Tono. 0 es la frecuencia más alta, 255 la más baja. Las expresiones pueden ser superiores a 255, pero el tono «se ajustará» a ese límite.

D: Distorsión. Puede ser cualquier número par entre 0 y 14. 10 es una onda cuadrada pura y los otros números mezclarán la información de tono con varias cantidades de ruido. Los motores, las explosiones y el sonido del surf se pueden encontrar fácilmente experimentando con los parámetros de distorsión y tono.

V: Volumen. El más ruidoso es el 15; 0 apaga el canal. Esto no debe considerarse simplemente como una alternativa al control de volumen de su televisor: el control dinámico de un sonido a menudo puede generar sonidos radicalmente diferentes a partir de la misma forma de onda.

Dos cosas deberían ser evidentes inmediatamente acerca de este comando: no hay ningún parámetro de duración y solo puede hacer referencia a un único canal a la vez. Tener un parámetro de duración requeriría que el procesador se detuviera y contara la duración del sonido, que es lo que estamos intentando eliminar. El parámetro de selección de canal es una ventaja definitiva; con él podremos tener cuatro sonidos completamente diferentes al mismo tiempo, convirtiendo al Atari en un auténtico instrumento polifónico.

Llenando El Vacío. La tarea del Programa 1 es inicializar la popularidad de tres candidatos en una simulación de elección presidencial y proporcionar una subrutina que «sondeará» los estados y proporcionará la popularidad promedio de cada candidato. Esta subrutina se llama cada vez que el candidato hace un cambio significativo en su plataforma o en su estrategia de campaña.

El sonido producido durante la inicialización no es crítico; se proporcionó para confirmar que el programa está activo y funcionando. La subrutina, sin embargo, se utiliza constantemente durante el transcurso de la simulación. Cualquier sonido proporcionado debe encajar en la textura del programa. Debe tener una razón obvia para su existencia: mejorar la atmósfera del juego y tal vez crear un poco de suspenso durante la pausa inevitable que requiere la tabulación de los datos.

Para el sonido de inicialización, se pusieron en servicio las variables de bucle Scan e Idate para la información de tono. Multiplicar los dos produce una serie de tonos descendentes. El usuario no tarda mucho en familiarizarse con la secuencia y anticipar cuánto durarán los cálculos. En este ejemplo, por supuesto, la base de datos es pequeña y las manipulaciones mínimas. Pero cuando el bucle se vuelve complejo, resulta vital darle al usuario una forma de calcular aproximadamente el tiempo que tendrá que esperar. Esto podría compararse con un largo viaje hasta la casa de un amigo. La mayoría de las personas descubren que a medida que se familiarizan con la ruta, el viaje parece mucho más corto que la primera vez que lo hicieron. El conocimiento y anticipación del tiempo requerido acorta enormemente el tiempo subjetivo del viajero.

En la subrutina de cálculo del promedio, los datos se muestran como resultados entrantes de una encuesta a nivel nacional. Mientras los candidatos se apiñan alrededor del monitor, el hiperactivo código Morse canta y pita, escupiendo ocasionalmente un porcentaje ante los aplausos y gemidos de los participantes. La tediosa pausa se ha transformado en la emoción de la noche electoral, y la participación en la simulación se ha intensificado mediante tres líneas de código: una línea para activar el tono al azar, una línea para apagarlo al azar y otra para detener el sonido al final de la rutina.

Se podría argumentar que el tiempo dedicado a seleccionar sonidos podría aprovecharse mejor para la tabulación, acelerando así todo el proceso. Esto es cierto cuando la rutina es tan pequeña que un gran porcentaje de la codificación se dedica a la generación de sonido, como en nuestro ejemplo. Sin embargo, ninguna simulación real será tan simple y, a medida que aumente la duración del programa, la contribución de la parte de audio al tiempo de ejecución se minimizará y la recompensa por llenar el vacío será mayor.

El Denominador Menos Común. La mayoría de los programas que se comercializan actualmente están escritos para varias marcas importantes de microcomputadoras. Aunque esta situación es mejor que la exclusividad extrema de tiempos pasados, lo triste es que hay muy pocos programadores que van más allá del mínimo indispensable de traducir la sintaxis de su programa a la versión del lenguaje de cada fabricante. El resultado final es un programa con el mínimo común denominador: puede ejecutarse en todas las máquinas disponibles pero no utiliza las características especiales de ninguna de ellas.

Esto es especialmente lamentable para el consumidor, quien, al invertir una cantidad de dinero considerable en su computadora, evidentemente ha mostrado interés por las particularidades de dicha marca. Si el consumidor compra un programa que no utiliza ninguna de estas características, se sentirá decepcionado, si no enojado.

Nada de esto es necesario y es una influencia inhibidora del mercado. Cuando el propietario de un Atari compra un juego de Doohickey Software y descubre que desarrollaron sus programas originales en un TRS-80, probablemente dejará de comprarles programas. Quiere un programa que utilice los 128 colores y sorprendentes efectos de sonido polifónicos; Depende del programador el proporcionarlos.

La próxima vez, veremos la música en el Atari y examinaremos un ingenioso programa que simultáneamente dibuja bonitos gráficos y reproduce música de cuatro voces generada aleatoriamente. Hasta entonces, ¡siga experimentando!

10 REM **********************************
20 REM *       SAMPLE PROGRAM ONE       *
30 REM **********************************
40 REM   
50 DIM STATES(50,3),CAND(3)
60 REM
70 REM **INITIALIZE POPULARITY**
80 REM
90 FOR IDATE=1 TO 3
100 CAND(IDATE)=0
110 FOR SCAN=1 TO 50
120 STATES(SCAN,IDATE)=INT(RND(0)*30)
130 REM "MAKE A NOISE**
140 SOUND 0,SCAN*IDATE,10,6
150 NEXT SCAN
160 NEXT IDATE
170 REM **SHUT OFF SOUND**
180 SOUND 0,0,0,0
190 REM "CALL AVERAGING ROUTINE**
200 GOSUB 1000
210 REM **INITIALIZATION COMPLETE**
220 REM MAIN BODY OF PROGRAM WOULD
230 REM FOLLOW....
240 END
250 REM
260 REM
1000 REM *** AVERAGING ROUTINE ***
1010 REM
1020 GRAPHICS 0
1030 PRINT "Only 3 weeks 'til the election!"
1040 PRINT
1050 PRINT "Latest UPI Poll Results follow...."
1060 PRINT:PRINT
1070 FOR IDATE=1 TO 3
1080 PRINT "Candidate ";IDATE;": %";
1090 FOR SCAN=1 TO 50
1100 CAND(IDATE)=CAND(IDATE)+STATES(SCAN,IDATE)
1110 REM
1120 REM *** SOUND PORTION ***
1130 REM RANDOM ON/OFF OF PURE TONE
1140 REM
1150 REM IF TRUE THEN SOUND ON
1160 IF RND(0)<0.4 THEN SOUND 0,20,10,8
1170 REM IF TRUE THEN SOUND OFF
1180 IF RND(0)<0.5 THEN SOUND 0,0,0,0
1190 NEXT SCAN
1200 REM **OUTPUT AVERAGE**
1210 CAND(IDATE)=INT(CAND(IDATE)/5)/10
1220 PRINT CAND(IDATE)
1230 NEXT IDATE
1240 REM **SHUT OFF SOUND**
1250 SOUND 0,0,0,0
1260 RETURN	

Leer la siguiente columna que es composición aleatoria e indirección musical.

Publicado en revista Softline volumen 1 de julio del 1982, páginas 31 al 33.