Difference between revisions of "Compatibility layers"

From Emulation General Wiki
Jump to navigation Jump to search
m
(correcting myself here)
Line 86: Line 86:
 
Compatibility layers may also make use of '''wrappers''', which translate a specific graphics API to another. How the user sets up the wrapper varies between each project but most involve a drop-in replacement of the original libraries.
 
Compatibility layers may also make use of '''wrappers''', which translate a specific graphics API to another. How the user sets up the wrapper varies between each project but most involve a drop-in replacement of the original libraries.
  
To understand why this is needed for older games, it's important to understand that during the 90s the graphics card market for [[86/286/386/486/Pentium/Pentium_II|IBM PCs and compatibles]] was in its infancy, and Direct3D wasn't an automatic choice for developers. Some games were often designed for 3Dfx's Glide API so that it would run with their Voodoo card. With 3dfx going bankrupt however, support for Glide didn't stay around and was basically abandoned for so long that modern Windows does not support it. A wrapper is now needed to play these games, or if we're lucky the game gets [[Game engine recreations/Source Ports|a port]] to other APIs instead.
+
To understand why this is needed for older games, it's important to understand that during the 90s the graphics card market for [[86/286/386/486/Pentium/Pentium_II|IBM PCs and compatibles]] was in its infancy, and Direct3D wasn't an automatic choice for developers. Some games were often designed for 3Dfx's Glide API so that it would run with their Voodoo card. With 3dfx going bankrupt however, support for Glide didn't stay around and the API was made open-source, but NVIDIA and AMD never incorporated it into their drivers. A wrapper is now needed to play these games with hardware acceleration, or if we're lucky the game gets [[Game engine recreations/Source Ports|a port]] to other APIs instead.
  
 
{| class="wikitable sortable" style="text-align:center;"
 
{| class="wikitable sortable" style="text-align:center;"

Revision as of 20:21, 20 January 2019

While not strictly emulation per se (hence why Wine stands for "Wine Is Not an Emulator"), compatibility layers allow software written for one operating system to run on a different OS, often by translating API and system calls made by an application to their equivalent calls in the host operating system. In theory, this should allow for near-native performance since no processor emulation takes place, but in practice some software such as games will tend to run a bit slower due to other bottlenecks that occur as a result of replicating the correct behavior, such as accounting for graphics APIs like Direct3D that aren't supported on non-Microsoft platforms. Additionally, compatibility layers may also use emulation in order to run software built for a different architecture.

Compatibility layers

Name Operating System(s) Latest Version Active Recommended Runs the following software
PC
Wine Linux, macOS 9.0 Windows applications and games
Wineskin macOS 1.7 Windows applications and games
Proton Linux 8.0-5 Windows games
TeknoParrot Windows 1.0.0.140 Windows-based arcade games
WineVDM Windows v0.6.0 16-bit Windows apps and games
WoW Windows ? Windows 9x apps and games
Win3mu Windows ? Windows 3.x apps and games
Ardi Executor Multi-platform 2.1.17 Classic Mac OS software up to System 6
Darling Linux Git (WIP) macOS software
Mobile
Wine Android 9.0 (WIP) Windows applications and games

Comparisons

  • Wine is a free and open-source compatibility layer that aims to allow computer programs (application software and computer games) developed for Microsoft Windows to run on Unix-like operating systems, primarily Linux and macOS. Since late 2017 there is also an experimental build for Android. Wine is almost as old as the Linux project, starting in the summer of 1993. Today it's widely used, very popular and sponsored by companies such as CodeWeavers and Valve. The core Wine development aims at a correct implementation of the Windows API as a whole. In this regard it's similar to the MAME project in its focus on correctness over usability. There are a lot of versions/forks of Wine which focus of different goals, such as usability, compatibility, gaming, office applications, etc. A few are listed below, Wikipedia has a more complete list.
    • Proton is Valves one-click solution to play Windows games on Linux. It's included in the Steam Linux client by default. Simply click on a whitelisted game and it will launch without any configuration, or enable it for all games in the settings. Proton is based on a fork of Wine in combination with other components such as DXVK (explained below) and FAudio.
    • Wineskin is an open-source compatibility layer which allows users to easily convert Windows software to macOS. The ports are in the form of Mac .app bundles with a self-contained Wine instance which are wrapped around the application to be converted.
  • TeknoParrot is a compatibility layer for Windows PCs to run games originally made for Windows-based arcade systems. Has since version 1.51 also support for some games from the Linux-based Sega Lindbergh arcade board.
  • Darling is a translation layer that allows you to run unmodified macOS binaries on Linux. In its nature, it is similar to the well-known Wine project. At this point, does not yet run macOS application with a GUI.

Graphics APIs

Compatibility layers may also make use of wrappers, which translate a specific graphics API to another. How the user sets up the wrapper varies between each project but most involve a drop-in replacement of the original libraries.

To understand why this is needed for older games, it's important to understand that during the 90s the graphics card market for IBM PCs and compatibles was in its infancy, and Direct3D wasn't an automatic choice for developers. Some games were often designed for 3Dfx's Glide API so that it would run with their Voodoo card. With 3dfx going bankrupt however, support for Glide didn't stay around and the API was made open-source, but NVIDIA and AMD never incorporated it into their drivers. A wrapper is now needed to play these games with hardware acceleration, or if we're lucky the game gets a port to other APIs instead.

Name Operating System(s) Latest Version Translates Into Active Recommended
nGlide Windows 2.0 Glide Vulkan, Direct3D 9
DXVK Linux 0.95 Direct3D 10, Direct3D 11 Vulkan
MoltenVK macOS, iOS 1.0.31 Vulkan Metal ?
dgVoodoo 2 Windows 2.55.4 Direct3D 1-7, Direct3D 8.1, Glide Direct3D 11 ?
VK9 Windows, Linux 0.29.0 Direct3D 9 Vulkan ?
Glidos Windows 1.53b Glide (DOS) ? ?
OpenGlide Windows 0.09 Alpha Glide OpenGL ?
psVoodoo Windows 0.13 Glide Direct3D 9 ?

Comparisons

  • nGlide is a 3Dfx Voodoo Glide wrapper. It allows you to play games designed for 3Dfx Glide API without the need for having 3Dfx Voodoo graphics card. All three API versions are supported, Glide 2.11, Glide 2.60 and Glide 3.10. nGlide emulates Glide environment with Direct3D 9 and version 2.0 implemented Vulkan support, which also makes it work under Linux using Wine Staging 2.10.0 or newer.[1] Glide wrapper also supports high resolution modes. Has a compatibility list.
  • dgVoodoo 2 is a wrapper for old graphics API's for Windows Vista/7/8/10. The API's it currently can wrap are: Glide 2.11, Glide 2.45, Glide 3.1, Glide 3.1 Napalm, DirectX 1-7 (all versions of DirectDraw and Direct3D up to version 7) and Direct3D 8.1. This wrapper can use Direct3D 11 with different device types as wrapping output such as hardware or software rendering.
  • DXVK is a Vulkan-based translation layer for Direct3D 10 & 11, which allows running Windows 3D applications on Linux using Wine.
  • VK9 runs Direct3D 9 applications on Windows or Linux (with Wine) over Vulkan.

References