5 ms·

Most emulators don't use middleware, because it doesn't afford them anywhere near enough flexibility or performance.

pjmlp 6y ago
As anyone from Flipcode and Gamedevnet days knows, middleware can be as thin as couple of function pointers with shared libraries loaded on demand for the desired 3D API. The approach taken by AAA game engines, although nowadays it looks more like a bunch of abstract classes/interfaces, depending on the language. When you look into a game engine, typically 3D API abstractions are like 10% of the whole codebase.
- throwaway2048 6y ago
  If its so trivial, I'm guessing the developers would welcome patches.
  - pjmlp 6y ago
    Nowhere did I used the word trivial. I wouldn't mind to contribute if paid accordingly.
- hexmiles 6y ago
  The way some emulator use the gpu can be quite different from the way pc games use it. You can look at this article: https://dolphin-emu.org/blog/2017/07/30/ubershaders/ https://dolphin-emu.org/blog/2017/07/30/ubershaders/ for an example how console graphics programming differ. Middleware designed for games don't allow nearly enough flexibility to handle all the possible edge case that can arise. Console gpu (and graphics api) and computer gpu don't map one-to-one and they need all the feature and support from the underlying api that they can get for replicating the console way of doing things, supporting a new graphics backend is a lot of work for this reason. middleware try to abstract common pattern and flows, but every console is quite unique (in some way) middleware are not build for that and often are (a form of) a lowest common denominator for graphics api. Which is fine... for games. edit: some clarification
  - pjmlp 6y ago
    That doesn't forbade loading shared libraries as function pointers though. Even if you stay, lets say OpenGL only, there are multiple execution paths with driver and graphics card specific code paths. 3D libraries like OpenGL/Vulkan are only portable up to a certain extent. When you are coding at the ultimate performance level, you are also going into that rabbit hole of graphic card specific code paths and driver specific extensions. So, it is hardly different than having your own plugable abstraction layer.

As anyone from Flipcode and Gamedevnet days knows, middleware can be as thin as couple of function pointers with shared libraries loaded on demand for the desired 3D API. The approach taken by AAA game engines, although nowadays it looks more like a bunch of abstract classes/interfaces, depending on the language. When you look into a game engine, typically 3D API abstractions are like 10% of the whole codebase.

throwaway2048 6y ago
If its so trivial, I'm guessing the developers would welcome patches.
- pjmlp 6y ago
  Nowhere did I used the word trivial. I wouldn't mind to contribute if paid accordingly.
hexmiles 6y ago
The way some emulator use the gpu can be quite different from the way pc games use it. You can look at this article: https://dolphin-emu.org/blog/2017/07/30/ubershaders/ https://dolphin-emu.org/blog/2017/07/30/ubershaders/ for an example how console graphics programming differ. Middleware designed for games don't allow nearly enough flexibility to handle all the possible edge case that can arise. Console gpu (and graphics api) and computer gpu don't map one-to-one and they need all the feature and support from the underlying api that they can get for replicating the console way of doing things, supporting a new graphics backend is a lot of work for this reason. middleware try to abstract common pattern and flows, but every console is quite unique (in some way) middleware are not build for that and often are (a form of) a lowest common denominator for graphics api. Which is fine... for games. edit: some clarification
- pjmlp 6y ago
  That doesn't forbade loading shared libraries as function pointers though. Even if you stay, lets say OpenGL only, there are multiple execution paths with driver and graphics card specific code paths. 3D libraries like OpenGL/Vulkan are only portable up to a certain extent. When you are coding at the ultimate performance level, you are also going into that rabbit hole of graphic card specific code paths and driver specific extensions. So, it is hardly different than having your own plugable abstraction layer.