arclight-team/arclight

High-performance C++23 ecosystem

Arclight - High-performance C++23 ecosystem

General

Arclight is an ecosystem intended to help developers in creating new C++ projects quickly without having to setup a common codebase everytime. It offers a wide range of features, ranging from basic utilities over image manipulation up to 3D rendering.

Additionally, all code is written in C++23 by making heavy use of new concepts introduced in later C++ standards. No code cruft, no old libraries from over 20 years, no license confusion: Arclight unifies all aspects of application development into one toolbox.

The code is not aimed towards a particular audience; Instead, everyone can write applications with it, no matter your level of profession or skill. Everything was written to be as clear as possible without requiring too much prior knowledge on the user's side.

So, why would you want to use Arclight?

Because development has never been that simple. We aim at maximum flexibility, user experience and performance so that you can get exactly what you want.

Note that Arclight is under heavy development right now. Interfaces might drastically change on active branches. Due to that, most of the code is yet to be documented in the near future. If you need stability and consistency, we recommend waiting until the first full release.

Features

The following features have been fully implemented:

• Full window support (including Cursor + opt. Animations)
• OpenGL 3D rendering backend GLE
• Advanced input management
• Image manipulation library, with full .bmp support, baseline JPEG
• Mathematics (Vectors, Matrices, Quaternions, etc.)
• Fastest C++23 Noise library for Perlin, Simplex and Worley noise up to 4D
• Logging & Debugging
• Command-line argument parser
• Timing utilities
• Byte/Bit readers/writers
• Unicode conversion support
• Compile-time encryption/hashing (DES, TripleDES, MD5, SHAx)
• Additional containers/extensions to std (BitSpan, OptionalRef, improved Any)
• Sound backend ASX
• XML parser
• Filesystem library
• OS classes: FileDialog, MessageBox, Notifications, Process
• Type traits + Concepts
• Configuration & Platform macros
• Optional runtime for easier setup
• Windows manifest skeleton
• Actor-Component-System (ACS)

Following features are being worked on:

• Spring, our 2D Sprite Engine
• Image formats: png, non-baseline JPEG, gif
• UnicodeString
• Compression algorithms
• Encryption algorithms such as AES and Blowfish/Twofish
• Arclight Sound System (AS2)
• Network management
• Full font render engine with TTF/OTF support
• Noise editor for optimized noise execution
• SSE/AVX acceleration of vectorizable functions
• constexpr Math

Planned features:

• Physics engine
• OS information query
• Full 3D render engine
• Unified code examples
• Image encoding
• Video streaming

Dependencies

Due to our handcrafted implementations optimized for performance, there is barely any need for external libraries. Those that are necessary include:

• GLFW for Window/Input and the render context
• GLEW for OpenGL extension management
• Bullet3 for physics
• FMOD for AS2

Only those libraries used by a module being built are required to build an application. All other dependencies appearing in CMakeLists.txt are temporary and will be removed with the first release of Arclight.

Building

Arclight is using CMake to build all of its modules. The preliminary buildsystem requires one extra file named arclight.modules residing in the Arclight root directory, containing the list of modules to be built. Note that some modules need to be built together.

arclight.input
arclight.window
#... add more modules on each line

Libraries go into lib/LibraryName/. Then, simply invoke CMake to build all of the requested modules.

Release

The first release is expected to be in 2023. Until then, there will be a consistent, intuitive and well-tested API, examples for different use cases and removal of unused dependencies. We also plan an easy-to-use build system through Arclight Studio, a tool to manage different aspects of application development with Arclight and C++. With the first release the license will be revealed as well.

Support

If you want to support this project, feel free to donate as soon as donation is set up. If you consider joining our team, contact us through [email protected].

Credits

• Arcayn for the project's management
• Ed_IT for the help as the second head developer
• ItzTacos for the logo, testing the code and several additions / fixes
• KonPet and TheGameratorT for their contributions

arclight's Issues

Math functions are wrongly declared constexpr

All math functions should be constexpr since there is no reason for them to be non-compile-time-evaluatable. However, std defines them as non-constexpr due to potential side effects.

A solution would be to use intrinsics where applicable. On runtime, this seems to be the best solution. When an architecture does not support a certain operation or whenever an intrinsic is non-constexpr, we must resort to optimized algorithms.

To check if the function is currently compile-time evaluated, std::is_constant_evaluated or (as soon as c++23 is supported) if consteval may be used in such contexts.

Residual directories when using Directory::create with a malformed path

Directory::create() (or std::filesystem::create_directories()) will create multiple directories recursively until either the end of the path is reached or an error occurs.
When passing a path such as "a/b/c/<", the directories a/, a/b/ and a/b/c/ will be created, but the creation will be interrupted by the 4th path, containing an illegal character (<).
This will result in residual, most of the times unwanted, directories being created despite the entire operation having failed.

Directory::create() should therefore operate as a transaction, meaning the only two possible outcomes should be 1) no directories have been created, or 2) all directories have been created.

Any does not work between different modules

Any relies on a linker behavior to compare types at runtime without using runtime type info (RTTI), it assumes that templated function instances will be resolved to the same address after being linked.
While this behavior is consistent when compiling a standalone binary, it is not reliable across different modules (dynamic libraries or processes) as the same templated function could be instanced twice and thus resulting in two different addresses.

JSON parser doesn't parse escape sequences

The JsonDocument class doesn't acknowledge escape sequences and fails if certains strings are parsed:

"title": "\"quoted string\""

As the reader has no knowledge of escape sequences, it treats the second character (") as a string terminator, thus improperly terminating the string and causing further read issues.

Unexplainable image resizing artifacts

This issue appears when applying scaling transformations (through e.g. Image::resize).

Upon resizing, independent of whether an image gets upscaled or downscaled, weird artifacts start to appear around the whole image. It manifests itself as "one-pixel wide stripes" in both directions, equidistantly spaced apart.

The following code reproduces the issue:

Image image;    //Initialization omitted

image.applyFilter<GrayscaleFilter>();
image.applyFilter<SepiaFilter>();
image.applyFilter<ContrastFilter>(1);
image.applyFilter<InversionFilter>();
image.resize(ImageScaling::Bilinear, 700);    //Downscaling

The most prominent pixel format for this artifact to appear seems to be Pixel::RGB5, implying that lower-resolution pixel formats are more prone to this issue than higher-resolution ones.
Whether nearest-neighbor is also affected is unclear; tests have shown that this is not the case.

Commit 22ad2a7 is affected by this behaviour.