we just do netstandard 2.1 just incase someone *needs* framework support
we just do netstandard 2.1 just incase someone needs framework support
Plol
Lit does mean we can run our engine on vista though
Lwhich is
Lcool i guess
Psure
L
Pyep
Lso i need to do something to get an intptr, im guess that would be dlopen on linux
V
RI could have swore framework only supported 2.0
Pthis is true
Loh im on 2.0 then
Lmisremembered
L2.0 is the one that goes back to 4.6.1
L
L
Lthis is all inside of a try catch too
Ai don't think try catch catches CLR errors
i've never had any successfully catch any CLR errors lol
i've never had any successfully catch any CLR errors lol
Lweird that the error is at a return though
Pin any case i'm sure there are plentiful resources for vortice support
Lsurprisingly i cant really find anything other then github issues, so i guess ill open one there
Awouldn't the error be caused by the fact that you are trying to run DX on linux?
or are you using DXVK or something like that
or are you using DXVK or something like that
Aorrrr am i misunderstanding what you're trying to do
LDXVK-native
Ai see
Lits why i needed to do a nativelibrary hook, to redirect vortices import of d3d11.dll to /usr/lib/libd3d11.so
OHi all, I'm looking to do some C# development with OpenXR and found the Silk.NET library as a convenient way to get started with this. However, I'm having some trouble finding good documentation for getting started with it. The pages at https://dotnet.github.io/Silk.NET/docs/ are basically just placeholders at this point in time. Can anyone point me in the right direction maybe with some examples as well? My eventual goal is just to use this app to drive various OpenXR haptic devices, so I don't really need a renderer or window
Lit should work about the same as using OpenXR in C, so look for C docs
Lyou can get the OpenXR API using
XR.GetApi i believeOokay, so basically it should be pretty 1 to 1 with the OpenXR api spec, just in C#
Lmostly yes
Ohttps://github.com/dotnet/Silk.NET/blob/7fba589843e118a388bdd261e1b8221e5a7c76b0/src/OpenXR/Silk.NET.OpenXR/Structs/ActionSetCreateInfo.gen.cs#L55
Any particular reason why these are fixed bytes instead of strings?
Any particular reason why these are fixed bytes instead of strings?
GitHub
The high-speed OpenGL, OpenCL, OpenAL, OpenXR, GLFW, SDL, Vulkan, Assimp, and DirectX bindings library your mother warned you about. - Silk.NET/ActionSetCreateInfo.gen.cs at 7fba589843e118a388bdd26...
L¯\_(ツ)_/¯
Lmaybe the spec specified it returns an array of max 64 bytes as a string
Lthen the generator ignored the "as a string" part
O
Lah ye it interpreted a C char* as C# byte array
Lyou can get a string out of it if you get a pointer to the byte array, then use SilkMarshal.PtrToString or smthn
OWell...I need to get a string into it
LSilkMarshal.StringToPtr or smthn then
Ookay I'll look for that - I really do hate C code with all its char* byte stuff
Lyou can also do
Encoding.UTF8.GetBytes(string)Lassuming it wants UTF8
Oyep - the spec defines UTF-8
Lyup then you should be able to clear the array to all null bytes, then fill it with the bytes you get from
Encoding.UTF8.GetBytesOYeah it would be really helpful if this was just a string like it’s supposed to be.
L2.x wont have breaking changes
https://github.com/dotnet/Silk.NET/issues/887
so pop a report here and we'll fix it in 3.0
https://github.com/dotnet/Silk.NET/issues/887
so pop a report here and we'll fix it in 3.0
GitHub
TODO We truly invite everyone to send us reports of any place where our bindings are not ideal. This issue will serve as a list of things we should fix in 3.0.
ENot sure if this is fixable by conventional means (if anything). A char pointer in itself can represent many things because it can be combined with an indexer (
[<index>]) or even C strings on top of being a reference to a single 8 bits value (there's no byte type in C). Even an array of char, which narrows it down some, can be used to represent either strings or binary data in C. Semantic intent is probably gonna be difficult to guess from just the type/signature. C strings also don't hold anything special in memory to tell that we're dealing with a string aside from the null-terminating character (\0 or 0 as an integer value).Lmost of our other bindings have extra data we use to determine type but i guess we didnt have that here, so its not really fixable unless we make that data ourself, find some copy of it, or manually fix all the broken parts
