Pi want a consistent syllabus though
DWTF is syllabus
Pof course, in vulkan there are a LOT of different details
Pbut the outcome of each chapter i'd like to be the same
DPretty sure I can make a line by line port lol
Pi.e. a window (for vulkan probably bundle instance, swapchain, and logical device creation in here too), then a quad, then abstractions, then textures, etc etc
DOh wait you mean LearnOpenGL in vulkan
DThat's not happening
DThat would be a huge amount of code
DIe the whole lighting thing
DIn Vulkan that's like... I can make that raytraced and it'd be as easy as not raytraced
Pwho said anything about raytracing
Popengl doesn't have raytracing
DWell I mean in terms of difficulty
KIsn't there an extension
Pi'd just take a look at the code before making a judgement is my advice
Pa lot of the stuff isn't that complex
DVulkan just normalizes anything to "pretty difficult", it's not super difficult to do anything, but it's also not trivial to make even basic stuff
Plike the lighting is just in a fragment shader
Pwith some uniforms
DI mean I can look, but also I don't feel it makes that much sense
DRelying on some of the community recommended tutorials is much better imo
Pfor the record the author of learnopengl is currently in the process of making learnopengl but in vulkan
DWhat
DThat's... Interesting
DI mean makes sense, there is no really good vk tutorial
Pexactly
Pso why not make one
Pftr my main reasoning behind the whole consistent tutorials thing is so people can actually figure out what's new and different
Pand what has the core fundamentals
Pa 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
inref is used?Pi 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