Back

rendering context is now owned by the client code. Remember UserData::owned from miniquad 0.2? Well, in a way, we got it back.

If only one specific rendering backend is needed,
"window::new_rendering_backend();" can be replaced by "GlContext::new()" and Box<dyn RenderingBackend> can be replaced by just GlContext.

Before, miniquad had a really weird concept of stateful/unstateful objects. Buffer was a stateful object holding some data, while Texture was just an Id.
It was not clear from the docs and just felt wrong.

Now miniquad is explicitly returning Ids. "new_buffer_immutable" returns BufferId.

I actually hate this one and I think I'll change naming before going out of 0.4-alpha.

miniquad had a bunch of functions like
fn f<T>(x: &T);

miniquad did not cared about any vtables or anything, it was just a way to pass a pointer + a size with a nice syntax.

Unfortunately, with "f" being a trait member this is not possible anymore.

Arg is basically a "ptr: *mut void, len: usize"

miniquad is never going to do any post-processing with shaders.

I would be very welcome for optional, naga-based, spirv-cross-based or anything-based library doing shaders cross compilation.

For life shader editing I would probably try to glean some code out of @rikarends's/makepad's shader cross compiler to get a compact, no dependencies tool.

But miniquad itself will just receive all the possible shader sources and some shader meta.

no more "Context" for event handlers.
RenderingBackend is now owned by the client code, and for window manipulation miniquad now provide a static "window" module.

"ctx.screen_size()" became "window::screen_size()"

Motivation for this in the next toot

miniquad used to have a very smart(well, it felt like...) system to combine data from the rendering backend, window payload etc into one single context.

Turned out it was the worst idea ever. Implementation was basically unreadable and it prevented A TON of usecases when it would be nice to get a context outside of just event handlers.

And, on top of this, some platforms used statics anyway!

A lot of suffering for nothing. Not anymore!

on linux miniquad will try to dlopen libx11, libwayland, libglx, libegl, basically it will try really hard to find some way to get at least some opengl, making its binaries super-survable.

But, on mac, Metal and OpenGL are just too different. I do not see any usecases where its reasonable to assume that if Metal context cration fails - we should fallback into OpenGL.

So on apples miniquad will create either Metal or OpenGL context.

I guess thats pretty much it

for macroquad nothing is going to change. Its already ported to miniquad 0.4 and it works perfectly on both Gl and Metal.

The only issue is live shader coding - right now it will require both metal and gl shaders.

Not really sure if macroquad will ever be shipped with shader cross-compiler or it always is going to be third-party thing, but for now - two sets of shaders.

and yea sorry for super low-quality code-as-screenshot

I tried to make mastodon not crop them, to make this thread readable at least on desktop, but, meh, did not worked...