The ABI is pretty non-standard and no tools have proper support for it, best bet is making a C layer
The ABI is pretty non-standard and no tools have proper support for it, best bet is making a C layer and binding to that
KYou'll gain little to no performance improvement in the GL calls. Maybe you get some improvement in CPU heavy workloads, but I kinda doubt it.
SDon't care.
K?
SIt's better to implement use of atlasing/texture array/array of textures than to optimize 64 bind texture calls
KI mean it depends massively on what the performance characteristics are. Depending on what the textures are you just have to use normal binds.
KThere's rarely a silver bullet in (graphics) programming
PThe max 4 bound textures in standard Vulkan 1.2 will really make you work hard to find them though!
KI mean that's the minimum of the minimum
Pyeah ofc, just the constraints you have to work with to have guaranteed portable code
Pglad 1.3 has increased it but I hate the lag time for adoption :/
KThere's been the introduction of the compatability subset too, and that stuff is wild
KI've tried building on that, but it's sooo many hoops to jump
Ldarn i can barely see with glasses at all let alone see incremented
Lhave you tried seeing incremented
Lits hard
Loh shit is a thing, so i dont need to do any of that
Land i can do it all in 1 gl call
L(on gl4 at least, ill have to reimplement glBindTextures using glActiveTexture glBindTexture for gl2 and gles)
Lbut that is for later, right now i need to implement text wrapping
SI think you meant descriptor sets, because that's exactly how many i can have on my phone.
Pif that's what you think i mean then you're wrong
Pi meant what i said
SJust query physical device capabilities and shit pants error when they have max 4 inages.
Pbut then you are defeating the point of vulkan
SBeing able to run on a potato? (Hmm a new idea)
Pno
Pbeing portable
Pvulkan was designed to unify mobile and desktop
Pas well as to continue mantle's legacy
Lif only apple were to really embrace vulkan the world would be whole, but no we gotta deal with metal (which isnt nessesarily bad, but its closed so its hard to justify developing metal code specifically)
Lat least MoltenVK is oss
Pi love how everyone ignores DirectX, NVN, and Gnm
LIndirectY, SVN, and Gnome
Lunrelated but look at this beautiful text wrapping i just wrote
Lvery fun
KBeautiful UI
KI'm surprised your code allows overflows. How do you do that?
L?
Ldo you mean how do i even allow text to overflow the container its in?
KYeah
Lmy UI code is very very stupid
Lit doesnt have a true concept of "size" and "positioning"
Lat least not automatically
Lthat container is literally just a rectangle with some text on top
Lthe illusion of it being "inside" the rectangle is caused by it being within the bounds and drawn above it, when in reality, its not 'inside' it
Ltheres not really a higherachy, just a bunch of ordered lists
Lwhile that ordered list can contain items with other lists, nothing is really aware of that
Lin this scene, its a with a , with a inside with a inside, then inside that second list is a and a , and inside that is another (its an extension of ) and inside there is the with the text
Lmy drawing code just traverses that list tree and draws recursively in the right order
Lwhile it may be a very very basic structure, its very simple to grasp and modify to create more complex logic