Making Projects Better

Making our projects better than before is one of our most important things that we have planned to do. We have improved the build system across all projects by introducing the tools repository on GitHub that is used as a submodule. Our strategy for this plan is to make sure that all our projects get the highest quality possible, while aiming for more.

Announcements for new release of our flagship projects will be made every major version or a version that is worth talking about. Not only updates will be done, but projects that are new to the programming industry will be made to allow developers to have more options according to the program.

Recently, we have started improving the documentation of the Terminaux project for the upcoming release. We have currently restructured the cyclic writer documentation so that a single page is split to multiple pages by category. This helps find information more quickly.

In the second half of the year, we are planning to introduce changes to our work plans so that we’d be more open. Confirmed additions, improvements, and other updates will be added to every repository’s GitHub Projects, straight from the internal information. This is to let the users know of the roadmap of all our projects in a more transparent manner.

After the release of the upcoming Nitrocid version series, we’ll make sure that other projects get their own development time as we are striving to improve them with new features and other general improvements. Because the upcoming version of Nitrocid is currently in a stage where it needs to be adjusted for the next Terminaux version, a beta program will be introduced. This is to gain feedback from developers and users, and we listen to all feedback!

Making sure that we fulfill our promises to you, we’ll keep you informed of any new updates regarding our projects. Meanwhile, normal development for all projects will start on April 6th, and we hope that we introduce you to new, exciting features. Are you ready for the most exciting moments?

Image by freepik

Update for Further Development

This month, it was a massive month for us when it comes to the build system and Terminaux. The build system witnessed many improvements across different areas, including, but not limited to:

• Introduction of the tools repository that any project (of course, not just C# projects, but non-C# ones, such as Node.js and Rust projects) can use.
• The build system actually uses the vendor scripts found under the vnd directory, which increases flexibility.
• All projects, such as Nitrocid, BassBoom, and Terminaux, now use the tools repository as a submodule instead of the project-specific build scripts.

In addition to that, we are proud to release the above repository with full documentation about how to adapt your project so that it uses this minimal and extensible build system. Then, we have actually started working on the upcoming version of Terminaux, which we will release when we feel that it’s ready for public use.

Now, we are announcing an important change to our plans for the next week. We will pause development of all projects for one week starting from March 30th as we are evaluating our plans for the coming weeks to make sure that we fulfill our promise to you. After one week, we will resume development of all projects, but we will employ different strategies to ensure high quality.

The blog will still get new articles, but we will resume normal project announcements after the one-week brownout. This way, we’ll make sure that we provide continuous updates regarding all our projects.

Photo by Andrea Piacquadio

Mono is back! Mono 6.14.0 released!

The first major version of Mono has been released after more than five years of no release. The WineHQ project has taken over the development of the .NET Framework version of Mono back on August 2024 after a fork has been made back in February 2024 under the project’s GitLab instance. This major version is under 6.14.0 and is available to download now.

The release changelogs states that Mono finally has native support for macOS with ARM64 processors, which makes your developer experience when using such machines improved. In addition to that, there have been several improvements regarding System.Windows.Forms for Mono GUI applications to fix resource leaks, to re-implement clipboard and drag-and-drop functionalities, and to improve stability on X11.

This release has also improved support for generated COM interfaces for apps that use them. Mono should no longer hang when the process is being exited in some common cases. In addition to that, Mono should no longer experience many bugs and many build warnings.

For Gregorian users, Mono finally has support for the Gregorian language, which means that you can now use Mono in your native language to improve your user experience.

To download Mono’s source code, click on the button below:

https://audiomack.com/aptivi/song/mono-is-back-mono-6140-released

GamesRadar: Sonic fans are leading the charge on a new preservation tool that can help give any Xbox 360 game a native PC port. “…this new tool, called XenonRecomp, simply gives fan developers a path to creating PC versions of Xbox 360 games. As the GitHub page explains, it ‘converts Xbox 360 executables into C++ code, which can then be recompiled for any platform.’ It’s not magic – you […]

https://rbfirehose.com/2025/03/06/gamesradar-sonic-fans-are-leading-the-charge-on-a-new-preservation-tool-that-can-help-give-any-xbox-360-game-a-native-pc-port/

This version of Ubuntu started the development with one of the most significant changes ever done. This time, it’s about compiler optimization level used on Ubuntu packages by default. When this version of Ubuntu had started its development, the mailing list entry said the following:

* perl 5.40 and haskell / ghc 9.6.6 already migrated to the releasepocket, to avoid entanglement with other transitions.* dpkg-buildflags defaults to -O3 instead of -O2. This might require changes in package builds. Please be aware that we already build with -O3 on ppc64el, so look for possible packaging adjustments.

While the Perl one is irrelevant in this blog post, the second entry in the toolchain changes is interesting. The default build flags for all Ubuntu packages that are determined by dpkg-buildflags have been changed so that -O3 is being used as a default instead of -O2.

This means that all future builds for all Plucky Puffin packages will be more optimized. Because of this, the build times will increase, but that doesn’t affect the end user. As a result, the packages that are built with the third optimization level will be faster than before, which means that your computer will be faster the second you upgrade to 25.04.

However, the binary size for the packages will be bigger, and there is uncertainty whether all packages benefit from this level of optimization that will be applied to all the packages. Furthermore, all builds and tests will be run, so expect delays. After that, when you test 25.04 during the development cycle, you should experience performance improvements.

On a side note, Perl 5.40 was released to Ubuntu 25.04, which brings several new features, new analyzers, and breaking changes, such as the :reader attribute for field variables, the breaking changes related to use VERSION declarations, the Infinity (inf) and Not-a-Number (nan) constants in builtin static class (module), the medium-precedence Logical XOR ^^ operator, the try...catch...finally block being a stable Perl feature, and stable support for multiple value iterations for the for loop.

Let’s see what Ubuntu 25.04 Plucky Puffin will offer as the next LTS, 26.04 RR, gets closer to the development period.

https://officialaptivi.wordpress.com/2024/11/04/ubuntu-25-04-plucky-puffins-packages-are-more-optimized/

#O2 #O3 #2504 #Acceleration #C #C_ #Computer #computers #GCC #GCCCompiler #improvements #Linux #LinuxUbuntu #news #Optimization #performance #Plucky #PluckyPuffin #speed #Tech #technology #Ubuntu #Ubuntu2504 #Ubuntu2504Plucky #Ubuntu2504PluckyPuffin #Ubuntu2504Puffin #UbuntuLinux #ubuntulinux #update

So you wanted to multi your threading, huh?

An introduction to a series where I talk about different parallelisation technologies for C++, comparing different implementations of the same algorithm. In this one, modern C++ STL

https://vilelasagna.ddns.net/multi-your-threads/so-you-wanted-to-multi-your-threading-huh/

By: @vilelasagna@mastodon.gamedev.place
#c_ #coding #multithreading #multiyourthreading