3 ms·
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/ub
by 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 agoThat 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.