Yeah, i know. But they only did vulkan bit right?
Yeah, i know. But they only did vulkan bit right?
SIdk
SI work on vulkan startup utilities for SilkNet
Di had a look around the d3d backend it is using vortice
Dhmm, i am looking in master vulkan using terrafx
Dmaybe silk stuff in a diff branch
Di can't see silk.net anywhere. maybe they changed their mind??
Dhmm, vs2022 has some problems
DAdd new class did this. D:
ROh meant to reply to this, yes it is slow, meant more for debugging purposes right now than actual use
RI am verifying the outputs make actual sense instead of like 1.07686E39 or something that implies I fucked up actually reading the data
Ralso so is using everywhere
SFrom my experience 1.0463829es aren't fucked up values
Rread the value I sent again
R1.07686E39
Ror something like that is what I ended up getting at one point
Rwhich is 1.07686*10^39
Rit was obviously incorrect when wanting a normalized value between zero and one for color....
RShould be fixed now with me using the assimp Querying APIs directly as fiddling with pointers is still something I am not good at :p
Ralso, considering the model I am loading takes 30 seconds to a minute for ASSIMP native code to process directly, it is by far not the slowest thing in this ugly monster of a 250 line long function of crust
RThis mess totally needs cleaned up
S@redhacker2 how many polygons?
RUhh well it is the Bistro outdoor scene
RXD
RThe point is I am working more on getting it running at all, then I will clean it up and remove some of the messy and slow stuff
DThat "add class" issue I mention has been reported multiple times. Apparently fixed in some upcoming update.
Ti moved the vulkan backend to terrafx.interop.vulkan and now it works on android
Ti also improved opengl buffer mapping and reduced overhead for enqueing work
Tand i plan to add dx12 some time in the future (i don't have free time at the moment)
SWhy? 
STo your possible answer "android support": shouldn't silknet work on android too?
Tit did, but i was not satisfied with having to pass a Vk instance around everywhere
Tor that types were not prefixed with Vk
PI do get a little salty when people complain about types not starting with Vk
Pprimarily because this is exactly what namespaces are for
PUse the language properly.
PThat being said, it’ll probably change in 3.0
Dall the vulkan implementation classes in veldrid are prefixed with Vk and some have name clashes with the vulkan bindings it uses. so if i was going to port "all" of veldrid to silk I would probably prefer the silk types weren't prefixed. 
Ryeah
RKinda with him on that front
Rthe passing around a VK instance around everywhere I could see as being slightly annoying though
Rbut not sure how else you would do it either
Lif you wanna be kinda unclean you could static import a class everywhere
Ri.. eww
Di had a look around the code base, everything keeps a ref to the "graphics device" which has the VkInstance as a member. 
Rkinda how I figured they would
Tah yes. _gd.Vk.callwhatever, no thanks
RI mean... you have to have some form of class to access it, you could I guess wrap the instance into a static class that would hide the API instance I guess?
Rbut thats about the best you can do
Tno thanks i'll just use a static import of terrafx