Re: A ready to use Vulkan triangle example for D
On Friday, 27 May 2016 at 18:40:24 UTC, maik klein wrote: https://github.com/MaikKlein/VulkanTriangleD Another dependency is ErupteD which I have forked myself because there is currently an issue with xlib-d and xcb-d with their versioning. Nice work. As a person still trying to understand modern OpenGL, I admire your jump into Vulkan. Just a quick question if I may; Why did you use ErupteD over say d-vulkan or derelict-vulcan? From my brief perusal of all three, they all seem kind of the same. Thanks.
Re: A ready to use Vulkan triangle example for D
On Saturday, 28 May 2016 at 03:02:23 UTC, WhatMeWorry wrote: On Friday, 27 May 2016 at 18:40:24 UTC, maik klein wrote: https://github.com/MaikKlein/VulkanTriangleD Another dependency is ErupteD which I have forked myself because there is currently an issue with xlib-d and xcb-d with their versioning. Nice work. As a person still trying to understand modern OpenGL, I admire your jump into Vulkan. Just a quick question if I may; Why did you use ErupteD over say d-vulkan or derelict-vulcan? From my brief perusal of all three, they all seem kind of the same. Thanks. derelict-vulcan only works on windows, dvulkan doesn't have the platform dependend surface extensions for xlib, xcb, w32 and wayland. Without them Vulkan is unusable for me. I really don't care what I use, I just wanted something that works.
Re: A ready to use Vulkan triangle example for D
On Saturday, 28 May 2016 at 10:58:05 UTC, maik klein wrote: derelict-vulcan only works on windows, dvulkan doesn't have the platform dependend surface extensions for xlib, xcb, w32 and wayland. Without them Vulkan is unusable for me. I really don't care what I use, I just wanted something that works. Platform extension support will be in the next release of d-vulkan. It doesn't include platform extensions now because I wanted to find a way to implement it without tying d-vulkan to a specific set of bindings, though I can't seem to find a good solution unfortunately... I personally use the git version of GLFW, which handles the platform-dependent surface handling for me. As for the demo itself... It might help explain things more if the separate stages (instance creation, device creation, setting up shaders, etc) were split into their own functions, instead of stuffing everything into `main`. Struct initializers are also useful when dealing with Vulkan info structs, since you don't have to repeat the variable name each time. Ex this: VkPipelineVertexInputStateCreateInfo vertexInputStateCreateInfo = {}; vertexInputStateCreateInfo.sType = VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_STATE_CREATE_INFO; vertexInputStateCreateInfo.vertexBindingDescriptionCount = 1; vertexInputStateCreateInfo.pVertexBindingDescriptions = &vertexBindingDescription; vertexInputStateCreateInfo.vertexAttributeDescriptionCount = 1; vertexInputStateCreateInfo.pVertexAttributeDescriptions = &vertexAttributeDescritpion; Can become: VkPipelineVertexInputStateCreateInfo vertexInputStateCreateInfo = { sType = VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_STATE_CREATE_INFO, // also sType is pre-set with erupted or d-derelict vertexBindingDescriptionCount = 1, pVertexBindingDescriptions = &vertexBindingDescription, vertexAttributeDescriptionCount = 1, pVertexAttributeDescriptions = &vertexAttributeDescritpion, };
Re: A ready to use Vulkan triangle example for D
On Saturday, 28 May 2016 at 17:50:30 UTC, Alex Parrill wrote: On Saturday, 28 May 2016 at 10:58:05 UTC, maik klein wrote: derelict-vulcan only works on windows, dvulkan doesn't have the platform dependend surface extensions for xlib, xcb, w32 and wayland. Without them Vulkan is unusable for me. I really don't care what I use, I just wanted something that works. Platform extension support will be in the next release of d-vulkan. It doesn't include platform extensions now because I wanted to find a way to implement it without tying d-vulkan to a specific set of bindings, though I can't seem to find a good solution unfortunately... I personally use the git version of GLFW, which handles the platform-dependent surface handling for me. As for the demo itself... It might help explain things more if the separate stages (instance creation, device creation, setting up shaders, etc) were split into their own functions, instead of stuffing everything into `main`. Struct initializers are also useful when dealing with Vulkan info structs, since you don't have to repeat the variable name each time. Ex this: VkPipelineVertexInputStateCreateInfo vertexInputStateCreateInfo = {}; vertexInputStateCreateInfo.sType = VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_STATE_CREATE_INFO; vertexInputStateCreateInfo.vertexBindingDescriptionCount = 1; vertexInputStateCreateInfo.pVertexBindingDescriptions = &vertexBindingDescription; vertexInputStateCreateInfo.vertexAttributeDescriptionCount = 1; vertexInputStateCreateInfo.pVertexAttributeDescriptions = &vertexAttributeDescritpion; Can become: VkPipelineVertexInputStateCreateInfo vertexInputStateCreateInfo = { sType = VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_STATE_CREATE_INFO, // also sType is pre-set with erupted or d-derelict vertexBindingDescriptionCount = 1, pVertexBindingDescriptions = &vertexBindingDescription, vertexAttributeDescriptionCount = 1, pVertexAttributeDescriptions = &vertexAttributeDescritpion, }; I think its personal preference, I like tutorials more if everything I just in the main instead of creating their own "architecture". Though I could probably group with comments. I saw that sType was a default value after a few hours and that is when I started using it. But at the end I was so annoyed by typing all the enums by hand that I mostly copied stuff from other people and translated it to D. This was mostly caused by my current vim D setup with vim-dutyl and dcd, it is really unreliable and I didn't get any sane autocompletion. (I have to investigate that at some point). Btw does this even work? I think the struct initializers have to be Foo foo = { someVar: 1 }; `:` instead of a `=` I didn't do this because I actually got autocompletion for `vertexInputStateCreateInfo.` and that meant less typing for me.
Re: A ready to use Vulkan triangle example for D
On Saturday, 28 May 2016 at 19:32:58 UTC, maik klein wrote: Btw does this even work? I think the struct initializers have to be Foo foo = { someVar: 1 }; `:` instead of a `=` I didn't do this because I actually got autocompletion for `vertexInputStateCreateInfo.` and that meant less typing for me. No, its equals. In C it's a colon, which is a tad confusing.
Re: A ready to use Vulkan triangle example for D
On Sunday, 29 May 2016 at 00:37:54 UTC, Alex Parrill wrote: On Saturday, 28 May 2016 at 19:32:58 UTC, maik klein wrote: Btw does this even work? I think the struct initializers have to be Foo foo = { someVar: 1 }; `:` instead of a `=` I didn't do this because I actually got autocompletion for `vertexInputStateCreateInfo.` and that meant less typing for me. No, its equals. In C it's a colon, which is a tad confusing. https://dpaste.dzfl.pl/bd29c970050a
Re: A ready to use Vulkan triangle example for D
On Sunday, 29 May 2016 at 00:42:56 UTC, maik klein wrote: On Sunday, 29 May 2016 at 00:37:54 UTC, Alex Parrill wrote: On Saturday, 28 May 2016 at 19:32:58 UTC, maik klein wrote: Btw does this even work? I think the struct initializers have to be Foo foo = { someVar: 1 }; `:` instead of a `=` I didn't do this because I actually got autocompletion for `vertexInputStateCreateInfo.` and that meant less typing for me. No, its equals. In C it's a colon, which is a tad confusing. https://dpaste.dzfl.pl/bd29c970050a Gah, I got them backwards. Colon in D, equals in C. Could have sworn I checked before I posted that...
Re: A ready to use Vulkan triangle example for D
On Fri, 27 May 2016 18:40:24 +, maik klein wrote: > https://github.com/MaikKlein/VulkanTriangleD > > Currently only Linux is supported but it should be fairly easy to > also add Windows support. Only the surface extensions have to be > changed. > > The example requires Vulkan ready hardware + driver + LunarG sdk > with validation layer + sdl2. Nice, runs without errors for me. I have a triangle example project too, but weird stuff happens when I resize my window. I see your window has fixed size, maybe I have more luck adding window resizing to your example. Will tell you when I get it to work. Does anyone here have a working vulkan window with a resizable window? I think its more of an xcb issue than a vulkan issue in my code, because even when I do - create xcb window with dimensions (w1, h1) - resize it to dimensions (w2, h2) (no vulkan interaction yet) - create a vulkan surface from that window - render the rendered image still has the original size (w1, h1), and I loose my vulkan device when (w2, h2) deviates too much from the original size.
Re: A ready to use Vulkan triangle example for D
On Monday, 30 May 2016 at 11:30:24 UTC, Manuel König wrote: On Fri, 27 May 2016 18:40:24 +, maik klein wrote: [...] Nice, runs without errors for me. I have a triangle example project too, but weird stuff happens when I resize my window. I see your window has fixed size, maybe I have more luck adding window resizing to your example. Will tell you when I get it to work. Does anyone here have a working vulkan window with a resizable window? I think its more of an xcb issue than a vulkan issue in my code, because even when I do - create xcb window with dimensions (w1, h1) - resize it to dimensions (w2, h2) (no vulkan interaction yet) - create a vulkan surface from that window - render the rendered image still has the original size (w1, h1), and I loose my vulkan device when (w2, h2) deviates too much from the original size. You probably have to update a lot of code https://github.com/MaikKlein/VulkanTriangleD/blob/master/source/app.d Do a ctrl+f vkcontext.width and you will see all the code that needs to be updated.
Re: A ready to use Vulkan triangle example for D
I now have initial window resizing added to your example: https://github.com/Manuel-Koenig/VulkanTriangleD It's still pretty much your code, but I structured it into several functions. Window resizing does work in the sense that the triangle gets stretched and redrawn, but the validation layer is still complaining.