4 ms·

Lately I've been under the extreme temptation to rewrite my game engine in Rust. I crave the ergonomy of rust development. I use Rust at my job (not game dev)

Lately I've been under the extreme temptation to rewrite my game engine in Rust. I crave the ergonomy of rust development. I use Rust at my job (not game dev) and it sucks to switch back to C++ for my side projects But I resist for the moment, because I fear it won't be easy as I predict and it would delay my projects. I already started using this list of features and refactored most of my code for c++20. I hope C++ will continue on that path and catch up Rust. But there are still so many things missing In the meantime I refactor little by little my C++ projects to be "rust ready": hierchical ownership, data oriented with minimalist oop. So the day I can't resist no more I will be able to quickly rewrite it in Rust

bluGill 3y ago
Rust doesn't allos dynamic libraries in general, so it isn't going to work where (right or wrong) the code is based on plugins. You can work around this with C api interfaces, but that limits you if both sides are rust. (unsafe for what should be safe as I understand.)
- jzwinck 3y ago
  Instead of literally loading the plugin into the same address space as the host process, you could launch it as a separate process and use sockets or shared memory to communicate. With a slight shift in API design this might actually be better than traditional dynamically loaded plugins. It will tend to level the performance playing field across languages (e.g. no JNI penalty for plugins written in a JVM language). And it will prevent plugins crashing the host.
  - anarazel 3y ago
    And the dispatch overhead will be a few orders of magnitude higher.
    - jzwinck 3y ago
      Passing a message via a shared memory queue (twice) is not 1000x slower than a non-inlineable function call.
      - gpderetta 3y ago
        That actually seems about the right order of magnitude.
      - anarazel 3y ago
        With the associated context switch it's bigger, if anything. Busy looping to wait if some memory changes isn't really viable for many scenarios.
      - kllrnohj 3y ago
        You're right, but that's also not the entire workload. You have to also wake up the remote process in some way and, depending on the expected duration, probably wake up for the response. On pretty much all major platforms that work is measured in 10s of microseconds, which puts you easily into the 1000x slower than a non-inlineable function call category.
- Ygg2 3y ago
  Wdym doesn't allow dynamic library in general? You can have `dylib` as crate type.
  - rwmj 3y ago
    We wrote some Rust *.so files, but had to use a C (not even C++) ABI to communicate between them. It's definitely possible, but quite clunky.
    - etra0 3y ago
      is it any better in C++, though? IIRC C++ doesn't have a stable ABI either. If you either commit to dylib or C++'s DLLs, you still have to recompile everything on version change, unless you also use the C ABI in C++.
      - pton_xd 3y ago
        One common use case for DLLs in gamedev is for code hotloading. You can just recompile your game DLL and unload / reload the library, patch up some globals and vtable pointers and voila, your game logic has been updated without restarting the game. And all that you get just writing normal C++. This is only for development. Shipping builds will usually statically link everything.
        etra0 3y ago
        > And all that you get just writing normal C++. But, as far as I understand, the boundary layer has to still be C (the side that loads DLLs and stuff), because of the natural limitations of templated languages and linkers. And as soon as you change any interface you'd need to recompile more parts of the code. The same can be applied with Rust using dylib. At the end, the glue code always end up being C.
        kllrnohj 3y ago
        On any given compiler you can make C++ have a stable ABI. You can even do this commonly in practice across compiler versions, even, the standard library typically tries to achieve this. It's easier to have a long term cross version cross compiler stable C ABI, but if you're talking a single toolchain that simplifies the problem tremendously and you can absolutely do that with C++ in practice at that point
- deleted 3y ago
  [deleted]
deleted 3y ago
[deleted]
jihiggins 3y ago
it really depends on what type of game you're making

bluGill 3y ago

Rust doesn't allos dynamic libraries in general, so it isn't going to work where (right or wrong) the code is based on plugins. You can work around this with C api interfaces, but that limits you if both sides are rust. (unsafe for what should be safe as I understand.)

jzwinck 3y ago
Instead of literally loading the plugin into the same address space as the host process, you could launch it as a separate process and use sockets or shared memory to communicate. With a slight shift in API design this might actually be better than traditional dynamically loaded plugins. It will tend to level the performance playing field across languages (e.g. no JNI penalty for plugins written in a JVM language). And it will prevent plugins crashing the host.
- anarazel 3y ago
  And the dispatch overhead will be a few orders of magnitude higher.
  - jzwinck 3y ago
    Passing a message via a shared memory queue (twice) is not 1000x slower than a non-inlineable function call.
    - gpderetta 3y ago
      That actually seems about the right order of magnitude.
    - anarazel 3y ago
      With the associated context switch it's bigger, if anything. Busy looping to wait if some memory changes isn't really viable for many scenarios.
    - kllrnohj 3y ago
      You're right, but that's also not the entire workload. You have to also wake up the remote process in some way and, depending on the expected duration, probably wake up for the response. On pretty much all major platforms that work is measured in 10s of microseconds, which puts you easily into the 1000x slower than a non-inlineable function call category.
Ygg2 3y ago
Wdym doesn't allow dynamic library in general? You can have `dylib` as crate type.
- rwmj 3y ago
  We wrote some Rust *.so files, but had to use a C (not even C++) ABI to communicate between them. It's definitely possible, but quite clunky.
  - etra0 3y ago
    is it any better in C++, though? IIRC C++ doesn't have a stable ABI either. If you either commit to dylib or C++'s DLLs, you still have to recompile everything on version change, unless you also use the C ABI in C++.
    - pton_xd 3y ago
      One common use case for DLLs in gamedev is for code hotloading. You can just recompile your game DLL and unload / reload the library, patch up some globals and vtable pointers and voila, your game logic has been updated without restarting the game. And all that you get just writing normal C++. This is only for development. Shipping builds will usually statically link everything.
      - etra0 3y ago
        > And all that you get just writing normal C++. But, as far as I understand, the boundary layer has to still be C (the side that loads DLLs and stuff), because of the natural limitations of templated languages and linkers. And as soon as you change any interface you'd need to recompile more parts of the code. The same can be applied with Rust using dylib. At the end, the glue code always end up being C.
        kllrnohj 3y ago
        On any given compiler you can make C++ have a stable ABI. You can even do this commonly in practice across compiler versions, even, the standard library typically tries to achieve this. It's easier to have a long term cross version cross compiler stable C ABI, but if you're talking a single toolchain that simplifies the problem tremendously and you can absolutely do that with C++ in practice at that point
deleted 3y ago
[deleted]

deleted 3y ago

[deleted]

jihiggins 3y ago

it really depends on what type of game you're making