Replace Gfx 3D API backends with sokol_gfx.h

pixelherodev commented 6 years ago

What still needs to be done on this? Anything I can do to help?

floooh commented 6 years ago

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") ;)

pixelherodev commented 6 years ago

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 fips updateing.

iboB commented 6 years ago

I think a good idea to proceed would be this:

Create a tag on master (for example "v1.0.0"). This will also lead to a GitHub release, so the code will be easy to find and download.
Create a branch "Oryol-1.0.0". You may choose to support this branch for a while for people who don't have time to migrate but still want bugfixes. (However don't feel obliged to do so. Supporting older versions can be demoralizing :smile: )
Merge this pull request, and create a release Oryol-2.0.0 (semver tells us that breaking changes require a major version upgrade. Still many people are reluctant to upgrade a major version if the breaking changes are only "slightly breaking" :wink: ... 1.1.0 could also be fine)
Add an announcement about this at the top of the README. Then after a while remove it from the top and leave it in the release notes alone. People using it through git should know that if they don't want to migrate, they should switch to the tag or branch

GeertArien commented 5 years ago

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?

floooh commented 5 years ago

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...

GeertArien commented 5 years ago

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!

pixelherodev commented 5 years ago

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).

floooh commented 5 years ago

@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).

pixelherodev commented 5 years ago

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 :)

frink commented 4 years ago

Did this idea die a year ago?

floooh commented 4 years 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) ;)

frink commented 4 years ago

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.

floooh / oryol

Replace Gfx 3D API backends with sokol_gfx.h #298