Still working through it and I have a basic ctrl that only clears the ctrl to a random color on linux for now. Honestly though if I was going to create a VulkanDraw I do wonder about how to properly architect it. I'm considering going back and rearchitecting the VideoCtrl because it is admittedly not very well-written and I wanted Vulkan HW support anyway.
I'm looking at Mirek's JetStory in combination with the GlDraw source to see how I would adapt Vulkan. It took hundreds of lines of code just to get to a clear screen routine , but from what I've figured out so far there's a drawing queue, you buffer up a bunch of drawing commands at once and you have a swapchain for queuing up multiple images. Initially I had some problems with redrawing during resize events because you have to go back and pretty much recreate everything - the surface, the queue, the commandbuffers, etc but I found if you pass the old surface in when creating a new one and then destroy that surface you can avoid the slowness during resize.
Will hopefully release some example code as I make more progress but I doubt I'll be able to create VulkanDraw all by myself, I'm not a graphics expert - it's more of a curiosity at the moment.
Xemuth Messages: 375 Registered: August 2018 Location: France
Hello JjacksonRIAB, I did try to create a VulkanCtrl for U++ but instead of OpenGL, Vulkan is much more verbose and supply a deep access to the graphic card. Learning it take a lot of time. I did some testing ( here is workspace ) nothing fancy nor working but the thing that could interest you is this schema I did to track all vulkan interface and relation between them :
It's far from being complete but it may could help you !
It does help! I'll take a look at it and your source. I agree from even the basic stuff I've done that it has a lot of components looks like it's going to be more difficult to expose the things that a programmer is going to want to use in all the different ways they can be used.