[DAEDALUS] - R10 Plan of Action

(Ojo: Las palabras entrecomilladas no llegué a pillar que significaban, asi que antes de arriesgarme a cometer una atrocidad, preferí ponerlo tal cual )
Antes de que me fuera de vacaciones os pregunté en que deberia centrarme para la siguiente release de Daedalus. Alrededor de 200 respondieron, y he disfrutado leyendo lo que habéis dicho.
Había algunas sugerencias brillantes, así que muchas gracias por vuestra colaboración.
Parece bastante claro que la velocidad es el principal tema que la mayoría de gente quiere que me centre. Mucha gente tambien mencionó la compatibilidad y los savestates o soporte para guardado, pero nada comparado con el número de gente que quería mejoras en la velocidad.
Mi plan es sacar la release de Daedalus R10 por finales de Marzo, centrándome en mejoras en la velocidad. Si puedo agregarle algún arreglo de compatibilidad, haré esto también.*
Bastante gente ha preguntado que posibilidades quedan de optimización. Esta es una pequeña lista de cosas que necesitan ser más trabajadas:
En muchos juegos, gran parte del tiempo en el que se ejecuta codigo dinamicamente recompilado se están haciendo cosas que pueden ser potencialmente emuladas a alto nivel. Por ejemplo, sobre el 5% del tiempo en el que se ejecuta código dynarec en Mario64 se está solamente convertiendo matrices desde un punto flotante a un formato de punto fixed (fixed point format). Otro 4-5% del tiempo está en un bucle deshabilitando areas del cache de datos (cosa irrelevante en un emulador)
Algunos de los más fragmentos más caros són aquellos que se “branch” a ellos mismos (ej: esos hacen demasiados bucles). Para optimizar esto puedo evitar cargas y “flushing” registros del caché en cada paso del bucle.
Puedo implementar la opción frameskip (Lo tenía que haber implementado en la R9, pero se me olvidó!)
Puedo hacer uso del Media Engine (tal y como Exophase me sugirió en una conversación, ya que el ME no puede acceder a la VRAM, esto haría más sensato ejecutar las listas de Audio y Display en la CPU, y así emular la CPU de N64 en la PSP ME)
Hay algunas situaciones donde falla en crear fragmentos en el recompilador dinamico – por ejemplo si el codigo recompilado escribe en un registro del hardware, esto activa una interrupción y hace que la generación del fragmento se aborte. Debería ser capaz de tratar mejor con estas situaciones.
El generador de fragmentos puede hacer mucho más para mejorar el “caching” del registro, y eliminanar las operaciones de 64-bit redundantes.
Hay muchas situaciones donde las roms de N64 se quedan paradas esperando. He detectado algunos casos de esto, pero no todos. Si puedo identificar ejemplos más complejos puedo hacer que el generador de fragmentos los optimize.
Algunas roms hacen que el cache del dynarec esté repetidamente “dumped and recreated” (Creo que el Banjo Kazooie es una de ellas). Arreglar esto puede comportar una mejora.
Estoy optimizando los accesos a la memoria ya que la mayoria estan en el rango 0x80000000 - 0x80800000, el qual es incorrecto para las roms que hacen mucho uso de la memoria virtual o acceden a la RAM a traves del rango 0xa0000000
Puedo mejorar el “trace recorder” para saber en que rango de memoria accede, y generar codigo para optimizar esto.
Ahora que el motor dynarec produce código mucho mejor, el coste del “display list processing” es más importante, con lo que tambien se puede optimizar esto.
Es una lista bastante grande, así que dudo que vaya a ser capaz de trabajar en todas estas cosas antes de finales de Marzo, pero creo que demuestra que aún hay mucho para optimizar.

-StrmnNrmn

*Justo esta mañana, he descubierto porque el soporte al Expansion Pak estaba roto, así que el Majora’s Mask y un par de otros juegos similares ya cargan correctamente