4 ms·

Most game engines work with some kind of abstraction to unify access to the underlying graphics APIs such as D3D, DX12, OpenGL, Vulkan and Metal (for example in

by m12k 6y ago

Most game engines work with some kind of abstraction to unify access to the underlying graphics APIs such as D3D, DX12, OpenGL, Vulkan and Metal (for example in Unity there's GraphicsDevice). Does anyone know if there's any work being done to create an open source abstraction like that? It would be neat if it were possible for open source games and game engines to share the work being done to ease cross-platform development.

chaorace 6y ago
OpenGL/Vulkan are open source, multi-platform abstraction layers. Of course, the graphics API isn't the only thing you have to get to work on multiple platforms. There's also the sound stack, networking, window management, and so forth. I think what you're getting at is some kind of all-in-one platform that abstracts away all of those lower level interfaces. In that case, that's basically what Unity is. Unity (and other cross-platform engines) do abstract away the metal in an open source, cross-platform set of APIs/tooling. If you're more interested in application development, as opposed to videogame development, there's toolkits like QT and VM-based environments like Java and Electron. The efficaciousness of these approaches do vary, however. Java UIs are famously ugly, due to how poorly they integrate with the host OS, Electron UIs are famously slow, due to literally being standalone web browser instances, and QT UIs are famously finicky, due to trying to abstract a lot less than the other approaches.
- seg_lol 6y ago
  Right now that cross platform abstraction layer is the Web. - https://get.webgl.org/webgl2/ https://get.webgl.org/webgl2/ - https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_... - https://webrtc.org/ https://webrtc.org/
  - kevincox 6y ago
    This is true and works for a lot of things (I love the web and publish a lot of web apps). However there is currently a very significant performance penalty both due to the available graphics APIs and due to WASM or JS vs native CPU performance. So for games with demanding graphics the web isn't that attractive of a target.
    - seg_lol 6y ago
      I didn't say it was the highest perf. Just that it is that abstraction layer that runs everywhere.
  - chaorace 6y ago
    I absolutely agree. It's the best way to get an app out that works everywhere. In fact, I actually really wish we could collectively work out some kind of shared container environment for such apps to run more "natively". Something like Electron, but shared between many applications and a little more loosey-goosey in terms of hacking on top of it. Essentially, I want emacs for webapps lol
    - seg_lol 6y ago
      Not being snarky, but I believe that format is html.
      - chaorace 6y ago
        No snark taken. My counterpoint here would be that HTML is a markup language and that the "equivalent to emacs" would be the web browser itself. My issue with that potential position is that the web is implicitly untrusted. That's why developers even deign to put up with Electron in the first place, because their app can run with more permissions and, thus, offer better host integration (i.e. "nativeness"). Of course, everyone loves to hate Electron. Who wants to run 6 different Chromium instances? Nobody, apparently! I'm not the first wise guy to suggest a single-instance approach that combines the performance wins of a shared browser instance with the trust of an Electron application. It's painfully obvious that there's a golden medium here, but, of course, if it were an easy problem to solve, it would already be solved!
jbister 6y ago
I believe bfgx[0] is similar to what you're describing. It's been around since before the Vulkan/DX12/Metal era so the abstractions are more similar to OpenGL/DX11 where you don't have concepts like command buffers and command queues etc, which might be a turn off. Big open source projects still seem to roll their own solution for this, which I imagine is both for historical reasons but also because there might be a fear that using a library like this could leave your hands tied when you need to do some API-specific workaround. 0. https://github.com/bkaradzic/bgfx https://github.com/bkaradzic/bgfx
- m12k 6y ago
  After searching some more, I came across this: https://github.com/ConfettiFX/The-Forge https://github.com/ConfettiFX/The-Forge It sounds a bit more heavyweight than what I was getting at, but it still makes me hopeful that there's a future for something like this.

by m12k 6y ago

chaorace 6y ago

OpenGL/Vulkan are open source, multi-platform abstraction layers. Of course, the graphics API isn't the only thing you have to get to work on multiple platforms. There's also the sound stack, networking, window management, and so forth. I think what you're getting at is some kind of all-in-one platform that abstracts away all of those lower level interfaces. In that case, that's basically what Unity is. Unity (and other cross-platform engines) do abstract away the metal in an open source, cross-platform set of APIs/tooling. If you're more interested in application development, as opposed to videogame development, there's toolkits like QT and VM-based environments like Java and Electron. The efficaciousness of these approaches do vary, however. Java UIs are famously ugly, due to how poorly they integrate with the host OS, Electron UIs are famously slow, due to literally being standalone web browser instances, and QT UIs are famously finicky, due to trying to abstract a lot less than the other approaches.

seg_lol 6y ago
Right now that cross platform abstraction layer is the Web. - https://get.webgl.org/webgl2/ https://get.webgl.org/webgl2/ - https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_... - https://webrtc.org/ https://webrtc.org/
- kevincox 6y ago
  This is true and works for a lot of things (I love the web and publish a lot of web apps). However there is currently a very significant performance penalty both due to the available graphics APIs and due to WASM or JS vs native CPU performance. So for games with demanding graphics the web isn't that attractive of a target.
  - seg_lol 6y ago
    I didn't say it was the highest perf. Just that it is that abstraction layer that runs everywhere.
- chaorace 6y ago
  I absolutely agree. It's the best way to get an app out that works everywhere. In fact, I actually really wish we could collectively work out some kind of shared container environment for such apps to run more "natively". Something like Electron, but shared between many applications and a little more loosey-goosey in terms of hacking on top of it. Essentially, I want emacs for webapps lol
  - seg_lol 6y ago
    Not being snarky, but I believe that format is html.
    - chaorace 6y ago
      No snark taken. My counterpoint here would be that HTML is a markup language and that the "equivalent to emacs" would be the web browser itself. My issue with that potential position is that the web is implicitly untrusted. That's why developers even deign to put up with Electron in the first place, because their app can run with more permissions and, thus, offer better host integration (i.e. "nativeness"). Of course, everyone loves to hate Electron. Who wants to run 6 different Chromium instances? Nobody, apparently! I'm not the first wise guy to suggest a single-instance approach that combines the performance wins of a shared browser instance with the trust of an Electron application. It's painfully obvious that there's a golden medium here, but, of course, if it were an easy problem to solve, it would already be solved!

jbister 6y ago

I believe bfgx[0] is similar to what you're describing. It's been around since before the Vulkan/DX12/Metal era so the abstractions are more similar to OpenGL/DX11 where you don't have concepts like command buffers and command queues etc, which might be a turn off. Big open source projects still seem to roll their own solution for this, which I imagine is both for historical reasons but also because there might be a fear that using a library like this could leave your hands tied when you need to do some API-specific workaround. 0. https://github.com/bkaradzic/bgfx https://github.com/bkaradzic/bgfx

m12k 6y ago
After searching some more, I came across this: https://github.com/ConfettiFX/The-Forge https://github.com/ConfettiFX/The-Forge It sounds a bit more heavyweight than what I was getting at, but it still makes me hopeful that there's a future for something like this.