Open Sorrowful-free opened 3 years ago
Why you stop develop this library?
Well, I still update to the latest version of Kotlin when I have to, since some versions may not be compatible. I don't actively add new features to this library because my primary interests have shifted elsewhere and I don't have enough time for both, since I now have a full-time job. However, I do tend to respond to specific feature requests and reported bug fixes.
Why you support only desktop platforms? (A lot of people use kotlin for mobile instead desktop development)
I've personally only used this library on desktop and no one has asked for mobile yet. I tried to get kgl-vulkan working on Android but I'm blocked by ktor supporting it too. I started work to replace ktor in #21 but haven't finished it yet.
Can i help you develop your library? (For example you have a vision of project but have not enough time for development) Thank you for your job!
Yeah feel free to open issues describing what you want to add and then PRs! I'm perfectly willing to review and merge. I indeed do have a vision but haven't written most of it down anywhere. The last thing I was looking at is #9 but it's really hard. What part of this library are you interested in?
Also, how are you using kgl
if I may ask?
Thank you for your answer, right now i have interest for make simple but modular "game engine", I understand it hard task, but it is great research project, your libraries (kgl and imgui implimentation) gives me opportunities to skip boring things like write editors or something else, and kotlin gives me opportunity to create it maximise near to native code for every platform, and your implementation kgl-dsl looks awesome for my tasks. I hope I answer on your question.
Hi,
I'm revamping vkk (moving to code generation, better docs and inline classes for pointers)
Since I've already started moving glm to multiplatform, maybe would it make sense to merge our efforts and have a unique multiplatform library for Vulkan.. vkk for jvm and kgl for native
What do you think about it?
At the moment kgl has jvm and native bindings for Vulkan. Though it doesn't generate methods just yet and the moment their semi generated and manually massaged in.
Sure we can merge our efforts! What did you have in mind do to achieve this?
Uh, I wasn't aware of.
I'd like to have all of that fully generated. However my main goal is to easier at best programming and debugging developers by having all the structs as fully fledged jvm classes and copy over the content only when needed (or maybe having an option to keep it in "sync" with an optional native counterpart), eg: a String
will be a String
.
Also, object oriented (so instance, device, etc will all become receiver), automatic check on errors but customizable otherwise, enums via inline classes, default parameters for the cases where it's obvious from the docs or the most used patterns, etc etc
but customizable otherwise
You want to do the generation at the application side? So every application would install some gradle plugin, set some settings and have their custom vulkan wrapper generated for them?
Hello, you doing awesome work, but i have several questions: