a lot of people learning vulkan will have the base knowledge of opengl
a lot of people learning vulkan will have the base knowledge of opengl
Pnot everyone, but a lot of people
DI mean the thing is you don't really need it. The only thing the tutorial does is give you some ropes to not give up immediately, for the most part it'll be understanding the basics of Vulkan, and then you can just do whatever you want with the api. (that's what I ment with normalized difficulty, its all the same)
DBut yeah I get it for sure
DI mean they will always have a bit of a problem. GL is just quite different.
DAnyways, gotta go to bed now, see ya
Pbaii
Pso the issue kinson is getting (which may or may not be related to this, haven't seen code yet but just a gut feeling) reminded me of the implicit in woes we recently had:
Pimplicit in is just far too dangerous
DI don't think so - this is just GL being interesting
Dwe will have the SilkTouch overloading system have a config, so if you think the Span/ref overloader isn't good for GL, we can just disable that for GL
Dbut in the more well defined specs like vulkan, the ref/span overloader is invaluable
Pthat's a bit inconsistent though. a solution could be not having generic in or treat generic in as a ref even though it's an in
Dnot really, it's only inconsistent across bindings, which, imo, isn't super important
Dsure we want to make it feel roughly the same, but there is no way that will always work
Pmaybe if we made it so
inrefi still want the in/ref/out overloader but if implicit in is tripping us up then we've gotta ditch in
Doh you just mean implicit in
Doh yeah I can see that 
Pwell we can't disable the implicit, so we have to disable the in
Dproblem is then I can't pass inline
5that's a good thing in my books!
Dwell I mean I can see it
Dput it on the list :)
Pawesome
Pto clarify, removal of in for just gl or library-wide to prevent future problems?
DI ment more in terms of, write it down, and then we can just try it out. I mean in the end making that overloader should be trivial, and then we can just toggle it a bit and see what that looks like
KSo implicit in meaning when we see
invoid* under the hood?Pnah so we have an overloader which converts
void* to in T0Pconsidering the following signature
you can actually just pass
you can actually just pass
MyThing(5)Pwhich may not be what's expected, because OpenGL (for whatever reason) likes to use
void* to represent an integerPso instead of passing
(void*)5Pyou pass a pointer to the number 5
Kah ok..so the implicit conversion is going from
IntPtr to (void*) and that is causing issues.Pnot necessarily in your scenario, but in general yes
K
Kso this isn't a C# runtime kind of thing, it is just OpenGL being dumb
Pboth
DVS has Source Gen step in, so I'll check out what we do under the hood, one sec
Pimplicit in was such a silly addition
DI mean it is really cool, just becomes an issue when GL pulls up with it's nice spec
Pfor example
Unsafe.AsRef(1000)Pthis works
Pwhich is one of the most cursed discoveries i think i ever made haha
Doh yeah that is just...
Kwell they did it for performance right? Because then with hot paths you dont get the expensive copy
Kisn't that a good thing?
Dexplicit in T0 whenPan
inrefin compilerGeneratedVariablePso for you, the user, it's seamless
Dnote on the workaround you suggested @Perksey, that is exactly what we do under the hood:
