Skip to content

[WIP] Include renderer inside the library instead of explicitly providing them at project level#17

Open
Logickin-Lambda wants to merge 4 commits into
johan0A:mainfrom
Logickin-Lambda:main
Open

[WIP] Include renderer inside the library instead of explicitly providing them at project level#17
Logickin-Lambda wants to merge 4 commits into
johan0A:mainfrom
Logickin-Lambda:main

Conversation

@Logickin-Lambda

Copy link
Copy Markdown

As suggested previously, I was thinking of putting the renderer backend inside the library so that users can use the library out of the box by selecting a preferred backend along with the related dependency instead of providing the renderer from their ends.

So far, I have gotten a working solution, and all you need is to choose a renderer at build.zig in your projects as shown:

const raylib_dep = b.dependency("raylib_zig", .{
	.target = target,
	.optimize = optimize,
});
root_module.addImport("raylib", raylib_dep.module("raylib"));
root_module.linkLibrary(raylib_dep.artifact("raylib"));

const zclay_dep = b.dependency("zclay", .{
	.target = target,
	.optimize = optimize,
	.renderer = .raylib,
});

// if you use custom renderer from your projects, skip the addImport function
zclay_dep.module("zclay").addImport("raylib", raylib_dep.module("raylib"));
root_module.addImport("zclay", zclay_dep.module("zclay"));

At the application level, instead of loading your renderer file, all you need is to fetch the renderer from the zclay module as shown:

const cl = @import("zclay");
const renderer = cl.renderer;

This works because under the hood, the library picks and selectively compile the renderer based on the switch statement, controlled by the .renderer option:

pub const renderer = switch (@import("zclay_options").renderer) {
    .custom => .{},
    .raylib => @import("renderers/raylib_render_clay.zig"),
};

Where the @import("zclay_options").renderer is an enum defined in the build.zig of the library:

const Renderer = enum {
    custom,
    raylib,
};

As you can see, with this implementation, for every new backend added into the library, the contributors can simply add a new name into the enum and loading their renderer at root.zig by expending the switch statement with their imports.

To test the upgrade, you may build the example raylib-sidebar-container from my fork to see how the new option behaves and to verify the result. I didn't update raylib-clay-official-website because I want to show you that the original method still works so that it offers a way for users to test and build their own renderer.

I am a bit tired now, so my speaking is a bit incoherent. Please let me know if you have any questions.

When I see this binding, the first thing comes in mind
is that we need to ship our own renderer for each
backend, but trying to translate the original C
renderer manually and individually is not an efficient
approach which everyone who have their own renderer
might written differently, and they need to update
their own version of renderer with their own code.

With this commit, users now have an option to either
using the original approach, or they can specify
a specific renderer for their project with an enum,
similar to how zgui works.
The new README let users know that not only they
can pick their own renderer with the recent update,
but their original approach remain unaffected,
letting them freedom to experiment their own backend
that is not included in the library.
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.

1 participant