Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add EGL support (And config struct) #30

Merged
merged 5 commits into from
Feb 18, 2023
Merged

Add EGL support (And config struct) #30

merged 5 commits into from
Feb 18, 2023

Conversation

darltrash
Copy link
Contributor

Now that EGL support has been added to sokol_app.h, it would make sense that the zig counterpart would also support it as a flag or something related.

I wrote a small patch which would allow for the zig build process to link towards EGL and use the right flags.

Maybe this code is a bit dirty, but that's what pull requests are for :)

@darltrash darltrash mentioned this pull request Dec 7, 2022
@darltrash
Copy link
Contributor Author

I am genuinely not sure about the extra function parameter, it looks like it could break a lot of existing things, and I feel like this will need something like a struct for general configuration later on as Wayland support is being implemented...

@floooh
Copy link
Owner

floooh commented Dec 7, 2022

I am genuinely not sure about the extra function parameter, it looks like it could break a lot of existing things,

Breaking compatibility should be ok, projects using the bindings would either copy them into their project, or integrate it as a git submodule. In both cases the build would only break after deliberately updating the bindings.

But a few smaller changes would be nice similar to the Wayland PR:

  • use the idea of a struct for configuration, but call that struct 'Config' instead of DisplayServer. This config struct could start with a single use_egl boolean, the current backend arg should also eventually move into this Config struct, but I can take care of that later.
  • also like in the Wayland PR, it would be nice if the config options are exposed as build options, so that they can be set from the command line

@darltrash
Copy link
Contributor Author

I was also thinking about something, is it really necessary to still support GLX? as far as I know, EGL is supported on pretty much anywhere and gives more freedom to what kind of OpenGL context is obtained.

Anyways, I will do a little sketch and upload it in a second :)

@darltrash
Copy link
Contributor Author

I just added a new Config struct, which contains the backend and the egl option.

My idea was to make everything also have a default value, so for example, the backend value will always default to .auto and the user code would end up looking like this:

const sokol_build = sokol.buildSokol(b, target, mode, .{}, "lib/sokol-zig/");

@darltrash darltrash changed the title Add EGL support Add EGL support (And config struct) Dec 7, 2022
@darltrash
Copy link
Contributor Author

I think it could be useful if you could left off certain sokol libraries, for example, skip sokol_audio if you want to use another library for audio

@darltrash
Copy link
Contributor Author

darltrash commented Dec 23, 2022

I've just added Wayland build support, based upon what I saw implemented on #30, It works with and without the Wayland sokol_app.h patch.

Again, I insist on considering to drop GLX support altogether and just use EGL, it would greatly simplify things as I can see a great part of the X11 implementation being based upon GLX which does not bring any sort of realistic gain over just using EGL, to my knowledge. (It could also be backwards, as in, to main EGL by default, then allow for GLX behind a flag.)

I've also noticed that making certain parts of sokol optional would be pretty easy to implement, i dont think all of them need to be optional since some of them don't even leave any trace in the output binary if they're not used in the code itself, but some of them create linker dependencies; sokol_app.h, sokol_gfx.h and sokol_audio.h come to mind.

@floooh
Copy link
Owner

floooh commented Jan 16, 2023

Note that for Wayland support you would need to generate your own bindings using the so far 'inofficial' Wayland PR. Not sure how much sense it makes to put that into the vanilla build.zig file, might just be confusing to users when they try it out and it doesn't work.

@floooh floooh merged commit b704e59 into floooh:master Feb 18, 2023
@floooh
Copy link
Owner

floooh commented Feb 18, 2023

And merged, thanks! I'll probably add a comment about the X11 vs Wayland flags so that users are not confused.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants