
D7VK es una capa de traducción basada en Vulkan para Direct3D 7, 6, 5 y 3 para usar con Wine/Proton, y está entrando en modo de mantenimiento con el lanzamiento de la versión 2.3.
¿Qué es? Utiliza una versión modificada del backend D3D9 Vulkan de DXVK, así como la implementación DDraw de Wine o la implementación DDraw propia de Windows, y actúa como un proxy entre los dos. Básicamente, esta es otra forma de ejecutar juegos antiguos de Windows en Linux con alto rendimiento y precisión.
El desarrollador anunció el lanzamiento de la versión 2.3:
“Si bien el código base ha alcanzado lo que yo llamaría un punto de madurez (ver también el anuncio a continuación), esta versión introduce varios cambios importantes en términos de manejo de objetos, así como varias correcciones nuevas y soluciones alternativas dirigidas a los primeros juegos D3D.
También hay una optimización de rendimiento (posiblemente final) que pude implementar manipulando la ubicación de la memoria de nuestras superficies de sombra. Estas son superficies de espejo que creamos en la ruta de vista «antigua» para reemplazar la superficie subyacente real, para evitar conflictos en la cadena de intercambio causados por la presencia de DDraw (WineD3D) en la cadena de intercambio.
Los juegos que tienen la costumbre de flotar sobre la imagen renderizada final abusan bastante de ellos, por lo que podemos ver algunas mejoras de rendimiento bastante agradables si mantenemos estas superficies de sombra en la memoria del sistema. Irónicamente, es en Empire Earth donde esta diferencia es más notable, por lo que si bien ya era un foco en la versión v2.1, ahora aparece por segunda vez, esta vez en una prueba de comparación y en la línea de tiempo de evolución del rendimiento de D7VK:
El anuncio muestra una diferencia significativa entre las versiones 2.2 y 2.3 de Empire Earth, como la velocidad de fotogramas en una escena que salta de 80,6 a 137 fps:

- Rediseñado basado en el reciente DXVK. v3.1.1 lanzamiento menor.
- Optimicé la generación de superficies de sombra y la reposicioné para mejorar el rendimiento en la mayoría de los escenarios. Por lo general, esto reduce la sobrecarga que se ve en los juegos que colocan el cursor directamente sobre la superficie principal. Star Trek: Armada es el único juego conocido que sufre una degradación del rendimiento debido a esto, por lo que ahora hay una opción de configuración para permitir que las superficies de sombra se sincronicen con las superficies principales establecidas por la aplicación que realiza la llamada. No te preocupes, aún puedes conseguir lo mejor. Star Trek: Armada experiencia con D7VK.
- Se agregaron comprobaciones de compatibilidad con formatos de profundidad en el lado de Vulkan antes de informarlos como disponibles. Esto puede ayudar a resolver problemas en varias plataformas móviles con soporte de formato limitado.
- Se agregó una solución alternativa para corregir el video de introducción que se reproduce en la versión original (sin parches). Necesidad de velocidad: Porschesimplemente no brinda soporte para superficies superpuestas (gracias a @CkNoSFeRaTU por notar esta característica).
- Procesado intermitentemente/parcialmente
EnumSurfacesprovoca llamadas más confiables, evitando fugas superficiales de las devoluciones de llamadas de DDraw. - Gracias a @CkNoSFeRaTU pasamos por alto lo no especificado
dwVertexCountvalores utilizados durante la configuración del runbuffer, lo que elimina los problemas de renderizado en Venganza Oscura. Como resultado, el juego (finalmente) se puede jugar en Linux. - Comprobación de superficie RT simplificada para las primeras API D3D para reflejar el comportamiento nativo, lo que permite utilizar superficies simples como objetivos de renderizado.
- Agregado
ProcessVerticesStridedimplementación para D3D7, aunque no hay usuarios conocidos por el momento. - Extensiones actualizadas durante
D3DPROCESSVERTICES_COPYTambién realiza operaciones de búfer, lo cual es necesario para algunos juegos D3D3 como G-policía Y hiperblade. La revisión también simplificó un poco el procesador.ProcessVerticesimplementación, aunque es poco probable que haya diferencias notables en el rendimiento. - Lógica de procesamiento de texturas unificada en todas las primeras API de D3D. Esto era necesario porque D3D6, aunque promocionaba la eliminación de los descriptores de textura, terminó teniendo un recurso alternativo que, como habrás adivinado, incluía descriptores de textura. Esto no resuelve ningún problema per se, pero generalmente es más sólido contra juegos que abusan de esta característica, p. Grandia II.
- Se solucionó un problema por el cual las operaciones alfa heredadas permanecerían vigentes después de cambiar el modo de fusión sin realizar ningún cambio en la textura instalada. Gracias @CkNoSFeRaTU por esto. Se solucionó un problema con la transparencia de la superficie del agua en zar.
- Tanque unificado
- El código base se considera lo suficientemente maduro como para lograr sus objetivos iniciales… bueno, en constante expansión… de proporcionar un buen soporte para todas las primeras API de modo inmediato D3D.
- No se espera que funcione en ninguna característica importante nueva en el futuro, aunque, como de costumbre, se corregirán errores y se realizarán adiciones menores.
- El ciclo de lanzamiento será más largo y los lanzamientos serán menos frecuentes.
- Cambie las implementaciones de materiales y texturas en D3D6/5/3 cuando sea posible mediante el uso de objetos genéricos preexistentes.
- La implementación de la ventana gráfica D3D6/5/3 se ha unificado implementando todas las interfaces en un solo objeto. Desafortunadamente, esto sólo es posible para las ventanas gráficas, ya que todas las interfaces de las ventanas gráficas son extensiones entre sí, lo cual es un caso excepcional en las primeras etapas de D3D. Se solucionó un problema al iniciar el juego en la versión (reparada) de GOG. Star Wars: Alianza X-Wing y generalmente es más resistente a modificaciones/parches que conectan la tabla virtual de la ventana gráfica y dependen de dichos detalles de implementación.
- Se eliminaron algunas comprobaciones de los tamaños de la estructura de descripción del búfer de ejecución, ya que aparentemente no las realiza la implementación nativa y se sabe que algunos juegos envían tamaños innecesarios (tos, abandonadotos).
- Se agregó la capacidad de usar una escala de compensación de LOD invertida para el mapeo de mip. Aparentemente esto es lo que se esperaba en algunos de los primeros juegos D3D, como Corredor de línea rojadebido a una entrada engañosa en la documentación D3D6/5.
Dado que ahora está entrando en modo de mantenimiento, los lanzamientos serán menos frecuentes y no se esperan nuevas funciones importantes.








