Nem kellene annyit dolgoznia rajta. Számos módja van annak, hogy a D3D11-et támogassák újszerű motorstruktúrával. Például kaphat a motor kétféle low-level back-endet. Egyet bindlessel, és egyet a D3D11 binding API-jára írva, amelyeken keresztül támogatható akármelyik API.
Ezzel lenne egy ilyen rendszer:
'
Játék
||
High-level leképező
|| ||
Low-level leképező Low-level leképező
|| ||
OpenGL/D3D11 Vulkan/D3D12
Ennek az előnye, hogy mindegyik API-ra wrapper nélküli, gyakorlatilag natív a path, viszont hátránya, hogy eléggé melós, mert kétféle low-level leképezőt írnak a kétféle bindinghez, és a közös high-level leképező miatt a gyártóknak egy külön drivert is kell írni a játékra a jó D3D11/OpenGL sebességhez. Így működik egyébként a Nitrous, és csak azért fut jól D3D11-ben, mert az AMD és az NV írt rá egy külön, alternatív D3D11 implementációt.
A másik megoldás ez:
'
Játék
||
Mid-level leképező
|| ||
Binding wrapper Low-level leképező
|| ||
OpenGL/D3D11 Vulkan/D3D12
Ennek az előnye, hogy sokkal kevesebb meló a programfejlesztő oldalán, főleg úgy, hogy elég sok kód van meg régebbről, mivel nem nulláról készült a motor, illetve nem kell két különálló low-level leképező. A modernizált mid-level rész támogat mindent, amivel működhet a D3D11/OpenGL, és csak egy wrapper kell alá a bindinghez, míg a bindless kód működhet a Vulkan/D3D12-vel egy low-level leképezőt berakva, ami tartalmazza a memóriamenedzsmentet és kezeli a hazardokat, ugye a bekötés eleve mid-level szinten van itt kezelve. Emellett járulékos előny, hogy nem kell külön legacy implementációt írni a gyártóknak hozzá. Ilyen az AC Origins motorja. Az egész hátránya persze, hogy rohadt lassú a legacy path, és egy rakás felesleges munkát ró a CPU nyakába.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.