0
\$\begingroup\$

I find myself wondering whether our PC games from the 2000s will continue to operate without a VM.

To the present, GPU manufacturers have generously kept pre-3.2 OpenGL in their drivers. I'm amazed and glad that they do.

But for argument's sake, imagine OpenGL<3.2 gets dropped. The current GL acquisition mechanism looks like this:

App → calls wglGetProcAddress() → returns driver's GL functions

It's looks good at first, but legacy OpenGL support is entirely in the hands of the driver developer.

This would be a non-issue if an "adapter" or "translation layer" could be set at runtime, positioned between WGL and the driver. For example: a enthusiast-maintained DLL that translates legacy API to new API.

Do any WGL/EGL/CGL implementations support user-specified adapters like that? (I see Mesa EGL has EGL_BACKEND but it only controls what hard-coded driver is selected)

Improve this question
\$\endgroup\$
2
  • 1
    \$\begingroup\$ I wouldn't be terribly surprised if most drivers' pre-3.2 support IS just such a translation layer, just loaded by the driver itself. 😉 Have you looked into techniques like DLL Injection, which are already used to intercept driver calls from games? \$\endgroup\$
    – DMGregory ♦
    Feb 22 at 4:37
  • \$\begingroup\$ @DMGregory Oh dang, I bet you're right about the drivers having a translation layer. That seems like a natural way to cut costs... Also, that DLL injection technique looks like a very practical solution to the issue! Maybe a skilled preservationist could supply their own opengl32.dll to intercept wgl functions! Thanks for the link! \$\endgroup\$
    – KarlLightning
    Feb 22 at 5:16

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .