This is exciting because gfx-rs has implementations of Vulkan on top of Metal, D3D12, D3D11, OpenGL, and Vulkan
It brings back the option of writing one graphics backend, having it work everywhere, and as a bonus not having to deal with terrible API that is OpenGL.
OpenGL is pretty bad, but it's not clear to me that Vulkan is really any better. Importantly, though, it gives more control and so makes it possible to build a good API on top.
Vulkan is way better. It's not lower level per se, just a way better abstraction for how modern GPU hardware works as opposed to the mid/late 90s hardware that OpenGL still targets at it's core.
The biggest win is how explicit it is so you won't stutter for things like shader recompiles like you do in OpenGL (I'll give you a hint, most of the time the shader isn't fully compiled by the time glLink returns). Also, Vulkan's emphasis on immutable objects really tickles my fancy in terms of programming hygiene.
While Vulkan is a better abstraction for modern GPU hardware, I’ve always thought OpenGL better mapped to how humans think of 3D scenes, and imposes relatively little* tedious boilerplate on the developer. If I wanted to get a quick experiment up and running that just shows a model and maybe using a few shaders, I know which API I’d rather use. If I wanted to make a simple, non-AAA budget game without using Unity or Unreal, I know which API I’d rather use.
Vulkan, to me, is the assembly language of graphics APIs. Few should need to drop down that far, but those who do really need to.
*The exception being platform-specific window management which has always been terrible, but mostly solved by compatibility libraries.
Honestly, OpenGL isn't that great for how people think. IMO a scene graph API is much better in that situation.
The boilerplate in Vulkan is a lot of work to get to a triangle on the screen, but once you're there it really isn't much more work to do whatever. The boilerplate isn't linear with lines of code, and honestly anything nontrivial with modern OpenGL is probably going to have more boilerplate.
It's sort of an unfortunate consequence of how code architecturally should change with log10(cloc). Examples in Vulkan look verbose, but as soon as you get out of examples, it's a lot nicer. So, with a simple game, I'd probably end up using something like Vulkan too.
More importantly, being lower-level reduces opportunities for driver bugs and inconsistencies — aren't they the main reason GL(&ES) and D3D(<12) are bad?
The lower level = bad drivers argument doesn't really apply to D3D. Microsoft is in control of the high level pieces of that, and the ISVs target a low level API underneath all of that. It's been that way for decades at this point.
Note that while in principle a compiler for the lower-level APIs/languages should be simpler, these are still pretty complex compilers (and given the underlying architecture changes quite often they don't necessarily end up eventually stable, given the architecture-specific code frequently becomes unmaintained).
Eh, Direct3D9 was awful and not at all rooted in mathematical convention. I think (0,0) was the upper left of a texture instead of the center of the upper-left texel, too.
Granted, it's been awhile. Maybe the situation has improved.
Does it? It seems very experimental now. They even had to do work _just_ to get DOTA2 running
> The initial results were… slightly discouraging. For a while we weren’t able to get the game to start, due to our Metal backend was missing some required features, like compressed texture support
Right, at the moment there is still missing functionality on each of the backends, but Dota2 was a great test application for the gfx-rs team to prioritize implementing some of that missing functionality.
As mentioned in the blog post, the team is also actively working on improving Vulkan conformance test suite coverage, so the goal is to continue maturing these backends relatively quickly.
Does this abstraction target WebGL as well? I could imagine it being a nice portability layer for web-aware apps since rust can easily target wasm with a few compiler flags.
Ideally this should be straightforward by adapting the OpenGL ES backend to perform the equivalent WebGL calls. There have been some initial investigations into this already, and the Emscripten target worked well with an earlier version of gfx.
Great work on the gfx portability layer! I hope to be able to use it in the future, but for the time being I've abandoned gfx in favor of raw OpenGL calls in order to avoid the type complexity in gfx (I spent multiple hours trying to cram all of the gfx state into a struct, but could not figure out what to put as some of the type signatures... even with the compiler trying to help me). Hopefully the the low-level API, once stable, will give me the type simplicity I prefer.
You can also try one of the Vulkan Rust libraries (ash, Vulkano). Later you'd have easier time migrating to gfx-hal, or alternatively can just run over gfx-portability.
I spent about a week trying to play Dota2 on my macbook pro a couple years ago (I've played on Windows desktop for years), and I was very put-off by the mouse acceleration profile with my Magic Mouse. I tried tweaking it, but couldn't get it to feel like it did with my Logitech mouse on Windows.
It wasn't about dpi or speed. I would constantly find myself trying to rapidly aim-click on something and have my cursor stop just short of the target. The cursor felt _heavy_ and stuck like it didn't move as easily.
MacOS mouse acceleration takes some getting used to, and there was OS-level mouse input latency (since fixed) to contend with for a while also.
The SmoothMouse utility fixed the latency issues and made the mouse cursor move like it did on Windows. I was very disappointed when Apple deprecated the APIs that made it work.
It brings back the option of writing one graphics backend, having it work everywhere, and as a bonus not having to deal with terrible API that is OpenGL.