Happy Solar2Day!
Today it is 6 years of our project, yay!
This year had its fill of platform updates and minor improvements, as well as new plugins and some minor in-depth engine improvements.
We have a new Metal backend for macOS cooking and staying on top of the platform updates.
Thank you everyone for being with Solar2D!
Happy Solar2D Day! 
Happy Solar2Day, and thank you Vlad for keeping everything running.
And thanks for all wonderful contributions in the community.
Thank you Vlad and everyone else who keeps Solar2D alive for us!
Thank you Vlad and Scott and everyone else who keeps Solar2D alive and thriving - it is the best app dev platform I’ve ever used, an absolute joy to code with
Happy Solar2Day everyone!
And thanks to each and every one who helps Solar2D thrive.
My resolution for this year is to be more active than the last. See you all around.
Woot! Congrats to the Solar2D team!
Thank you to Vlad, Scott and everyone else, too!
Thanks to you all who keep Solar2D thriving!
I have a quick question regarding the upcoming engine improvements: Is the “new Metal backend for macOS” related to the Vulkan rendering backend? Since Windows got Vulkan support previously, I’m wondering if this Metal backend is a completely brand-new native implementation, or if it’s built on top of Vulkan (for instance, using MetalANGLE just like iOS)?
Thanks again!
I’m guessing this concerns some ANGLE-based stuff, which I’ve discussed with @vlads and a few others.
There are many interesting capabilities on ES 3.x devices [1], which are quite prevalent now. (iOS introduces some wrinkles, of course.) It would be nice to use them, and ES 3 seems pretty trivial to set up [2], but meanwhile the simulator is stuck at GL 2.x. Since the latter has quite a lower feature set—probably even when using the ideal available extensions—we’d have two very different views of things if we try to actually do anything with those features.
So, the idea is to use ANGLE to bring what we can of ES 3.x to desktop, probably either 3.1 or 3.2 according to platform. [3] Metal would ultimately underlie this on Mac, thus the connection, though the actual aim is only this feature parity. [4]
The Mac side seems to be more or less working.
I’ve tried hammering on it with the gamut of skins, resizing, rotating, and so on. Thus far it’s seemed to fare okay… I should be pleased, but am waiting for some other shoe to drop. 
[5]
The most sensible way to implement this on Mac seemed to be to make clone targets for the ANGLE versions (I think iOS did this too?), with preprocessor and linking differences. (If there’s a lower-maintenance alternative, I’d like to know.) I also did a little reorganization to reduce the number of these.
This setup builds a separate simulator—and shell, I think; it’s been a while since I last touched it—since it seemed at the very least difficult to switch between the two configurations on the fly. Its (desktop) builds also drag in the ANGLE binaries, so are a few MB larger.
That wouldn’t need to be the final form of things; I don’t have any strong feelings here.
I haven’t dug into Windows or Linux yet, so not sure what surprises they might bring.
The earlier Vulkan work was done when GL’s future on Apple first started to seem uncertain, and MoltenVK was a possible avenue. The MetalANGLE stuff on iOS—which has since been pulled upstream, thus why mainline ANGLE is now “Metal-based” on Mac—was part of the same effort.
So they’re separate things but overlap in a lot of the concerns. 
There might also be some point about WebGL2 in all of this.
[1] - See for instance this summary or compare the different ES reference cards. (GL 2.x isn’t even provided, so harder to compare off-hand.)
[2] - Annoyingly so, actually. While doing some other texture work—which I am currently revisiting—I was trying to configure ES 3.x contexts, to test stuff like ASTC. And it was always already in use! (As a superset of 2.0, it “just works”.) And the most advanced version too, e.g. ES 3.2 if available.
I couldn’t figure out a way to downgrade, so it’s hard to be certain some things were gracefully handled. Also, there could be drivers in the wild that actually do need you to opt-in.
[3] - See the chart on the ANGLE link.
[4] - So far I’ve just used a prebuilt Mac library, with ES 3.0 capabilities I believe. I did build ANGLE manually (35 GB, ugh) with MoltenVK, which ought to bump it up to 3.1, per the ANGLE project’s chart, but haven’t tested yet.
Again in theory, the new Kosmic Krisp driver is actually supposed to be a fully conformant Vulkan driver and so would ostensibly bring Mac closer to 3.2. I haven’t even moved to Tahoe / Metal 4, so obviously haven’t tested this either. In fact, seems nobody’s really explored this yet, so it would be pioneering work, with the good and bad that brings.
(iOS details, new to me too.)
I seem to remember there were some particular Metal hangups that wouldn’t allow claiming 3.2 feature-completeness, and don’t know if version 4 addresses them. In any event, it sounded like more of a corner case and that the majority could be implemented just fine.
That’s probably all a bit vague, but I read and have since forgotten a ton of stuff here.
[5] - It would be great to use `NSOpenGLView` like Solar does already, but it drags in “normal” GL state. This means doing some guesswork instead on how to properly replicate certain timing details without it, and this is not yet settled.
I need to take it easy to digest, haha.
Overall, it matches my observations and is all about what you shared. I’m glad to have such a detailed technical architecture.
Honestly, I’d be even more excited if we could natively use it instead of just Metal adapters, but I completely agree with the idea of raising the ES version to 3, which would solve a lot of problems, including future compressed texture content.
Thanks again!
Thanks guys for maintaining this community and an amazing SDK