Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making a Game in Rust

michaelfairley.com

Post reply on HN
Print view View original

81–90 of 125 posts

Re: Making a Game in Rust

#81

Post by 0xcde4c3db »

throwaway7645 wrote: post #72
Lerc wrote: post #48

Earlier quoted context omitted.

Yeah, it's the dynamic interactivity that I was looking for. I'm afriad console IO isn't a starter here. I'm sure it's fine as a console IO example, but it's just a completely different class of thing.

I'm actually a huge proponent of learning through text type games in lieu of more complicated graphics related black boxes where someone is essentially letting a library do 98% of the work. A text game is literally as simple as it gets while requiring no modules (well maybe IO or system if your language doesn't include it by default). Guess my number also is seems more mathematical although that is just subjective ru…

I think the issue isn't text versus complicated graphics, it's that the only thing you can do with most standard libraries is buffered line I/O, which doesn't feel like directly controlling anything. If you could just read the actual keyboard and poke some letters into a 2D text array, it would enable a whole different kind of interaction.

Re: Making a Game in Rust

#82

Post by comex »

bluejekyll wrote: post #77
comex wrote: post #76

Earlier quoted context omitted.

I mean, it's certainly possible for simple cases. I just tried: % cat test.rs fn main() { println!("Hello, world!"); } % rustc --emit llvm-bc -C lto test.rs % LIB=$HOME/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib % xcrun --toolchain XcodeDefault clang -o test test.bc ~/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-ea49ffd3fe…

That's an excellent example, thank you! I wonder if the dependency on jemalloc can go away once custom allocators stabilize. Then the macOS system allocator could be used.

You could get rid of jemalloc, but on the other hand you could also just compile it with -fembed-bitcode. (It's part of the Rust standard library, so that's a bit more work. Rust code doesn't have this issue because .rlibs contain serialized ASTs, and passing -C lto makes rustc only use that rather than use the precompiled bits. In any case, it's just a matter of rebuilding.)

Incidentally, I just tried updating my nightly Rust, and it stopped working - clang started failing to read the bitcode, bailing out with a vague "error: Invalid record". This is not too surprising, because Rust just landed a big LLVM upgrade two weeks ago. Newer LLVM can read older bitcode files but not the other way around, and even though LLVM 4.0 was released months ago, Apple seems to only sync with trunk yearly, along with major Xcode releases. (You can tell based on the --version output.)

However, Rust can be built against an external LLVM (rather than the fork it uses by default), and AFAIK it tries to preserve compatibility with older versions. So it should still be possible to use the latest rustc, you just have to compile it yourself against a slightly older LLVM.

edit: corrected thinko about .rlibs

Re: Making a Game in Rust

#83

Post by flukus »

0xcde4c3db wrote: post #81
throwaway7645 wrote: post #72

Earlier quoted context omitted.

I'm actually a huge proponent of learning through text type games in lieu of more complicated graphics related black boxes where someone is essentially letting a library do 98% of the work. A text game is literally as simple as it gets while requiring no modules (well maybe IO or system if your language doesn't include it by default). Guess my number also is seems more mathematical although that is just subjective ru…

I think the issue isn't text versus complicated graphics, it's that the only thing you can do with most standard libraries is buffered line I/O, which doesn't feel like directly controlling anything. If you could just read the actual keyboard and poke some letters into a 2D text array, it would enable a whole different kind of interaction.

NCurses (https://github.com/jeaye/ncurses-rs)?

Re: Making a Game in Rust

#85

Post by sitkack »

jamescostian wrote: post #27
aschampion wrote: post #23

Earlier quoted context omitted.

Lua is great and generally the right tool for this sort of thing. As an alternative, though, there are several Rust-based scripting languages that attempt to expose some of the power of the type system, etc., while being more amenable to dynamic loading, REPL, etc: http://libs.rs/scripting/

Dyon (from that link) looks very cool! I'd also like to add that JavaScript is another language used in this arena, and there is a crate with V8 bindings ( https://crates.io/crates/v8 ). Even Garry Newman (creator of Garry's mod) wrote that he believes JS would have been better than Lua for scripting: https://garry.tv/2014/08/16/i-fell-out-of-love-with-lua/

He even invoked Wadler's Law!

It really is too bad that JavaScript is different from Lua. Lua predates it by 2 years. [1]

Criticizing a language on syntax is something I would hope we could move past. Mr Newman didn't read about the history and purpose of Lua, otherwise he would know it was targeted at scripting data loads for simulations written in Fortran. Hence the 1 based indexing. Lua syntax is one of its SELLING points.

[1] https://www.lua.org/versions.html

Re: Making a Game in Rust

#86

Post by Pxtl »

voltagex_ wrote: post #74
voltagex_ wrote: post #55

Earlier quoted context omitted.

I wonder how XNA's asset pipelines worked. I also wonder if you could "pack" a binary into an assembly by writing a tiny bit of IL around it.

http://stackoverflow.com/a/28191247

Yeah, that's the workflow I was mentioning, cooking the file into a resource by referencing it as resource in the csproj, but then it's keyed by a string of the file-path within the project file, which isn't nearly as nice as having it bound to a variable in C#.

Re: Making a Game in Rust

#87

Post by flukus »

Pxtl wrote: post #9
wyldfire wrote: post #6

> The include_* macros are great for “packaging”. Being able to compile small assets directly into the binary and eschewing run time file loading is fantastic for a small game. For C/C++/etc devs looking for something similar, BFD objcopy supports an "-I binary". It will emit an object file with _binary_objfile_start, _binary_objfile_end and _binary_objfile_size symbols. But I have got to say that making it a languag…

Agreed. I code in C# and there's facility for bundling assets into the binary but they're handled at the project file level and not the C# file level, and this means the keys to access this binary content is not available as a compile-time constant. You're still just passing strings around and hoping they match. Having first-class language support for resource files looks fantastic.

> and this means the keys to access this binary content is not available as a compile-time constant

Isn't that exactly what resource files give you or am I confusing something? Anything you add in resource files have are accessible as a static variable.

Re: Making a Game in Rust

#88

Post by Buge »

The performance on my Android phone (Nexus 6) is not good. I would have thought Rust would be fast. The fps is fairly low, a lot lower than Maps or Chrome, at least when Maps isn't freezing up. And it seems the transitions between levels might be proportional to fps, because they are irritatingly long.

Re: Making a Game in Rust

#89

Post by yorwba »

About floats implementing PartialOrd and not Ord:

I have not tried out Rust yet, but couldn't this be solved by wrapping the float in a single-field struct that checks for NaN on construction, implements Ord using PartialOrd and otherwise passes everything through to the ordinary float inside?

If this isn't possible, I'm definitely interested in the reasons.

Re: Making a Game in Rust

#90

Post by lifthrasiir »

yorwba wrote: post #89

About floats implementing PartialOrd and not Ord : I have not tried out Rust yet, but couldn't this be solved by wrapping the float in a single-field struct that checks for NaN on construction, implements Ord using PartialOrd and otherwise passes everything through to the ordinary float inside? If this isn't possible, I'm definitely interested in the reasons.

Every calculation will have to check for NaN, so it's a non-starter when you need a lot of float calculations.
Post reply on HN