Doing game dev and digital content creation in anything but C++ and some python is simply a fool's errand. Any decent software in this area needs to use libraries written in C++ to have even a remote chance of being successful. These libraries are often written in ways that makes wrapping them for other languages impossible or at least force the exclusion of some desirable features in the bindings. In other words, C+…
Why I rewrote the mesh generator of Dust3D from Rust to C++
61–70 of 283 posts
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#62Earlier quoted context omitted.
I never met a GC that can deal with millions of allocations per second while having several millions of objects in the young generations. Some mesh processing algorithms have a tendency to get you there very quickly if you do not employ custom allocators. At this point you already defeated the GC provided by the language.
You would have to be dealing with a very large number of meshes at once, if you were churning through millions of vertex and uv arrays per second. I can't say what you should use in this scneario. But this is a pretty niche scenario! And you would probably want to focus on parallelism, where C++ again is not the best.
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#63Earlier quoted context omitted.
Most programs don't need C++ performance. Java is usually within factor of two and usually fast enough.
Need is relative. If you can get the extra speed, why waste it? Life’s too short to spend it waiting for your computer. And in this case, the author does need cpp speed.
The app is Dust3D, a ease-of-use focused mesh editor which deals with simple meshes.
Certainly from the blog post you get the impression that programmer productivity is a consideration in his choice of language.
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#64Earlier quoted context omitted.
And it is a special snowflake because of that. Unity needs to pour a ton of resources into this to make it viable and competitive. IL2CPP and the Burst compiler are proof. A company with fewer resources would have to give up on this approach.
Mono runs fine. IL2CPP is more of a work around to get AOT on iOS and Burst is just a nice linter but you could write the same tight loops now and mostly likely get very close. Plus, Burst isn't even out so its odd to bring it up as necessary.
IL2CPP was required to be able to stick with C# and stay relevant for mobile gaming. They forced themselves into this corner by wanting to stay with C# and become relevant for mobile gaming.
Compare all this to Unreal. By sticking to C++, they do not have to commit the same amount of resources to programming language related tooling.
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#65Earlier quoted context omitted.
You would have to be dealing with a very large number of meshes at once, if you were churning through millions of vertex and uv arrays per second. I can't say what you should use in this scneario. But this is a pretty niche scenario! And you would probably want to focus on parallelism, where C++ again is not the best.
No, I am talking about operations that alter the topology of single large meshes. Just creating a single tesselated sphere with full topological information gets you there easily.
> Performant mesh manipulation code as a rule deals with largish float arrays (or other similar contiguous layouts, like AoS or SoA or indexed versions thereof). So there are no per-vertex objects to malloc/free or to track in GC.
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#66Doing game dev and digital content creation in anything but C++ and some python is simply a fool's errand. Any decent software in this area needs to use libraries written in C++ to have even a remote chance of being successful. These libraries are often written in ways that makes wrapping them for other languages impossible or at least force the exclusion of some desirable features in the bindings. In other words, C+…
The first non Unity non Unreal game I thought of, Celeste, uses C# and XNA. Lots of games use other languages these days.
When a game seems to be written exclusively in a high level language like C# then there is almost always a massive framework underneath that integrates a lot of shiny C and C++ libraries for the real heavy lifting.
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#67I suspect that mesh generation is very much a mutable algorithm domain and probably a high impedance mismatch with Rust.
For example, simple things like mapping a struct of three elements to a vector of three elements were, at one point, very difficult if not impossible in Rust.
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#68Earlier quoted context omitted.
> capacity to change Good luck making changes to a 100kloc Python codebase.
If you have good manners, Python codebases can easily grow over 100kloc mark. Static type annotations, using descriptive variable and class names, type checks on user input(esp. libraries) makes growth safe and simple.
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#69Earlier quoted context omitted.
No, I am talking about operations that alter the topology of single large meshes. Just creating a single tesselated sphere with full topological information gets you there easily.
Ah, we may be talking past each other then. So I reiterate my point from upthread: > Performant mesh manipulation code as a rule deals with largish float arrays (or other similar contiguous layouts, like AoS or SoA or indexed versions thereof). So there are no per-vertex objects to malloc/free or to track in GC.
Re: Why I rewrote the mesh generator of Dust3D from Rust to C++
#70I wonder how many of the Rust defenders in this article actually know C++ and have written a production used Rust system, instead of a side-project on github, so that they can compare in an informed way? The author certainly has, but who else has? Step forth priests of Rust! As for me: I use C++ at my job daily but have never done Rust so I cannot compare. What I do know about is "memory safety" in C++, and to be hon…
If you want to handle closing a socket, it’s as easy as implementing the Drop trait on your type. Without an unsafe block there’s no way your destructor won’t be called.
struct Socket(u16);
impl Drop for Socket {...}
To answer your question there’s no special casing around memory vs non-memory resources. Your socket is backed by a kernel ID which must exist in memory, of course, so by adding a Drop implementation you can then define the special treatment yourself. If threading considerations exist you can explore the Sync and Send marker traits too.
It’s largely a much simpler language than C++, you just have to learn how to write it. A lot of the friction/confusion IMO is that it looks so similar to languages you use at first glance you just start writing the code you used to in a Rust-y way, instead of Rust, then are frustrated as to why it won’t build.
In some ways it’d be clearer if it looked “foreign” like prolog — it’d be a lot less popular though haha.