Saltar al contenido principal

Carga de escenas y música desde el CD-ROM

· 6 min de lectura
Desarrollador de Unity y creador de Polygon Engine

Al trabajar en la carga de escenas de Polygon Engine, el CD-ROM fue una de las diferencias más claras respecto al desarrollo para una computadora actual. El disco ofrece mucho más espacio que la RAM de PS1, pero los datos tienen que leerse y prepararse antes de que el juego pueda utilizarlos. La velocidad de la unidad y la ubicación de los archivos influyen en ese tiempo.

Esto también afecta a las transiciones del juego. Antes de entrar a otra zona hay que decidir qué recursos estarán cargados, qué se mostrará durante la espera y qué ocurrirá con la música. Para implementar ese flujo necesitaba considerar juntas la carga de datos y la reproducción desde el disco.

Estimar los tiempos de carga del disco​

Primero tuve que distinguir la capacidad del disco de su velocidad de lectura. La capacidad indica cuánto contenido se puede almacenar; la transferencia indica cuántos datos se leen por segundo en un modo determinado. A ese tiempo se agregan la búsqueda de los sectores y el procesamiento necesario para utilizar lo que se leyó.

Como referencia sencilla, leer 150 sectores por segundo con 2,048 bytes de datos de usuario por sector da 307,200 bytes por segundo, o 300 KiB/s. Es la velocidad nominal conocida de doble velocidad para esa carga útil. Excluye búsquedas, comandos y procesamiento, y otros formatos de sector distribuyen sus datos de otra manera.

Si un área necesita 600 KiB mediante ese recorrido, la transferencia por sí sola tiene un mínimo nominal de dos segundos antes de agregar los demás costos. Es un ejemplo para planear, no una medición de una escena específica de Polygon Engine. La referencia del CD-ROM explica los modos y la estructura de sectores detrás del cálculo.

Con esa estimación ya se puede planear la transición. Una opción es mantener cargados los recursos que se utilizarán enseguida; otra, reducir los datos necesarios o mostrar una pantalla de carga. La elección depende del espacio disponible y de cómo estén organizadas las áreas del juego.

Agrupar recursos para leerlos de forma secuencial​

Supongamos que una habitación necesita una malla, varias texturas, materiales, scripts y efectos de sonido. Cargar cada dependencia como un archivo independiente puede implicar cambiar repetidamente el lugar donde lee la unidad. Aunque el tamaño total sea modesto, el patrón de acceso puede agregar espera.

Agrupar recursos que se utilizarán juntos permite leerlos de manera secuencial y reducir los cambios de ubicación del lector. Esa es la razón de los paquetes de dependencias por escena de Polygon Engine: preparar en la compilación una distribución más conveniente para la carga.

Al organizar esos paquetes hay que decidir cómo manejar los recursos compartidos. Repetir uno en varias escenas puede simplificar la lectura, a cambio de ocupar más disco. Mantener una sola copia ahorra espacio, pero exige coordinar cuándo se carga y cuánto tiempo permanece en memoria. Un paquete más pequeño no necesariamente se carga más rápido.

La memoria agrega otra restricción. Leer un paquete grande en un búfer temporal no es automáticamente una buena idea si la escena final ya ocupa casi toda la RAM. El acceso secuencial y una memoria de trabajo acotada necesitan considerarse juntos.

Coordinar la música XA con la carga de escenas​

La música larga necesita otro tratamiento porque mantener una grabación completa en la RAM de la SPU consumiría demasiado espacio. CD-XA permite reproducirla conforme llegan sus datos desde el disco. Los efectos cortos, en cambio, pueden permanecer cargados para responder de inmediato a una interacción.

La lectura de música y la carga de escenas utilizan la misma unidad. Si ambas necesitan datos, el engine tiene que coordinar el acceso. Algunas arquitecturas resuelven esto con sectores entrelazados y búferes organizados para alternar lecturas, pero ese comportamiento requiere una implementación específica.

En la implementación actual de Polygon Engine, la música XA se suspende durante la carga de datos de escena y, al reanudarse, empieza desde el principio. Es una limitación que hay que considerar al elegir las pistas y diseñar las transiciones. El reinicio será más evidente en una canción con una entrada reconocible que en un ambiente sonoro de inicio suave.

La guía de audio describe cómo configurar este flujo. Al preparar un cambio de escena, se puede aprovechar una pausa, utilizar música distinta en el destino o acompañar la transición con un efecto residente. Lo importante es diseñarla teniendo en cuenta el comportamiento de reproducción que ofrece actualmente el engine.

Preparar la pantalla de carga​

La pantalla de carga también necesita prepararse a tiempo. Si sus datos solo están disponibles después de cargar la escena de destino, no podrá mostrarse durante la espera. El sistema de transición debe tener lo necesario para dibujarla antes de iniciar la parte más lenta del proceso.

Eso implica disponer de la presentación de carga, mantener la imagen estable y cambiar a la escena nueva cuando esté lista. No hace falta una pantalla elaborada, pero sí que aparezca desde el inicio de la transición y no después de varios segundos sin información.

Además, hay que definir quién controla la cámara, el audio y la entrada en cada etapa. La escena anterior deja de estar activa, la transición muestra el progreso y la nueva escena toma el control al terminar. Coordinar esos cambios evita que el jugador siga moviéndose o interactuando mientras se reemplazan los datos del nivel.

Diseñar las transiciones considerando la carga​

Al diseñar niveles, esta información permite elegir dónde conviene cargar contenido nuevo. No todas las puertas tienen que provocar una carga ni todas las áreas necesitan estar residentes. El tamaño de cada zona y la memoria disponible ayudan a decidir cómo dividir el juego.

Un conjunto pequeño de habitaciones puede permanecer cargado, mientras que un cambio importante de ubicación puede usar una transición explícita. Los pasillos también ayudan a controlar lo que se ve, aunque eso por sí solo no resuelve la carga de archivos. Conviene separar las decisiones de visibilidad de las de almacenamiento y lectura.

Entender estos tiempos me ayudó a relacionar el sistema de carga con el diseño de las escenas. La distribución de archivos influye en cuánto espera el jugador, y la presentación de la transición influye en cómo se percibe esa espera. Por eso ambas partes necesitan revisarse al probar el juego exportado.