3 ms·
Vulkan solves a different problem though, specifically one where performance is the primary consideration and simplicity is maintained to the extent that someon
by munchbunny 9y ago
Vulkan solves a different problem though, specifically one where performance is the primary consideration and simplicity is maintained to the extent that someone who writes engines gets all of the options they need.
It's a bit hard to equate to assembly because the bulk of the complexity isn't so much "general purpose code" as "data processing pipeline." Additionally, graphics still has a very real "out of memory problem" that you can safely ignore for the most part in modern OSes and normal programming. The moment you hit "virtual graphics memory" your framerate tanks.
If you're looking for sane defaults, the answer is to use things like Unity, Unreal, etc. You can actually get quite far with their defaults and very little code. That's why I usually tell people to skip OpenGL, DirectX, or Vulkan and just go use an engine.
3d also just has an inherent complexity that at every stage you're dealing with the limitations of processing 3d data using 2d buffers. That's why any fancy effect requires you to manipulate primitives (buffers and shades).
- atemerev 9y agoI work with realtime scientific visualization, game engines solve different kind of problems. So I have no other choice than to work with OpenGL/Vulkan directly, which is... less than satisfying. Good abstraction layers are totally possible, like it was done for networking, 2D graphics, and other hard problems. However, with 3D, it is more of a cultural issue — the APIs were designed by hardware / driver people, who eat these kinds of complexity for breakfast. The rest of us have to suffer and adapt. Additionally, Vulkan is increasingly pushed as a replacement for OpenGL, and this makes me cringe. It's like somebody took the worst of WinAPI and combined it with joys of developing device drivers...