You are not logged in. Please login or register.
AudioGames.net Forum → Developers room → Making games with Rust?
So recently, I have been checking out Rust a bit, and I like how fast it compiles and runs, and the Cargo package manager.
The executables make pyinstaller look like a baby toy.
I'm wondering, however, if it'd be possible to make good games with it.
Its possible. There are good game engines out there (Amethyst comes to mind) but as for audio? You've got Alto -- an OpenAL wrapper for Rust. There's rfmod, but that hasn't been maintained, to my knowledge. There's SDL2, which should do good for you in regards to input, rendering, etc. Networking.. there are lots of ways of doing this one.
+1
A semi-joking comparison of Rust and Go: https://matthias-endler.de/2017/go-vs-rust/
Rust would be my pref, but it will be so much hard work.
While I'm at it I should change from OpenGL to Vulkan.
Because Rust & Vulkan.
While I'm at it I may also pick up one of Apple's recently announced $1,430USD monitor stands.
I'm looking for a way to build a DLL with rust.
I wanted it to export
add(f:i32, s:i32) ->i32 {
f+s
}
It's supposed to add 2 numbers together, but when I put crate-type=['cdylib'] under the [lib] section of cargo.toml, the resulting DLL only exported rust_eh_personality?
Can you please tell me what I'm doing wrong?
It seems like it'd be really cool to make DLLS with Rust rather than C.
Thanks!
Hi,
have you specified, that it should be exported?
extern "C" fn add(a: i32, b: i32) -> i32
{
a+b
}Means, that add method should be exported using C calling convention.
Best regards
Rastislav
Oh! No I didn't. I had no idea about that sintax.
I did some searches on Google, and it said nothing about that.
Thanks a lot!
@5 is sort of correct.
To make a function export itself in rust, add the following before it:
#[no_mangle]
This prevents Name mangling.
Additionally, remember the difference between dylib, staticlib, and cdylib:
--crate-type=dylib, #[crate_type = "dylib"] - A dynamic Rust library will be produced. This is different from the lib output type in that this forces dynamic library generation. The resulting dynamic library can be used as a dependency for other libraries and/or executables. This output type will create *.so files on linux, *.dylib files on osx, and *.dll files on windows.
--crate-type=staticlib, #[crate_type = "staticlib"] - A static system library will be produced. This is different from other library outputs in that the compiler will never attempt to link to staticlib outputs. The purpose of this output type is to create a static library containing all of the local crate's code along with all upstream dependencies. The static library is actually a *.a archive on linux and osx and a *.lib file on windows. This format is recommended for use in situations such as linking Rust code into an existing non-Rust application because it will not have dynamic dependencies on other Rust code.
--crate-type=cdylib, #[crate_type = "cdylib"] - A dynamic system library will be produced. This is used when compiling a dynamic library to be loaded from another language. This output type will create *.so files on Linux, *.dylib files on macOS, and *.dll files on Windows.
(Source: https://doc.rust-lang.org/reference/linkage.html.)
So, in summary:
If you want a rust library DLL (which is compiler-defined), use crate-type = ["dylib"].
If you want something that can be called from another language, use crate-type - ["cdylib"]
If you want a static library, use crate-type = ["staticlib"]
Finally, in your DLL, either add:
pub
before your function, or:
pub extern "C"
If you want structures/enumerations/... visible in your DLL, add:
#[repr(C)]
Before the struct/enum/... in question.
Just a question... why are you doing this -- do you know the language sufficiently enough for this to be useful to you?
+1
I am trying to make a DLL that I can use from Python with ctypes.
It was sort of an experiment.
I wanted to start with an add function, then maybe make something more useful.
I did use the advice from number 5, here is the src/lib.rs file:
pub extern "C" fn add(f:i32, s:i32) ->i32 {
f+s
}
This creates a DLL, and then I ran dependency walker which can show all the exported functions. There was only 'rust_eh_personality", even if the name got mixed up, shouldn't there be something else?
My cargo file is like this
[package]
name = "dll"
version = "0.1.0"
authors = ["Keith"]
edition = "2018"
[dependencies]
[lib]
name="test"
crate-type=["cdylib"]
Thanks.
Edit: Also, this came from home, I don't have the VC build tools installed on here
@8, you need to add #[no_mangle] before the function and before pub extern "C". I'd recommend you run dumpbin /exports on the DLL instead of using dependency walker. See post six.
+2
Also note that, the instant you move beyond basic primitives, you're going to have to start tossing around u64s representing pointers to your objects, then converting them to and from Rust structs. IOW, it's probably not a good idea to just create a DLL in Rust because it's fun, unless that's your only goal.
I.e. write your project in whatever language you're familiar with. Then, if and only if you've identified performance bottlenecks or areas in the code that you'd like extra safety on, rewrite those paths in Rust.
I've got a Rust project for which I'm trying to export C/JNI interfaces, and the overhead of that isn't huge, but it's something. Glad I wrote and significantly tested the project first before working on the FFI bridges. They're both very distinct sets of problems.
@10, I've never passed pointers around; the most I've passed around are large structs with references.
Ugh, yes. Dealing with Python bytes seems to require an array of u8 and then I just stop when I find a 0. I guess recieving unicode strings requires an array of chars.
Is there some kind of reference on how to convert between all the types, like, which types will Python convert into what, and which will just cause it to crash?
I did think if I was going to make a DLL that managed objects, I'd pass numbers from the init function and the DLL would manage the objects based on the number you passed. I don't think I came up with this idea though, 
@12, what are you exactly trying to do in Rust with this DLL? Making a DLL is complicated in any language; Rust just simplifies it a *tiny* bit.
I was thinking I'd make something to simplify making games and help with things like sounds.
@14, in a DLL? That would be pretty hard to do, man. You can do it, but I'd just recommend you make your hole game in rust if your going to do that.
AudioGames.net Forum → Developers room → Making games with Rust?
Generated in 0.028 seconds (61% PHP - 39% DB) with 11 queries