Would you mind explaining in more detail why you didn't like using DirectX? When I was reading up for some games if they would get an OpenGL version, I was reading more than once that OpenGL were a mess.
It was a really simple project, like a couple of colored rotating triangles. I think it was like... maybe 10 short lines of code for OpenGL, and over 50 to do it with DirectX.
Of course, I can't speak for how hairy OpenGL might get at doing more advanced features, and of course, in a lot of cases games are built on established game engines which do most of the DirectX and/or OpenGL coding for them.
OpenGL has so much implicit state and "defaults" set for you that you can get a "hello world" -style app done really quickly, but then it all falls apart.
And if I'm guessing correctly, you probably used legacy, fixed function OpenGL (ie. no shaders) with immediate mode rendering (glBegin/glEnd). Because you can't do anything in 10 lines with modern OpenGL.
As soon as you start doing something practical, you start fighting OpenGL all the time. It's a badly designed, very error prone API that requires much more developer effort than any of the competing APIs.
If you apply best practices to OpenGL code (don't rely on global, implicit state, use shaders/buffers/etc) , it's about on par with the "lower level" APIs.
My OpenGL boilerplate code and my Vulkan boilerplate code have about the same number of lines of code in them while they do about the same things (create rendertarget, framebuffer, clear the screen, draw some text, draw a triangle, blit to screen, measure performance counters). OpenGL is a bit less by a small margin, but the difference is only in the verbosity of Vulkan code (ie. you have to explicitly type every single pipeline state, even if it doesn't matter, e.g. depth test mode when depth test is disabled).
In my opinion the bottom line is this: Vulkan is verbose but OpenGL is complex. I'll take verbosity over hidden complexity any time.
