Solar2D 2025.3721 has been released

Summary


FIX:

  • #809: Fix the error where audio.play always returns false with the completed event.
  • #758: Fix meshes not centering when created using buffers.
  • #803 + #812: Fixing unpack with alignment with format texture.

NEW:

  • #810: Android API 35 support and 16KB page support.
  • #811: Xcode 16.4 on Apple.

Some notable changes


  • Resolve the issue where Google Play Store requires apps to support 16KB page sizes as mentioned here and Support Android 15 SDK.

  • depilz has made some improvements with buffering for mesh updates, which will significantly improve performance compared to updating via Lua tables.

  • With the unpacking alignment, we can now create Image Masks without requiring divisible by 4 size. Additionally, it also fixes pixel padding issues with the bytemap plugin when generating textures of arbitrary sizes.


More info:

15 Likes

I don’t know if there were details and comments here about the Solar2D updates, but this post is to be congratulated, it’s a simple detail, but it makes all the difference for some.

Yeah, everyone is welcome to discuss the update here, as well as possibly report bugs. This is just a post based on my personal understanding of the updates.

There have been a lot of updates with cool new features recently, I think a lot of people might have missed it.

1 Like

I remember struggling when I first started learning the engine because I didn’t know image mask layers had to be in multiples of 4. This is a great update. :slight_smile:

Yeah, I worked on a kids painting app before, Image Mask rules made things more complicated when using masks to separate out the picture pieces.

It will be easier now.

Thank you @Kan98
It would be very helpful to update the official documentation with these changes. For example, to strike through the requirement text in the mask image.

As I mentioned before, Solar2D is only really known to users who are active on this forum, because many changes and fixes haven’t been documented in the official docs. If we want better support for our engine, updates alone aren’t enough—it’s also crucial to document them.

Will probably try that later, I haven’t tried building the corona docs repo yet.

1 Like

I’ve always noticed that the fix for using the latest version of Xcode is just updating the Xcode version number in a build.yml file.

Would it be practical to add a workaround where the developer can add their local Xcode version number to a separate file which gets read and overwrites this number? That would let devs use the latest version of Xcode immediately without Vlad/Scott/etc having to update this as quickly. Of course it would then be on the dev to ensure they test their builds thoroughly before releasing.

Or is there some complication that would prevent this from working?

According to my know, Solar2D uses templates to build apps for each platform, these templates (Including the target Xcode version) will be generated when Solar2D builds a new release.

This means, if you need to update your xcode version, you need to rebuild the templates for Apple platform and replace it with your current templates.

Do you have pages in mind that are out of date so we can look into it? I’ve been trying to keep the pages up-to-date for the ones I can track. I’ve probably missed on some but a list could help.

@Kan98 can you tell which of the following requirements are no longer relevant so that I can add a warning as such?


Here it is.

1 Like

I thought the part in bold was also related to image masks :slight_smile: Just sent the PR making the necessary change.

@bgmadclown Different manifestation of the problem, but it was the same faulty mechanism under the hood. (With similar behavior: either an outright crash or weird-looking shortening rows of pixels, when given a ā€œbadā€ width.) There was a second problem with updates—after the texture was created, but for example when setting pixels in a mask-type memory bitmap—that @Kan98 flushed out and also fixed.


Speaking of ā€œnever got around toā€, I do have notes for a lot of 3713+ stuff, and probably a few odds and ends before that. Very rough drafts in many cases, but I suppose it’s something. There is a lot of non-API material that wants some love too (maybe it should be in ā€œguidesā€), but… well, hasn’t had any. :smiley:

1 Like

Sure, I’ll show you some I’ve discovered. The first one that comes to mind is the one related to masks (Kan98 already advised you).

If you can share some of it maybe we can put together something using ChatGPT to speed up the process. Better than nothing I guess.

Please do. I have added the notice for Image Masks as @Kan98 pointed out. I’ve also discovered a few more stuff that I’ll send PRs to fix.

1 Like

Here’s something I noticed:

In the plugin.admob documentation, under the adsRequest(https://docs.coronalabs.com/plugin/admob/event/adsRequest/phase.html) event phases, the closed phase is described as occurring only when an interstitial ad is closed. However, in my testing I found that closed also fires for other ad formats—excluding banners—like appOpen, rewardedInterstitial, and rewardedVideo.

1 Like

Submitted a PR addressing the issue. Can you take a look?

2 Likes

As Kan said, yes, whenever a new version of Xcode is released, a supported GitHub CI runner image is required. Then, Solar2D uses the new Xcode version to compile the template within it and then releases the version. If you want to obtain the engine core compiled with the new Xcode version locally, apart from compiling the source code locally, you can only wait for the new template to be released.

However, it might be possible to accelerate the generation of the new template, for example, by adding a trigger that automatically or manually initiates the compilation upon the appearance of a new GitHub CI runner image, and then obtain the template.

Even further, consider separating the variable content from the release version, such as placing it in a plugin. However, this is generally only applicable to Xcode version updates that do not require manual intervention.

I’m not very satisfied with the current Apple integration, but I can’t start working on it at the moment.

It doesn’t fully support Apple Silicon and the device simulator. The fragmentation of platforms and architectures leads to duplicate code, which could potentially be resolved by using XCFramework or Pods, and the template, also the plugins, should also be reviewed together to make the Apple integration more flexible.

I’ve checked the documentation and it’s corrected now!
Thank you @bgmadclown

1 Like