I'm happy to announce that after 7 years in development the first stable Fyrox 1.0.0 was released! Fyrox is a modern game engine written in Rust, it helps you to create 2D and 3D games with low effort using native editor; it is like Unity, but in Rust. This release is huge compared to the last one (0.36). Make sure to check release notes for release-candidate versions as well as the release notes on this page.
This release took a lot of effort, a lot of polishing and attention to details. Yet, the development team of the engine is quite small with little to no funding, so it is impossible to catch all the bugs and polish all the "rough" parts. If you find a bug, confusing or incomplete documentation, please file an issue (opens new window) or propose a solution by creating a pull request (opens new window). Your feedback is very valuable to improve the engine, make it more stable and easy to use.
Make sure to also check release notes for the two release-candidates for 1.0.0, which essentially summarizes all the changes in 1.0.0 compared to 0.36.2.
Use the link (opens new window) to download page to learn how to install this release.
It is now possible to configure continuous integration/continuous delivery (CI/CD) for games made with Fyrox. Each
project built using the project manager has a special crate called export-cli. This crate offers a command line
interface (CLI) for the same functionality that the editor uses when you export the game from it.
This functionality is very important for team development where a project is developed by many developers of various roles. For example, even on small teams CI/CD with this CLI will automate builds for QA.
There are number of useful options that can be used to simplify testing of the produced builds.
-h, --help - show the detailed usage instructions for the CLI.-V, --version - prints version of the CLI.--target_platform <pc/wasm/android> - the target platform to build the game to. Must be one of: pc, android, wasm.
Keep in mind, that you must also set the appropriate build_target parameter if you're using cross compilation (for
example, creating a WebAssembly or Android build from PC). Default value is pc.--build_target <target triple> - the name of the build target. The default value forces to compile the game to the
default target of the current toolchain. Usually this parameter can be left unchanged, unless you need
cross-compilation to some specific platform and architecture (see below). WebAssembly builds requires this parameter
to be wasm32-unknown-unknown. Android builds require one of the following: armv7-linux-androideabi for 32-bit and
aarch64-linux-android for 64-bit. The full list of build
targets can be found here (opens new window). Default value is
default.--destination_folder <path> - the destination folder for the build. Default value is ./build/.--include_used_assets - a flag, that defines whether the project exporter should include only used assets in the
final build or not. If specified, then this flag essentially forces the exporter to scan all the assets for
cross-links and if there's at least one usage then such asset will be included in the final build. This option could
be useful if your project has a lot of "dangling" resources, and you don't want to search all the used resources
yourself. Use this option carefully, because it won't include assets that you manually load from code bypassing the
resource manager. In this case, the project manager will simply ignore such "unknown" files. This option is disabled
by default, because it may produce unwanted side effects in some projects.--ignored_extensions <ext1,ext2,..,extN> - specifies a set of file extensions that should be ignored. Each extension
must be separated by a comma. For example: log,txt,iml. Default value is log, which excludes Fyrox log file.-r, --run_after_build - if specified, the exporter will try to run the exported project after the successful
build. This option is disabled by default.-o, --open_destination_folder - if specified, the exporter will try to open the build folder in the default file
manager of your OS after the successful build. This option is disabled by default.-c, --convert_assets - if specified, the exporter will try to convert all supported assets to their "shipping"
version. For example, native game scenes and UIs will be converted from ASCII to binary if this option is specified.
This option is enabled by default.-e, --enable_optimization - if specified, enables all possible optimizations for the build. This option is enabled
by default.The typical usage varies on the target platform. Keep in mind that you can also add all the arguments listed above for the commands below.
When building for Windows/Linux/macOS on the same OS (Windows → Windows, etc.) then all you need is to run the tool with default arguments:
Cross-compilation requires build target to be specified, for example if you're making Linux build from Windows you can do something like this:
WebAssembly builds usually performed on Windows/Linux/macOS machine so it essentially requires cross-compilation and a typical command to build the game can be something like this:
Keep in mind that WebAssembly builds were tested only on wasm32-unknown-unknown build target.
Android builds usually performed on Windows/Linux/macOS machine so it essentially requires cross-compilation and a typical command to build the game can be something like this for 64-bit version:
32-bit version requires different build target:
It is now possible to add optional text trimming with ellipsis when a line does not fit in its constraint. On practice, it looks like this:

This is small improvement, but it really makes the UI more elegant.

Input box is a new widget that solves the most common problem in UI - ask a user to enter some text and either confirm the input or cancel it.

Project manager is able to build and run or edit your game, this is achieved by creating child processes that are attached to the project manager process. Some operating systems (such as Windows), explicitly controls the lifetime of child processes. For example on Windows, child processes are terminated automatically when the parent process is terminated. This fact added confusing behavior for the project manager - when the editor was run from the project manager and you're closing the project manager, the editor will be closed too without a warning. This inconvenience was fixed in this release by adding confirmation dialog when closing the project manager.

Text box now has a configurable corner radius property. This is small but important change for consistent look of the editor.

It is now possible to capture the state of all animated properties in the animation editor. It is very useful when you're creating an animation that should capture your actions made in the editor. To do that, make a change to a scene node's property that is currently being animated and click on the green key button. Then move the time cursor and repeat these actions again. After that you can preview the result by clicking on the button with eye icon.

It is also possible now to disable drawing of background curves in the animation editor:

Background curves are used to visualize values of other animated parameters, but showing them all at once in some cases creates quite noticeable visual clutter and now it can be removed in a single click.

Animation blending state machine editor was improved as well, it is not only the visual style improvements. Adding a new animation or renaming one is now performed via new input box control. This is much more intuitive than the old approach.
Scene and UI loading was refactored to be more flexible, AsyncSceneLoader was removed and now scene loading is performed
via async tasks. There are three new helper methods in PluginContext: load_scene, load_ui, load_scene_or_ui.
The easiest way to load a scene or UI (and the most compact one) is just one line:
This method is used by default in all new projects generated by the project manager. This method automatically adds the loaded scene or UI to the engine internals.
In some cases you may want more control of how the scene is processed before adding it to the engine. A typical example of scene loading with full control of the process is something like this now:
It is quite verbose, but it is only needed if you need to do something special during scene loading.
The book (opens new window) was updated for 1.0.0, it now has all screenshots up-to-date, pretty much every chapter is finished.
The release of 1.0.0 was very labor-intensive and Fyrox Dev Team needs some rest. The devs will continue fixing bugs, but new major features will be on-hold for a few months.
If you want to support the development of the project, click this link (opens new window). Also, you can help by fixing one of the "good first issues" (opens new window), adding a desired feature to the engine, or making a contribution to the book (opens new window)
The list is split into four sections for ease of reading and finding particular information.
already borrowed panicopen recent sceneexport-cliadd and remove buttons for collectionscore module in fyrox docsUserInterface::try_send_response helperdonate button for project managerImageButtonBuilderBehaviorResult alias + test fixesColor::hexImageButtonBuilder helper + replaced make_button_xxxPluginContext::load_scene_or_ui + fixed project templatedispatch_behavior_variants macrolocate button for material fieldlocate button for surface fieldmake_image_toggle_with_tooltip helperholes enabled flag is offvisual_debug == truefyrox-build-tools crateNumpadEnter on Button widgetlocate button in material field editorlocate button in surface field editorlocate button in resource field editorHotKeySceneRoot from __ROOT__load_uiFrameworkError in GameErrorMobility because it does nothing