I don’t think I’ll touch Vulkan for a couple of months (1500 lines just to clear the darn screen? Damn!). But temptation usually prevails when it comes to exciting new libraries.
Yes, I did not think that it would be such a lot of work to get a clear screen to work.
But the good thing is that most of that code is general setup which you need to do in any case. And once you’ve cleared the screen you’ve already covered about 80% of the whole Vulkan API.
It is really a clean and well thought-through API, which makes OpenGL look really patchworky, tangled up and cumbersome to use (more than it used to be).
Which means that adding anything on top of a simple clear screen app, like rendering a triangle, is not that difficult to do.
So in essence: With Vulkan you get more control over your setup, which is good, but it has a much steeper learning curve than OpenGL. But once you have that down, you know already pretty much everything there is and programming in it should become much smoother afterwards.
So do have a try with it. I think the LWJGL project will get some demos and also some boilerplate reducing utility classes/methods to make working with Vulkan a lot more pleasure.
In my opinion Spasi deserves all the medals.
He provided the LWJGL Vulkan bindings in such short time, that I find it unbelievable how he did this.
And the binding is close to (if not already) perfect right now.
So, absolutely fantastic work of him!
An overlooked missing feature of OpenGL was that FPS was limited to 10 000 on Nvidia hardware. I’m glad to inform you all that the cap has been removed in Vulkan, so now I can enjoy my clears at over 20 000 FPS. I can’t believe it took them so long to realize that 10 000 simply isn’t enough for some people. :
I had seen the issue, even with game loops that plays catch up, and does use the rest of the time to do repeated frames, they still appear to be choppy, even when the framerate is at high numbers. I’ve tried to use an interpolation when rendering, but that didn’t work out that great, since I don’t know how to interpolate transformation matrices…
How and why are you needing that many framerates? and also how is it smooth?
Vulkan is really exciting, there are mainly three reasons why one should choose it over OpenGL: multithreading rendering, lower overhead (although many would argue why choosing java in the first place and especially lwjgl) and full control.
Anyway, OpenGL has evolved a lot in the last years. OpenGL 4.5 and the AZDO extensions do bring some concepts close to Vulkan’s philosophy but there are also things that will never die (such as the texture units).
Vulkan is actually a so-called double edge sword: huge powers bring huge responsabilities 8), this means a lot of code path, based on the resources available.
The OpenGL drivers are, yes, unpredictable sometimes, but they are also very well optimized, so in order to make it worth choosing Vulkan one should not only match the driver performances, but be faster.
Actually there are also another couple of reasons to choose Vulkan, if one needs extremely all the cpu power he can get, the cpu delta OpenGL->Vulkan may still be very tempting and the compatibility, OpenGL ecosystem is quite fragmented, Nvidia is always first to implements the last features, but forgives a lot of errors, Amd closes, in general, quite quick the gap. And then we have the lazy window Intel team (because the linux team is different and they rock) and Apple, who really suxs. Vulkan is, under this point of view, somehow like OpenGL 3.3, it brings a fresh start. A difference compared to OpenGL is that Vulkan introduces also a couple of features to push vendors to keep their drivers updated and this is really excellent.
Vulkan is for the big Software Houses, small/indie devs will remain on OpenGL and if they want faster performances, they should consider moving on modern GL before jumping to Vulkan.
There is a small list of very intersting posts on the Nvidia website, here at the end of the page. Also the upcoming talks at the GDC will be really interesting, especially the comparison AZDO vs Vulkan (Nv command list ext seems to be even faster than Vulkan).
Funny, I have nv and I experience that cap with jogl but not lwjgl
One thing I might potentially like about Vulkan is the possibility of more userfriendly API’s being developed on top of Vulkan. I have no interest in dabbling in supertechnical details, but maybe something easier / better than OpenGL built on top of Vulkan, who knows.
If i use Vulkan it is because under the hood some game engine starts using it. The days of doing it all myself are long gone. I may add a feture or a special effect, or as in jME hack some mulitmonitor support. But outside that, na.
And today i registered as a Ltd company (incorporate). I also managed to get Unity to work again. We have models importing to both jME and Unity, but some slight issues with jME. Also in Unity there is no IK and everyone seems to use mecncia or whatever for animations.
Yea i will freeze the engine decision at the end of the week.
I’m gonna try to abstract away the graphics API used in NNGINE/We Shall Wake, so that I can switch between the two without having to change code. Sadly since Vulkan needs so much more information (memory barriers, image usage, etc) that’s basically gonna mean that you have to code for Vulkan and all the extra info is discarded when running OpenGL, so that’s not gonna help you very much. xd