Document to fuse vulkan with vkvg (first tutorial)

[Joaopmoliveira]

No description provided.

[jpbruyere]

I would have started with basic lines. Have a look here:(http://zetcode.com/gfx/cairo/).

vulkan docs has a compatibility table for copy operations: (https://www.khronos.org/registry/vulkan/specs/1.2-extensions/html/vkspec.html#formats-compatibility). If format are not size compatible, you may point to the vkCmdBlitImage.
We need to add TRANSFER_DEST to swapchain image requirement because we use copy/blit operation to present vkvg image. If we use a full screen pipeline with vkvg image as texture, we have to add COLOR_OUTPUT. This is not a requirement from vkvg, but from the application that want to print on screen vkvg image.

I'm not fan of the formulation "how one",

I've seen that there is no easy way to make pull request on the github's wiki, but I will surely commit tutorials on it.

So what is important to have a sample running:

1. picking a graphic queue with presentation support (every single vulkan app need this to show something)
2. Create your swapchain with 'TransferDest' or 'ColorOutput'.

for vkvg

1. what to do to compile with vkvg (from source, binary) (I'll make a release with binaries soon) with details.
2. create/destroy api, opaque pointers model.
3. device creation, only one device per application, must be destroyed at the end. multisampling is enable here.
4. surface creation, may not access image when a vkvg.context is bound to it.
5. context creation/destruction
   5a) drawing and painting how to.
   -clear surface
   -set color
   -line width
   -moveto
   -stroke/fill.

[Joaopmoliveira]

I would like to understand how to commit in a simpler way (this is why I asked about the contributions but I now understand that it could pose a risk to your project).
The tutorial is still not finished. My intent was to first write a sample which can be used without the vkh library API and then from this simple sample/explanation connect a follow up where we dive into surface, context, etc..
Need feedback on how to proceed. If it is the right path forward or not.

[Joaopmoliveira]

The intent of this first sample is to allow someone to copy the code and actually try the changes in the follow up samples and see the results in front of them.
I find this simpler than reading definitions and then trying to put together the code. Especially because we are dealing with Vulkan, which is intended to give so much control to the developer. This would mean that this library (which is already quite mature) should have samples which clearly show what is being used and what is required from the developer no?

[jpbruyere]

You may commit everything to your fork and take the time to make thing exactly as you wanted to. With the pull request active, I will get all your updates in realtime, and we will be able to discuss it in this discussion thread. No matter how long it could take for me to integrate the changes in master.
Or, an other option would be to create a dedicated repository for your tutorials, and I put the address in my front page README, even if the work is in progress. Maybe this second solution is closer to what you expect (having content accessible online quickly).

For the correct path to follow for the tutorials, feel free to explore, test, go forward and rewind. I know that the critics are easy, but the art is difficult (as we say in french). Your style and presentations will improve over time.

I've try the exercise of documenting vkhelpers yesterday, And what I've learned is that is not easy while developments are stil in progress, I've spent half the time in code for improving the api, Such kind of remark from you (missing func, bug, etc...) is surely as important as the final tutorials, because while writing them, you test vkvg and may give me feedback. If you submit push requests for debug, correction, or in code documentation, it will surely be quickly merged.

Don't hesitate to illustrate with screenshots, it's a drawing library, and be direct, without to much ego's (me, you, him,...).