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
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:
> >
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
https://pastebin.com/JxxJufNB
>
> 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 it is used.
What's
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
can anybody tell me why
struct S
{
int x;
alias x this;
}
void test()
{
S s;
s = 8; // this works
S s = 8 // but this does not?
}
gc causes unpredictabilities in performance*. With games it tends to be
worst case performance that matters.
I would reccomend using std.experimental.allocator (even if you still use
the default GC backed allocator). This will allow you to swap out your
allocator for a more specialised one as
The following code is not working for me
float[3] f;
f[] = abs(f)[] * -1.0f;
where abs is a function that returns a float[3];
it complains that f should be attached to some memory.
Is it a bug or am I missing something?
yup figured it out -
module documentation needs to go *above*
the module declaration or you get nothing.
On Fri, Jul 28, 2017 at 11:53 AM, Soulsbane via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:
> On Thursday, 27 July 2017 at 03:01:50 UTC, Danni Coy wrote:
>
>> I am trying
I am trying to build my projects documentation via the ddox system via dub.
It seems that my modules are being documented and then filtered out.
Ironically for a documentation system there isn't a lot of documentation.
What is the minimum I need in order for documentation to show up?
how do I
Can somebody give me a quick example of how to combine the
MMapAllocator with the AllocatorList and the BitmapBlock objects
together?
Lets assume I want to be able to swap in and out allocators none of
which will be the gc_allocator...
What is best practice for using std.experimental.allocator in @nogc code?
13 matches
Mail list logo