it doesn't matter for silk because we squash anyway, so it just ends up being whatever the PR title
it doesn't matter for silk because we squash anyway, so it just ends up being whatever the PR title is
Lim too lazy to PR in constantly for my personal projects so i commit everything directly to master so like all my projects have a TON of commits
Li also make sure all my commits are small and relavent, so i try to avoid commits like "rewrite everything"
Pin the early days of silk we committed straight to master and just merged everything
Pthese days us maintainers don't even have permission to main unless we really want to
Li would try to get eevee to disable pushing to main on our engine but i dont think they would really wanna go through the effort of PRing everything, seeing as they already dont really care for the commit guidelines
Fcuz as long as it describes what got added/changed/removed its good enough for me
Li tend to want to focus on singular subsystem at a time, so in my git window i filter to just the system im working on, which is very helpful for knowing context behind why things are how it is, ex: the Localization subsystem, which hadnt been touched in like 4 months, i wanted to fix up for use in pTyping, but was confused by my own code, so i sifted through the commits a bit and it helped give a lot of context as to where i was going with it (it was heavily unfinished and unfit for use)
SYou haven't seen my
idk
SWhat about in as silknet analog for vk bootstrap?
Pit doesn't look like much of an analog, rather just a thin wrapper
Pan analog would be something like
SEven if it's a thin wrapper it aims to simplify vulkan startup
Pyeah it does simplify it, but just doesn't have as much "substance" as vkbootstrap does. that's not a bad thing, it honestly depends on the scope of your project, and it's certainly something i'd expect in something called "startup utilities"
Pbut yeah it's more "let me help you configure it how you want" rather than "let me help you out by configuring it with either what you want or some sensible defaults"
KI would still like to change this 
Dwatching the community meeting....
Dalso having a play with veldrid. looks quite interesting. certainly makes using vulkan easier. not sure about any overhead caused by it's API design.
SI moved from veldrid to opengl and then to vulkan
DSomething like Veldrid that let you get to the raw silk API bindings if you wanted would be pretty cool. Forking/porting Veldrid kind of feels rude to me though.
S@techpizza 's fork :P
DYeah, 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? 