Replace Gfx 3D API backends with sokol_gfx.h #298
Conversation
- removed hardwired vertex attrs from MeshBuilder and ShapeBuilder - MeshBuilder and ShapeBuilder no longer return a MeshSetup, but instead a Result object - convert uniform block definitions when creating sokol shaders - remove uniform block type hash
|
What still needs to be done on this? Anything I can do to help? |
|
I've been hesitating to merge this because it contains breaking changes, and I was focusing on other things in the past months... Have you seen this blog post? https://floooh.github.io/2018/05/05/oryol-sokol-gfx-changes.html I would appreciate some feedback on the API changes (basically either "WTF is this shit", or "that's fine") ;) |
|
Read that multiple times already, and I definitely like it. What I do recommend though is maybe giving people a bit of notice before merging this. I don't mind changing my code a bit, but anything using Oryol via git in fips will have problems once it's merged because their code will immediately stop working in CI, or on any new computer, or after |
|
I think a good idea to proceed would be this:
|
|
Any update on what's the status of this pr? I've read the blog post and I really like the changes. I've just started development on my application so I would much prefer to use this branch, also to avoid extra work in the future. However I noticed this branch is now a few commits behind the master branch. It's true what they say about breaking existing builds. But fips supports specifying git branch or commit hash, so these problems should be easy to solve for project maintainers. Is there anything else we could help with? |
|
I think the branch needs a few fixes for changes that happened in sokol-gfx API, but other then that I don't think there are big outstanding issues. I'm still not entirely happy with the builder-pattern initialization (compared to C99's designated initialization), but I think it's the best solution for what's allowed in C++. I need to wrap up a few things in the sokol headers first though, but I think in a couple of weeks its in a state where I can take care of Oryol again. Another thing I want to do is replace the application wrapper parts with sokol_app.h, this would also remove some big chunks of code from Oryol. But one thing after the other... |
|
That makes a lot of sense, it will also make it easier to maintain these two projects. The builder-pattern doesn't really bother me that much tbh, I think it's an elegant compromise (for what it's worth: designated initialization should be included in C++20). Thanks for the update! |
|
My biggest current concern is that this will make Oryol unable to work with Wayland, as to the best of my knowledge Sokol is currently unusable with Wayland (which is the biggest thing stopping me from switching to Sokol for some of my projects). |
|
@pixelherodev This branch currently only uses sokol_gfx.h, but not sokol_app.h. On Linux GLFW is used for window creation, so theoretically it should work with Wayland even when sokol_gfx.h is used (I only tested that after your PR for fips-glfw with the GLFW samples in the sokol-samples repo). |
|
Ah, thanks for the clarification. Let me know when this is closer to being ready and I'll happily take it for a test drive under both X11 and Wayland with a few of my existing projects :) |
|
Did this idea die a year ago? |
|
Oryol is a bit on the backburner for quite a while now. The problem with this PR in particular is that I also did a lot of API changes in the Gfx module (adding the builder pattern), and I'm not happy with those changes anymore (C99 designated initialization has spoiled me, and I was hoping that things would get more straightforward when designated init lands in C++20, but it turned out that the C++ version is so crippled that also isn't very helpful, so my motivation to continue with this PR isn't that great either) ;) |
|
Sokol has matured so much that it seems like you're on the verge of replacing most of Oryol except for some of the drawing stuff. One thing that is not clear is how you see the relationship between the two libraries. You should probably do another blog post on this and explain where your brain is at now... It seems like Sokol definitely is the one getting most of the love these days. |
No description provided.