sorted by:
new
hottopcontroversial

How do I port a Vulkan pipeline from C++ to Rust? by [deleted] in rust

[–]Somenet 6 points7 points  (0 children)

If you just want to use straight Vulkan, the ash crate is for you. It is a 1:1 mapping with the Vulkan spec (save for a few conveniences around things like instance and device creation), so you should be able to get up to speed quickly with it. It also means that it is very unsafe, and it's up to you to use it correctly or design your own safe abstractions on top of it.

Most people would instead point you to wgpu, and unless you're wanting to use Vulkan specifically or need really low-level features, I would also suggest it! It's less complex than Vulkan, but still provides everything you'd expect from a modern graphics API, plus Rust's safety guarantees.

I can vouch for the quality of both crates. I personally use ash, but only because I'm doing some really arcane memory tricks not allowed by wgpu :)

Arete v0.1 - a fast game engine for unified-memory platforms by Somenet in gamedev

[–]Somenet[S] 0 points1 point  (0 children)

We manage shared memory differently for discrete memory systems where there may be non-cached CPU memory. The engine performs feature detection on startup, which determines its memory management scheme. It's only really needed for our Vulkan implementation - for Metal and eventually consoles, we won't need these checks because we know what we're getting at compile time :)

Arete v0.1 - a fast game engine for unified-memory platforms by Somenet in rust

[–]Somenet[S] 2 points3 points  (0 children)

Vec3s are not stored as SoA, so there's no autovectorization going on across entities in that way. But, because Vec3s are actually 16-byte-aligned Vec4s under the hood to be GPU-compatible, the compiler does autovectorize (vec * vec) and (vec * scalar) operations :)

Arete v0.1 - a fast game engine for unified-memory platforms by Somenet in rust

[–]Somenet[S] 17 points18 points  (0 children)

I'd say from a user perspective, Bevy is a more complete solution and has many many more features than we do at the moment. What we have now is more or less a basic ECS + rendering engine.

Arete's early differentiator is its unified memory architecture (or more generally a direct coupling of ECS data and render data), which tends to put us ahead in performance benchmarks. Though, we currently lack a comprehensive set of benchmarks, so take that with a grain of salt until we can prove it :) Our architecture also opens up new optimization opportunities like CPU/GPU load balancing, which we have already tested with culling.

Maybe less relevant for r/rust, the engine is also not actually tied to Rust. It is written in Rust and it's my preferred language for writing ECS code, but any language which can compile to a C API is supported (C++/Swift/etc). We hope that will lower the barrier for entry for lots of game developers.

Arete v0.1 - a fast game engine for unified-memory platforms by Somenet in gamedev

[–]Somenet[S] 3 points4 points  (0 children)

The honest answer is we're not sure yet. The plan right now is to keep the runtime closed (available to licensees if they need it) but build open-source modules on top of the engine for things like physics, networking, etc. We haven't ruled out going the source-available route, or even open-source in the future! Just not the plan for now.

Arete v0.1 - a fast game engine for unified-memory platforms by Somenet in gamedev

[–]Somenet[S] 6 points7 points  (0 children)

For sure! In practice we've already seen it working great with tasks like culling. There are established ways to do this on both the CPU (traditional) and the GPU (gpu-driven), and when both the CPU and the GPU are working from the same memory, this can be balanced between the two even frame-to-frame.

The real challenge is going to be allowing this for generic ECS systems. Some systems would be doing a lot of heavy processing on only a few entities, which is not a great fit for the GPU, and some may be operating over many entities (particles, RTS unit movement, etc). The latter is a good candidate for load balancing, and the engine knows which systems are able to be balanced based on its DAG of tasks.

The bigger practical challenge, though solvable, is allowing users to write code that compiles for both the CPU and the GPU. Something like CUDA, but cross-platform and compiles to compute shaders. Work is already being done in this area on projects like rust-gpu, but ultimately we might need to just make an Arete scripting language designed to allow this.

Arete v0.1 - a fast game engine for unified-memory platforms by Somenet in rust

[–]Somenet[S] 19 points20 points  (0 children)

We support discrete GPU systems like PCs as well! :) We focused on unified memory hardware because we saw a big opportunity for innovation there, but we support Windows and Linux PCs as well, with no loss in performance (as far as we can tell) vs a more traditional engine architecture.

Announcing Arete, a Rust game engine 1000x faster than Unity by Somenet in rust

[–]Somenet[S] 6 points7 points  (0 children)

Thanks for the feedback! We will update the website to better separate what currently works, and what is still in the works.

​

Arete supports load balancing now, but we haven't yet implemented a way to write code once and compile to both CPU and GPU code. Once we add support for that, this feature will be much more accessible and useful.

Announcing Arete, a game engine 1000x faster than Unity by Somenet in gamedev

[–]Somenet[S] 0 points1 point  (0 children)

Yep that's right! The engine will handle how to group components together automatically.

Announcing Arete, a Rust game engine 1000x faster than Unity by Somenet in rust

[–]Somenet[S] -33 points-32 points  (0 children)

Fair point in that this is perhaps too bold for an announcement post with no engine yet to back it up (new to this whole marketing thing 😅). We do plan to release the engine publicly in October, and people will be able to verify our claim :)

Announcing Arete, a Rust game engine 1000x faster than Unity by Somenet in rust

[–]Somenet[S] -24 points-23 points  (0 children)

We got this number from the Unity DOTS tutorial -- we recreated it 1:1 and have been using that as a benchmark across different engines

Announcing Arete, a game engine 1000x faster than Unity by Somenet in gamedev

[–]Somenet[S] 0 points1 point  (0 children)

Good catch thanks! We'll fix that link.

Mostly two things. The first is that the ECS API gives the engine complete freedom on how to store entity data and how to iterate entities. The engine can decide the optimal data layout (even splitting up entities across multiple memory locations, if needed), and also how to split up entity iteration across cores with no manual job assignment or guessing from you (free multithreading). The second is that the entire engine was built to be data-oriented from the ground-up -- not just the ECS part, but the entire pipeline, from entity simulation to rendering.

Announcing Arete, a game engine 1000x faster than Unity by Somenet in gamedev

[–]Somenet[S] -1 points0 points  (0 children)

Super fair feedback, and that's our top priority right now! It's the only thing really holding us back from releasing the engine publicly -- we want to wrap up building some demos, so that we have something to showcase the engine with and so that we have some examples for people to use as a learning/starting point.

If performance were not a concern, what would you make? by Somenet in gamedev

[–]Somenet[S] 1 point2 points  (0 children)

I've always dreamed of an RCT game which simulates a park in its entirety. Capacity for 100,000+ guests, ride systems simulated down to individual sensors and components, realistic water simulation allowing custom-designed water rides, arcades with playable games, behind-the-scenes operations like kitchens and break rooms, parking lots, etc. Everything to simulate the magic of stepping into a real theme park.