Re: having troubles with D and Vulkan.

ork! Now I can rest in peace tonight. :D Same for me :) Great to see folks working in Vulkan with D.

Re: having troubles with D and Vulkan.

On Thursday, 20 July 2023 at 06:27:13 UTC, Danni Coy wrote: ok found it, I am an idiot, (really not used to working with dynamic libraries). erupted needs a call to load device level functions. loadDeviceLevelFunctions(instance); On Thu, Jul 20, 2023 at 4:22 PM Danni Coy wrote:

Re: having troubles with D and Vulkan.

ok found it, I am an idiot, (really not used to working with dynamic libraries). erupted needs a call to load device level functions. loadDeviceLevelFunctions(instance); On Thu, Jul 20, 2023 at 4:22 PM Danni Coy wrote: > > https://pastebin.com/Jc9ZaFFs > Redid the code as an almost exact

Re: having troubles with D and Vulkan.

https://pastebin.com/Jc9ZaFFs Redid the code as an almost exact translation of the C code. should be easier to test and compare. Same issue is occurring. On Thu, Jul 20, 2023 at 5:30 AM Mike Shah via Digitalmars-d-learn wrote: > > On Wednesday, 19 July 2023 at 07:39:35 UTC, Danni Coy wrote: > >

Re: having troubles with D and Vulkan.

On Thu, Jul 20, 2023 at 5:30 AM Mike Shah via Digitalmars-d-learn wrote: > > On Wednesday, 19 July 2023 at 07:39:35 UTC, Danni Coy wrote: > > https://pastebin.com/JxxJufNB > > What platform are you using, and how are you trying to build? > > I can try to replicate on my end. I am on Manjaro

Re: having troubles with D and Vulkan.

On Wednesday, 19 July 2023 at 07:39:35 UTC, Danni Coy wrote: https://pastebin.com/JxxJufNB What platform are you using, and how are you trying to build? I can try to replicate on my end.

Re: having troubles with D and Vulkan.

https://pastebin.com/JxxJufNB

Re: having troubles with D and Vulkan.

> > I was able to get through the triangle demo a while back. I feel > like it's more of a D question than a Vulkan library question. > You'll have to post your code so people can tell what it is. Just > a hunch, but it's probably something that the gc is collecting > before i

Re: having troubles with D and Vulkan.

On Wednesday, 19 July 2023 at 02:50:05 UTC, Danni Coy wrote: I am trying to run through the basic Vulkan triangle demo. I am getting stuck at vkGetDeviceQueue which segfaults for me. I have written the same tutorial to about the same point in C and I am not getting the segfault. I have

having troubles with D and Vulkan.

I am trying to run through the basic Vulkan triangle demo. I am getting stuck at vkGetDeviceQueue which segfaults for me. I have written the same tutorial to about the same point in C and I am not getting the segfault. I have enabled validation layers and they are not picking up anything. Any

Re: CalderaD - SDL2 Vulkan renderer for windows, linux, and android

On Thursday, 27 May 2021 at 10:12:43 UTC, Danny Arends wrote: On Friday, 14 May 2021 at 21:12:55 UTC, Imperatorn wrote: On Friday, 14 May 2021 at 16:39:53 UTC, Danny Arends wrote: [...] Nice! Is it on dub as well? No not yet, It's still very very early for that I think. I was hoping to

Re: CalderaD - SDL2 Vulkan renderer for windows, linux, and android

On Friday, 14 May 2021 at 21:12:55 UTC, Imperatorn wrote: On Friday, 14 May 2021 at 16:39:53 UTC, Danny Arends wrote: Dear all, I'm proud to announce CalderaD, yet another SDL2 Vulkan renderer in the D Programming Language. However, this one will work on Windows, Linux, and even Android

Re: CalderaD - SDL2 Vulkan renderer for windows, linux, and android

On Friday, 14 May 2021 at 16:39:53 UTC, Danny Arends wrote: Dear all, I'm proud to announce CalderaD, yet another SDL2 Vulkan renderer in the D Programming Language. However, this one will work on Windows, Linux, and even Android. The current 'engine' is based on the excellent vulkan

Re: CalderaD - SDL2 Vulkan renderer for windows, linux, and android

On Friday, 14 May 2021 at 17:38:54 UTC, Danny Arends wrote: On Friday, 14 May 2021 at 17:29:13 UTC, evilrat wrote: On Friday, 14 May 2021 at 16:39:53 UTC, Danny Arends wrote: Find the GPL-v3 licensed code here: https://github.com/DannyArends/CalderaD You can set up platform filters in

Re: CalderaD - SDL2 Vulkan renderer for windows, linux, and android

On Friday, 14 May 2021 at 17:38:54 UTC, Danny Arends wrote: Hmm, things gotta have a license, why not GPL would CC0 be better? is attribution and sharing code so weird ? I think: "license": "proprietary" also doesn't sound very inviting It's a WIP tutorial project. It is not finished yet.

Re: CalderaD - SDL2 Vulkan renderer for windows, linux, and android

On Friday, 14 May 2021 at 17:38:54 UTC, Danny Arends wrote: Hmm, things gotta have a license, why not GPL would CC0 be better? is attribution and sharing code so weird ? GPL is a perfectly fine license. If people don't want to use it because of that, their loss, not your problem.

Re: CalderaD - SDL2 Vulkan renderer for windows, linux, and android

On Friday, 14 May 2021 at 17:29:13 UTC, evilrat wrote: On Friday, 14 May 2021 at 16:39:53 UTC, Danny Arends wrote: Find the GPL-v3 licensed code here: https://github.com/DannyArends/CalderaD You can set up platform filters in dub to automatically match target platforms without specifying

Re: CalderaD - SDL2 Vulkan renderer for windows, linux, and android

On Friday, 14 May 2021 at 16:39:53 UTC, Danny Arends wrote: Find the GPL-v3 licensed code here: https://github.com/DannyArends/CalderaD You can set up platform filters in dub to automatically match target platforms without specifying configuration for build. See this

Re: SDL2 Android vulkan question

On Sunday, 2 May 2021 at 13:43:11 UTC, evilrat wrote: Anyway, I might try to look at this next weekend. Do you have this project available on github/google drive? Open-sourced the code see: https://github.com/DannyArends/CalderaD Danny

CalderaD - SDL2 Vulkan renderer for windows, linux, and android

Dear all, I'm proud to announce CalderaD, yet another SDL2 Vulkan renderer in the D Programming Language. However, this one will work on Windows, Linux, and even Android. The current 'engine' is based on the excellent vulkan-tutorial.com, and uses SDL2 via the bindbc-sdl bindings for cross

Re: SDL2 Android vulkan question

On Sunday, 2 May 2021 at 16:42:07 UTC, evilrat wrote: On Sunday, 2 May 2021 at 16:06:10 UTC, Danny Arends wrote: On Sunday, 2 May 2021 at 12:35:51 UTC, evilrat wrote: As for SDL2, are you sure it was built with Vulkan support? That's the thing I worry about, since the SDL2 libraries

Re: SDL2 Android vulkan question

On Sunday, 2 May 2021 at 16:06:10 UTC, Danny Arends wrote: On Sunday, 2 May 2021 at 12:35:51 UTC, evilrat wrote: As for SDL2, are you sure it was built with Vulkan support? That's the thing I worry about, since the SDL2 libraries are locally build using android studio and I'm kind of a noob

Re: SDL2 Android vulkan question

On Sunday, 2 May 2021 at 13:43:11 UTC, evilrat wrote: On Sunday, 2 May 2021 at 12:35:51 UTC, evilrat wrote: On Sunday, 2 May 2021 at 08:58:30 UTC, Danny Arends wrote: Any thoughts on why loading the Vulkan library using SDL2 would not work ? thoughts in general about the process ? Just few

Re: SDL2 Android vulkan question

On Sunday, 2 May 2021 at 12:35:51 UTC, evilrat wrote: On Sunday, 2 May 2021 at 08:58:30 UTC, Danny Arends wrote: Any thoughts on why loading the Vulkan library using SDL2 would not work ? thoughts in general about the process ? Just few tips. GC "crashes" since you have cust

Re: SDL2 Android vulkan question

On Sunday, 2 May 2021 at 12:35:51 UTC, evilrat wrote: On Sunday, 2 May 2021 at 08:58:30 UTC, Danny Arends wrote: Any thoughts on why loading the Vulkan library using SDL2 would not work ? thoughts in general about the process ? Just few tips. GC "crashes" since you have cust

Re: SDL2 Android vulkan question

On Sunday, 2 May 2021 at 08:58:30 UTC, Danny Arends wrote: Any thoughts on why loading the Vulkan library using SDL2 would not work ? thoughts in general about the process ? Just few tips. GC "crashes" since you have custom main, D default main has runtime initialization code s

SDL2 Android vulkan question

-threading issues. Since OpenGL is abandoned, I am currently adding Vulkan support to future proof it. I have done this in D with the help of the bindbc-sdl and erupted packages and managed to get the whole vulkan-tutorial.com example working under windows without much hassle. (I bet it would

Re: BetterC issues with ErupteD Vulkan binding typedef handles

[snip] Forgot to add another question. The mentioned error message is not too helpful in locating the real offended code. Is there a way to get more information or additional hints about the actual cause of the problem?

Re: BetterC issues with ErupteD Vulkan binding typedef handles

On Sunday, 20 December 2020 at 15:52:39 UTC, Adam D. Ruppe wrote: On Sunday, 20 December 2020 at 15:45:59 UTC, ParticlePeter wrote: VkSemaphore[] wait_semaphores = [], // error: TypeInfo required does it still error if you just use = null? they work the same way but

Re: BetterC issues with ErupteD Vulkan binding typedef handles

On Sunday, 20 December 2020 at 15:45:59 UTC, ParticlePeter wrote: VkSemaphore[] wait_semaphores = [], // error: TypeInfo required does it still error if you just use = null? they work the same way but might avoid the annoying error.

BetterC issues with ErupteD Vulkan binding typedef handles

Hello, I am experimenting with betterC and Vulkan through Erupted [0] binding, but unfortunately I find myself hunting down these kind of errors: ..\ErupteD\source\erupted\types.d-mixin-77(77,1): Error: `TypeInfo` cannot be used with -betterC The issue is with Vulkan type handles. One

ErupteD v2.0 + Vulkan v1.1 breaking changes and NEW transition strategy

The deprecated ErupteD was un-deprecated again. Version v2.0 comes with Vulkan 1.1 support and breaking changes regarding its dependency mechanism. Details in the projects dub and github [0] pages. Regarding [1]: ErupteD-V1 will be destroyed, ErupteD-V2 continued to implement a valid

Re: Vulkan ErupteD breaking changes and transition strategy

a proper automation and testing system in place. There will be a separate announcement, when ErupteD v2.0.0 reaches vulkan 1.1 status.

Re: Vulkan ErupteD breaking changes and transition strategy

`-bugfix.1` will be a binding to vulkan v1.1.71? That doesn't make any sense. Actually, for me it does, afaik we can put whatever into the pre-release names, so this would work for me: v1.1.71-bugfix.1.1.70.1 It informs me that v1.1.71 is on its way but we are fixing 1.1.70 bugs before that.

Re: Vulkan ErupteD breaking changes and transition strategy

in it. Well, I am interested in it - Vulkan is cool and so is D. Here I was hoping for a little more attentive reading, the bugfix (if any bugs happen in the end) for v1.1.70 would be v1.1.71 (as in "point seven ONE") -bugfix.1. I would hope for community colaboration to always use prerelease

Re: Vulkan ErupteD breaking changes and transition strategy

) 2. Start versioning from 2.0.0 increasing MINOR when new Vulkan version is supported and increasing PATCH when bug fixes happen. Metadata can be added too. This way users are going to always get latest version possible. It'll look like this: 2.0.0+1.0.69 2.0.1+1.0.69 - first bugfix 2.1.0+1.

Re: Vulkan ErupteD breaking changes and transition strategy

semver. You shouldn't just use Vulkan's versions. If you release 1.0.69 which contains bindings to Vulkan 1.0.69 and there is a bug in the binding which you want to fix, you have to increase PATCH number which results in 1.0.70 which (obviously) is not a binding to Vulkan 1.0.70. The bug

Re: Vulkan ErupteD breaking changes and transition strategy

1.0.69 which contains bindings to Vulkan 1.0.69 and there is a bug in the binding which you want to fix, you have to increase PATCH number which results in 1.0.70 which (obviously) is not a binding to Vulkan 1.0.70. The bug then is not in ErupteD but in its generator. It needs to be fixed

Re: Vulkan ErupteD breaking changes and transition strategy

- Changing how binding works, Vulkan v1.0.69 2.1.0 - Vulkan 1.0.70 ...And so on. This way semver is followed and you don't have to mess with erupted-v1 and erupted-v2 repos. Also note that SemVer allows to attach meta data: 2.0.0+1.0.69 That'll work too, but I'm not sure how dub handles it. Anyway

Re: Vulkan ErupteD breaking changes and transition strategy

On Monday, 26 March 2018 at 07:51:31 UTC, Seb wrote: On Monday, 26 March 2018 at 07:04:00 UTC, Anton Fediushin wrote: This is a *bad* idea and you shouldn't do that. Just increase MAJOR version and start from there: 2.0.0 - Changing how binding works, Vulkan v1.0.69 2.1.0 - Vulkan 1.0.70

Re: Vulkan ErupteD breaking changes and transition strategy

On Monday, 26 March 2018 at 07:04:00 UTC, Anton Fediushin wrote: This is a *bad* idea and you shouldn't do that. Just increase MAJOR version and start from there: 2.0.0 - Changing how binding works, Vulkan v1.0.69 2.1.0 - Vulkan 1.0.70 ...And so on. This way semver is followed and you don't

Re: Vulkan ErupteD breaking changes and transition strategy

will be further developed. The breaking changes and Vulkan 1.1 are implemented in ErupteD-V2 [2]. At some future point ErupteD will be destroyed and recreated with all releases of ErupteD-V2 [3]. Two issues bugged me with the previous design of the binding: 1. versions are not only disconnected from

Vulkan ErupteD breaking changes and transition strategy

ErupteD [0] is deprecated (one of its major modules). The project content is supposed to be replaced completely. Current state was copied into ErupteD-V1 [1] (without deprecation message), neither ErupteD nor ErupteD-V1 will be further developed. The breaking changes and Vulkan 1.1

Re: Vulkan

On Tuesday, 13 February 2018 at 22:20:15 UTC, Ivan Trombley wrote: I wanted to do some experimentation with Vulkan using D. None of the projects that I found (derelict-vulkan, d-vulkan and erupted) work. Are there D bindings to Vulkan that actually work? I had success using Vulkan

Re: Vulkan

On Saturday, 17 February 2018 at 05:52:38 UTC, Jonathan M Davis wrote: Well, in D-speak, C header definitions rewritten as D so that D can call the C functions are exactly what bindings are, whereas if bindings are wrapped in D code to make them more D-like, those are called wrappers. I

Re: Vulkan

at 8:20 AM, Ivan Trombley via Digitalmars-d < > >> > >> digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote: > >> I wanted to do some experimentation with Vulkan using D. None of > >> the > >> projects that I found (de

Re: Vulkan

t;mailto:digitalmars-d@puremagic.com>> wrote: >> >> I wanted to do some experimentation with Vulkan using D. None of the >> projects that I found (derelict-vulkan, d-vulkan and erupted) work. >> >> Are there D bindings to Vulkan that actually work? &g

Re: Vulkan

it can be fixed. Derelict-vulkan is Windows only ATM. The only difference is the one specific function for creating the surface. You are better off using something like SDL2 for creating the window anyways, which takes care of the only OS specific code of vulkan. None of the types also

Re: Vulkan

it can be fixed. Derelict-vulkan is Windows only ATM. Actually someone added posix support. Just forgot to flag a new release. (I did not test posix support myself yet). If there are other issues please file them on GitHub.

Re: Vulkan

On Wednesday, 14 February 2018 at 00:22:25 UTC, flamencofantasy wrote: Maybe these work, not sure; https://github.com/Rikarin/VulkanizeD Thanks, I'll check this out.

Re: Vulkan

On Wednesday, 14 February 2018 at 02:40:18 UTC, Mike Parker wrote: What [does] it mean to say they don't work? Have you reported any issues? I don't see any in the DerelictVulkan repo. If something's broken, please report it so it can be fixed. Derelict-vulkan is Windows only ATM.

Re: Vulkan

On 13/02/2018 10:54 PM, Danni Coy wrote: On Wed, Feb 14, 2018 at 8:20 AM, Ivan Trombley via Digitalmars-d <digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote: I wanted to do some experimentation with Vulkan using D. None of the projects that I fou

Re: Vulkan

On Wednesday, 14 February 2018 at 02:40:18 UTC, Mike Parker wrote: What doesn't it mean Eh, what *does* it mean.

Re: Vulkan

On Tuesday, 13 February 2018 at 22:20:15 UTC, Ivan Trombley wrote: I wanted to do some experimentation with Vulkan using D. None of the projects that I found (derelict-vulkan, d-vulkan and erupted) work. Are there D bindings to Vulkan that actually work? What doesn't it mean to say

Re: Vulkan

On Tuesday, 13 February 2018 at 22:20:15 UTC, Ivan Trombley wrote: I wanted to do some experimentation with Vulkan using D. None of the projects that I found (derelict-vulkan, d-vulkan and erupted) work. Are there D bindings to Vulkan that actually work? Maybe these work, not sure; https

Re: Vulkan

On Wed, Feb 14, 2018 at 8:20 AM, Ivan Trombley via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > I wanted to do some experimentation with Vulkan using D. None of the > projects that I found (derelict-vulkan, d-vulkan and erupted) work. > > Are there D bindings to Vulkan

Vulkan

I wanted to do some experimentation with Vulkan using D. None of the projects that I found (derelict-vulkan, d-vulkan and erupted) work. Are there D bindings to Vulkan that actually work?

Weekend Project: Vulkan-DPP

Hi All, I am toying with the idea to use https://github.com/KhronosGroup/Vulkan-Hpp to target the D language. I haven't started it yet, but would like to hear people's thought and opinion on it. My goal is learning about vulkan and D in general. The existing wrappers we have namely

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

Re: A ready to use Vulkan triangle example for D

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

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

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

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

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

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

Re: A ready to use Vulkan triangle example for 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

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.

A ready to use Vulkan triangle example for D

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. Another

Re: Discuss vulkan erupted, the other auto-generated vulkan binding

Test worked, now supporting dub packages xcb-d, xlib-d, wayland-client-d.

Re: d-vulkan, automatically generated D bindings for Vulkan

On Saturday, 19 March 2016 at 01:12:08 UTC, Alex Parrill wrote: https://github.com/ColonelThirtyTwo/dvulkan I've updated the bindings to Vulkan 1.0.13, and added a few fixes. Platform support will come in a bit. I'm going to use void* pointers for most of the platform-specific types, so you

Re: Discuss vulkan erupted, the other auto-generated vulkan binding

On Friday, 20 May 2016 at 18:52:35 UTC, maik klein wrote: On Thursday, 19 May 2016 at 15:44:27 UTC, ParticlePeter wrote: I am a bit slow, how do I add xcb as a dependency? /source/erupted/types.d(3335,16): Error: module xcb is in file 'xcb/xcb.d' which cannot be read Can I add dependencies

Re: Discuss vulkan erupted, the other auto-generated vulkan binding

On Thursday, 19 May 2016 at 15:44:27 UTC, ParticlePeter wrote: On Wednesday, 18 May 2016 at 20:28:09 UTC, Manuel König wrote: [...] As far as I understand Mike it is still possible. Suppose you build an engine based on (d-)vulkan/erupted, lets call it Turtle-Engine, you would also specify

Re: Discuss vulkan erupted, the other auto-generated vulkan binding

ut this is probably just a pathetic use case not relevant in practice, I just stumbled over the question if that is possible when I wanted to add proper xcb, xlib, etc. support to erupteD. As far as I understand Mike it is still possible. Suppose you build an engine based on (d-)vulkan/erupted

Re: Discuss vulkan erupted, the other auto-generated vulkan binding

this in the d-vulkan issues.

Re: Discuss vulkan erupted, the other auto-generated vulkan binding

On Monday, 16 May 2016 at 12:10:58 UTC, ParticlePeter wrote: This is in respect to announce thread: https://forum.dlang.org/post/mdpjqdkenrnuxvruw...@forum.dlang.org Please let me know if you had the chance to test the functionality as requested in the announce thread. All other question are

Re: Discuss vulkan erupted, the other auto-generated vulkan binding

Am Wed, 18 May 2016 18:57:48 + schrieb ParticlePeter : > On Wednesday, 18 May 2016 at 15:09:50 UTC, Mike Parker wrote: > > On Wednesday, 18 May 2016 at 13:26:14 UTC, Manuel König wrote: > > > >> I think I will use glfw3 later. I don't know if the original > >> problem

Re: Discuss vulkan erupted, the other auto-generated vulkan binding

On Wednesday, 18 May 2016 at 15:09:50 UTC, Mike Parker wrote: On Wednesday, 18 May 2016 at 13:26:14 UTC, Manuel König wrote: I think I will use glfw3 later. I don't know if the original problem of using multiple configurations (xcb, xlib, glfw3, ...) is possible with only dub's internal

Re: Discuss vulkan erupted, the other auto-generated vulkan binding

On Wednesday, 18 May 2016 at 13:26:14 UTC, Manuel König wrote: I think I will use glfw3 later. I don't know if the original problem of using multiple configurations (xcb, xlib, glfw3, ...) is possible with only dub's internal logic. I tried putting this in my "vulkantest" packages' dub.json

Re: Discuss vulkan erupted, the other auto-generated vulkan binding

On, 18 May 2016 04:51:10 +, ParticlePeter wrote: > > > > Sounds reasonable, picking a subconfig is definitely easier to > > use and implement. I was looking into that too, the only > > nitpicking I have is that it sounded like you can't select > > multiple

Re: Discuss vulkan erupted, the other auto-generated vulkan binding

On Tuesday, 17 May 2016 at 16:17:39 UTC, Manuel König wrote: had to update the function loading names I chose differently. This bugged me a little, v1.1.0 has the EruptedLoader struct removed so that the loading functions are called without EruptedLoader. prefix and can be renamed at

Re: Discuss vulkan erupted, the other auto-generated vulkan binding

ther note, while I like the creative package naming, it may not be very easy for search engines to pick up or recognize by potential users as vulkan bindings. The project is still new, but gooogle and duckduckgo don't find erupteD when searching for "dlang vulkan", but they do find derelic

Re: Discuss vulkan erupted, the other auto-generated vulkan binding

be added. But I'll have to try that for myself. On another note, while I like the creative package naming, it may not be very easy for search engines to pick up or recognize by potential users as vulkan bindings. The project is still new, but gooogle and duckduckgo don't find erupteD when searching for &qu

Re: Discuss vulkan erupted, the other auto-generated vulkan binding

into it. In your triangle vulkan project add the path to xcb.xcb.d and xcb-d to "sourcePaths" and "importPaths". Erupted might pick it up. Another way would be, and I think I'll go for it, that I add dub platform configurations. In your case it would be: "subConfigurations":

Re: Discuss vulkan erupted, the other auto-generated vulkan binding

are welcome here as well of course. Cheers, ParticlePeter Cool stuff! I think I'll try this out soon on Posix. My Nvidia driver should in theory support Vulkan already.

Re: Discuss vulkan erupted, the other auto-generated vulkan binding

Hi, Kalua here :) First, thanks again for fixing vulkanizeD, now I don't have to use my locally patched version anymore ;) Giving you some input for how your lib works on my posix sytem (arch linux): My simple triangle drawing program works with your lib, I only had to update the function

Discuss vulkan erupted, the other auto-generated vulkan binding

This is in respect to announce thread: https://forum.dlang.org/post/mdpjqdkenrnuxvruw...@forum.dlang.org Please let me know if you had the chance to test the functionality as requested in the announce thread. All other question are welcome here as well of course. Cheers, ParticlePeter

Re: Anonther auto-generated vulkan binding

Please discuss here: https://forum.dlang.org/post/mclrqnwwrhmbxumgj...@forum.dlang.org

Anonther auto-generated vulkan binding

ErupteD is based on D-Vulkan, but goes further: * Platform surface extensions * DerelictLoader for Posix Systems * With respect to [API without Secrets](https://software.intel.com/en-us/api-without-secrets-introduction-to-vulkan-part-1) D-Vulkan function loading system is partially broken

Re: d-vulkan, automatically generated D bindings for Vulkan

and not in D? Just curious :) I see now... The Vulkan docs provide python modules for easier integration already. Makes sense.

Re: d-vulkan, automatically generated D bindings for Vulkan

On Saturday, 19 March 2016 at 01:12:08 UTC, Alex Parrill wrote: https://github.com/ColonelThirtyTwo/dvulkan [...] @Alex Parrill: Thanks for sharing! Looks nice. I was just wondering... why did you write the generator in python and not in D? Just curious :)

Re: d-vulkan, automatically generated D bindings for Vulkan

On Sunday, 20 March 2016 at 00:52:48 UTC, Alex Parrill wrote: If I import a xcb_connection_t from some bindings, it ties d-vulkan to those bindings, which I'd rather not do. By the magic of D: version (Linux) { import xcb.xcb; } ... version (Linux) { xcb_connection_t* con; } Also

d-vulkan, automatically generated D bindings for Vulkan

https://github.com/ColonelThirtyTwo/dvulkan I know there are a few other bindings for Vulkan around, but I didn't see one that generated the bindings from the XML spec, so I made d-vulkan. The included vkdgen.py script leverages the spec parser included in the Vulkan-Docs repo to generate D

Re: d-vulkan, automatically generated D bindings for Vulkan

On Sunday, 20 March 2016 at 00:52:48 UTC, Alex Parrill wrote: If I import a xcb_connection_t from some bindings, it ties d-vulkan to those bindings, which I'd rather not do. really? It would be a 1 line change. Or alternatively tell the user to import their own bindings.

Re: d-vulkan, automatically generated D bindings for Vulkan

;` in the version block, then that type will be different than the xcb_connection_t declared in the XCB bindings that the developer is likely using, and thus they will be incompatible. If I import a xcb_connection_t from some bindings, it ties d-vulkan to those bindings, which I'd rather not do.

Re: d-vulkan, automatically generated D bindings for Vulkan

On Saturday, 19 March 2016 at 19:37:38 UTC, Alex Parrill wrote: On Saturday, 19 March 2016 at 12:57:18 UTC, Nicholas Wilson wrote: On Saturday, 19 March 2016 at 01:12:08 UTC, Alex Parrill wrote: Should be doable using appropriate version blocks. The problem is that I'd have to define my own

Re: d-vulkan, automatically generated D bindings for Vulkan

On Saturday, 19 March 2016 at 12:57:18 UTC, Nicholas Wilson wrote: On Saturday, 19 March 2016 at 01:12:08 UTC, Alex Parrill wrote: Should be doable using appropriate version blocks. The problem is that I'd have to define my own structs (Xlib Display, Xlib Window, etc), which will be

Re: d-vulkan, automatically generated D bindings for Vulkan

On 19/03/16 13:57, Nicholas Wilson wrote: Afaik OSX doesn't support vulkan, due to Apple's metal. Seems someone is creating a Vulkan wrapper around Metal: https://moltengl.com/moltenvk/ -- /Jacob Carlborg

Re: d-vulkan, automatically generated D bindings for Vulkan

to include. The platform-independent VK_KHR_surface extension is available, however. Should be doable using appropriate version blocks. (Currently the Derelict loader only works in Windows because I don't know the library names for Vulkan on Linux or OSX; if anyone knows them, please tell me

Re: d-vulkan, automatically generated D bindings for Vulkan

Am Sat, 19 Mar 2016 01:12:08 + schrieb Alex Parrill <initrd...@gmail.com>: > https://github.com/ColonelThirtyTwo/dvulkan > [...] > > (Currently the Derelict loader only works in Windows because I > don't know the library names for Vulkan on Linux or OSX; if > anyone

Re: D Vulkan API

On Tuesday, 1 March 2016 at 11:33:26 UTC, Nicholas Wilson wrote: So i've spent the last few days making more D feeling bindings for vulkan, based off Satoshi's because going strait from the spec was a PITA and very inconsistent, and they're almost done. I would like to request some feedback

  1   2   >