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 bi
Am Sat, 19 Mar 2016 01:12:08 +
schrieb Alex Parrill :
> 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 knows them, please tell me, and I'll add them
On Saturday, 19 March 2016 at 01:12:08 UTC, Alex Parrill wrote:
https://github.com/ColonelThirtyTwo/dvulkan
This includes bindings for all extensions, except for the
platform-dependent VK_KHR_*_surface APIs, which require type
declarations from other projects (like X11) that I didn't want
to
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
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 incompat
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
On Sunday, 20 March 2016 at 00:03:16 UTC, Nicholas Wilson wrote:
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 appropriat
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.
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 yo
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 :)
On Monday, 21 March 2016 at 09:27:35 UTC, Manuel Maier wrote:
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
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 c
12 matches
Mail list logo