El proyecto D7VK para llevar soporte Direct3D 7 a Linux usando Wine/Proton se amplió en la versión 1.1 para incluir soporte experimental para Direct3D 6.
Así como DXVK comenzó como desarrollador que quería jugar NieR: Automata (ver mi entrevista original), el desarrollador D7VK quería jugar Sacrifice and Disciples II además de DXVK, por lo que lanzaron D7VK para que funcionaran bien.
En el archivo Léame actualizado para la versión 1.1 en GitHub, el desarrollador explica:
Espera, ¿qué? ¡Mi D7VK tiene D6VK! ¿Cómo llegó allí?
Después de revisar la documentación del SDK de D3D6, me pareció algo accesible, así que lo implementé. La compatibilidad con D3D7 sigue siendo el objetivo principal del proyecto, pero la compatibilidad con D3D6 también se proporcionará como una adición experimental. En términos de características y compatibilidad general, espere que las cosas sean algo peores que D3D7, porque como dije: cuanto más nos alejamos de D3D8/9, más nos alejamos de lo divino.
¿Por qué no resaltar D6VK o cambiar el nombre del proyecto?
Todas las API anteriores a D3D8 caen bajo el maldito paraguas de DDraw, por lo que no tiene ningún sentido separarlas. En cuanto al cambio de nombre, no se producirá, ya que el enfoque principal del proyecto permanecerá sin cambios.
¿Significa esto que agregarán soporte para D3D5 y D3D3 en algún momento?
No. Pero ya somos totalmente compatibles con D3D4, je. Bromas aparte, también revisé la documentación de API anterior y puedo decir con confianza que, si bien D3D6 sigue siendo bastante similar a D3D9, las API anteriores utilizan un proceso de renderizado mucho más crudo que simplemente no vale la pena renderizar en el backend D3D9 DXVK. Tampoco tiene mucho sentido considerarlo, especialmente dada su complejidad, ya que antes de D3D6 (e incluso en D3D6, para ser justos), había muy poco sobre la aceleración de hardware.
Otros cambios desde la versión 1.1 incluyen:
- Solución alternativa agregada para Sacrificio lo que permite que el juego utilice correctamente la profundidad de color/búfer z de 32 bits. Este es un problema/limitación conocido del juego, que intenta usar D32 para mayor profundidad y recurre a la versión de 16 bits si no está disponible (D32 no siempre ha sido compatible en absoluto, y es no es universalmente compatible con los controladores modernos). La solución alternativa mejora significativamente la representación de la geometría remota.
- Se agregó soporte para la representación gradual de primitivas gracias a @CkNoSFeRaTU, lo que significa Sagrado ahora jugable.
- Se corrigieron mapas mip faltantes/reemplazados en Star Trek DS9: Los Caídos (#58), gracias a @esdrastarsis.
- Solución alternativa agregada para Conquista: Guerras Fronterizaslo que permite utilizar el D7VK para renderizar en el juego, siempre que la aceleración 3D y la resolución deseada se configuren de antemano. El juego utiliza la compatibilidad DDraw extremadamente maldita, por lo que sacar algo de provecho es nada menos que un milagro.
- Se corrigieron mapas MIP mezclados en Gothic/Gothic 2 (#56).
Fuente: GitHub
Artículo tomado de MuyLinux.xyz.
