Hacker News new | past | comments | ask | show | jobs | submit login

> There's many, many different graphics abstractions out there for C and C++ alone, and none of them is The solution.

There’re downsides of course (that thing is C++ only because exceptions, requires recent enough hardware e.g. minimum GLES version is 3.0, and a few others), but in general that one is actually good. On the very high level, developers have re-implemented D3D12 over the rest of them.

Things like Angle and BGFX expose APIs which are very far from how GPU actually work, and close to the legacy stuff like D3D11 or OpenGL. For complex enough scenes, it’s pretty much impossible to get good performance on modern hardware with these APIs.

Game engines are designed in a way which does allow them to leverage the hardware, but they are huge, implementing many high-level things like assets pipelines, and are more like frameworks than libraries.

> Your comment actually reinforces the original author's point

Rendering an indexed triangle mesh with a vertex + pixel shader is the traditional rasterization technique. Compute shaders like piet-gpu, or custom vendor APIs like NV_path_rendering are examples of untraditional ones.

> You don't control what the system UI framework is doing with the GPU

Indeed, but good ones support explicit interop: WPF has D3DImage, UWP and WinUI have SwapChainPanel.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: