How to start the Fyrox Game Engine?

[TheRainbowSun]

I cannot find an executable file in the v0.24 source code archive.
How to start the 3D Rust Game Engine?
Windows?
Linux (Debian, Arch)?

[DuckEater54]

Are you new to rust?

[TheRainbowSun]

yes

[Eragonfr]

The source code archive does not contain any executable.
That's normal, it contain only code, nothing more.
If you want an executable from this source code you will need to build it.

For that you will need the rust toolchain, once you have it you can simply run cargo build --release and you will get the executable in the new target/release folder.

If you want to learn more about rust and how to program with it you can try to follow the rust tutorial, it will guide you through the setup of rust and it's tools.
https://www.rust-lang.org/learn/get-started

This issue can be converted to «No binary available to download in the releases».
Because we should be able to grab the latest editor and run it without having to build it from source code.

[TheRainbowSun]

Okay, My first attempt is now with Mx Linux. As text editor I use the preinstalled Geany. With the terminal command curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh I installed Rust. Next, I opened a terminal in the unzipped Fyrox-0.24 folder and inserted cargo build --release. Now I have a folder with Fyrox-0.24/target/release. Unfortunately I still don't have anything executable. I find rlib, d and cargo-lock as file extensions in the release folder. Now how can I start the engine without having to create an executable? I want to access the user interface of the Fyrox engine. I don't quite understand your last sentence.

[Eragonfr]

You should be able to run the editor. It's probably the file target/release/rusty-editor (yup… not an intuitive name for an engine named Fyrox but the new name is recent).
Don't be surprised by the absence of extension on the file. It's normal, on linux executable don't need to have any sort of extension.

This issue can be converted to «No binary available to download in the releases».
Because we should be able to grab the latest editor and run it without having to build it from source code.

This was more for @mrDIMAS or others maintainers.

[ghost]

@Eragonfr I made support for .deb an .rpm packets in rusty-editor in 2021

[Eragonfr]

I've seen that.
But the deb, rpm, exe… whatever files are not in the release.
I think, it should be as a separate file alongside the source zip and tar.gz in each release. Maybe we should set up a GitHub Pipeline or something like that to automatically build and add them on each release

[mrDIMAS]

https://fyrox-book.github.io/fyrox/beginning/getting_started.html

[TheRainbowSun]

That helped me.
e28ecd1

cargo install rusty-editor
After that, you can run the editor by simply calling:
rusty-editor

[weekendkoder]

The accessibility of the engine would be better, if you provide binaries for the main systems. Maybe it could be a possibility in the future.

[DuckEater54]

The accessibility of the engine would be better, if you provide binaries for the main systems. Maybe it could be a possibility in the future.

Impossible for the most part. While bakcwards compatibility is possible for some versions, a .rgs file that has node script data relies on the editor being compiled with the game as a dependency.

The editor is instead, forwards compatible for a lot of it. A .rgs file with no script node data that was created by the editor installed from the cargo package manager can be used in a recent version such as one created by user compilation with game dependency.

But this back/forward compatibility is extremely limited, and installing a pre-built binary without dependency cannot use modern engine features. In the future at some point, when the Rust dependency injection, ABI and compilation produces stable and unchanging between compilations is fixed we will be able to use pre-built binaries

[DuckEater54]

It could be possible to distribute pre-built binaries, through various irritating and lengthy processes. And these pre-built binaries would be better quality than other user built binaries.

Theoretical fixes:

• currently the editor is built and handles UUID has references to scripts and plugins in the binary. As I understand it (from reading #development on the discord server), when saving an rgs file it saves these UUID to the .rgs file format and the engine does behind the scene stuff in runtime to utilise the scripts and plugins for each node that is active at the time.
  • an alternate theorised idea is to declare the UUID of plugins and scripts as an array or table at the beginning of a .rgs file, and for the editor to read that first and get an idea. The setback with this is that when saving new plugin or script information ID to the .rgs, it needs to be exactly the same as the Uuid!() macro is the actual program.
  • another idea related to this first idea is to utilise a fyrox data file in the root directory like Cargo.toml (for Cargo), Xargo.toml (for Xargo), Makefile (for cargo-make), rust-toolchain.toml (for Cargo) and to have the user define the UUID info and other data in there. Then when running the editor and selecting a project root, like Cargo it checks for a fyrox.toml file and procedurally/dynamically uses these during runtime. The advantage is simplicity and uniformity to set up for users. The setback is the amount of changes to how the editor/engine situation currently works. It also has the same problem it the user needing to exact the Rust declared UUID and the fyrox.toml.

These are just a couple ideas to utilise pre-built binaries efficiently, ultimately it comes down to MRDimas's choice. But seeing the editor become something that is more accessible to people would be nice. Ultimately I just don't like compiling things for a long time and so I think of alternative ways to make things faster in the longer run than shorter run.

[mrDIMAS]

@weekendkoder it is not possible. The main reason is that the editor needs to be compiled with the game attached to it as a plugin. https://fyrox-book.github.io/fyrox/beginning/scripting.html

[weekendkoder]

Okay. Thank you for all the detailed information. Lets see, which direction the engine will take in the future, related to this topic.