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

71–80 of 125 posts

Re: Making a Game in Rust

#71

Post by vvanders »

eridius wrote: post #64
vvanders wrote: post #2

Great stuff, lines up a lot with what I'd care about as an ex-gamedev and spending a bit of time with Rust. One minor point: > First class code hot-loading support would be a huge boon for game developers. The majority of game code is not particularly amenable to automated testing, and lots of iteration is done by playing the game itself to observe changes. I’ve got something hacked up with dylib reloading, but it re…

A long time ago I wrote bindings to Lua 5.1 ( https://github.com/kballard/rust-lua ), but there was a nasty problem where Lua uses longjmp() for errors (it can be configured to use C++ exceptions, but that doesn't work because you can't throw those past an extern C boundary without hitting undefined behavior). longjmp(), of course, will just skip right past the intervening stack frames, meaning if your Rust code call…

That's still pretty much the state of the world. I think that's a trade-off that makes sense as long as you're aware that you shouldn't be depending on drop functionality in callbacks(I would hope that your initial point is dostring/dofile and let that catch handle things).

Generally I've found that any time you're interacting with an FFI in Rust all bets are off and you need to be very aware of what your libraries do and what their runtime looks like(just in C/C++).

Re: Making a Game in Rust

#72

Post by throwaway7645 »

Lerc wrote: post #48
steveklabnik wrote: post #44

Earlier quoted context omitted.

It's not a graphical game, but the introductory project in the book has been the "guessing game" for years now https://doc.rust-lang.org/stable/book/guessing-game.html

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 rubbish on my part ;). I do believe you're correct that certain people would like a graphical introduction more. Maybe you could write a cool intro to Rust with graphics!

Re: Making a Game in Rust

#73

Post by bluejekyll »

comex wrote: post #60
bluejekyll wrote: post #21

Earlier quoted context omitted.

The biggest problem I faced with Rust and macOS/iOS is related to Apple's requirement for bitcode on all submitted code to the App Store for Watch and appleTV applications. This internal Rust discussion focuses on it for more details: https://github.com/rust-lang/rust/issues/35968 This gist is that Apple is requiring bitcode, but isn't giving easy access to the LLVM version they use for their own tools. This means th…

It's not as bad as it sounds. The LLVM they ship in Xcode is basically stock, or at least it was in past releases where they posted the source - after all, Apple is the upstream for LLVM. And unlike the LLVM API , the LLVM bitcode format is stable and preserves backwards compatibility whenever possible, in the sense that newer versions of LLVM can read old bitcode. So there's a good chance that passing bitcode from r…

I agree that ostensibly it is possible. But what I would love is to see either: Apple show how to do it in a supported manner; or someone at least prove that it's possible. So far I haven't seen either.

To your comment about bitcode being stable, I don't think that bitcode stability and forward compatibility was something guarateed until 4.0.

Re: Making a Game in Rust

#74

Post by voltagex_ »

voltagex_ wrote: post #55
Pxtl wrote: post #9

Earlier quoted context omitted.

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.

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

Re: Making a Game in Rust

#75

Post by pandaman »

sillysaurus3 wrote: post #12
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…

To embed binary assets into any language, write a program that emits the binary as a string containing hex codes. E.g. bytes [0, 12, 99] would become "\x00\x0C\x63". Almost every language has facilities to treat a string as a set of bytes, so this works basically everywhere. It's nice because you don't need any special language-level support for it.

C++ string literals usually have fairly low maximum length (C++ standard suggests 64K in [implimits/2.16]). Initialized arrays can be longer in practice but they also have a limit (the same standard suggests 16K but even that will give you 128Kb if you initialize uint64). Objcopy, as suggested elsewhere in the comments has more comfortable limits.

Re: Making a Game in Rust

#76

Post by comex »

bluejekyll wrote: post #73
comex wrote: post #60

Earlier quoted context omitted.

It's not as bad as it sounds. The LLVM they ship in Xcode is basically stock, or at least it was in past releases where they posted the source - after all, Apple is the upstream for LLVM. And unlike the LLVM API , the LLVM bitcode format is stable and preserves backwards compatibility whenever possible, in the sense that newer versions of LLVM can read old bitcode. So there's a good chance that passing bitcode from r…

I agree that ostensibly it is possible. But what I would love is to see either: Apple show how to do it in a supported manner; or someone at least prove that it's possible. So far I haven't seen either. To your comment about bitcode being stable, I don't think that bitcode stability and forward compatibility was something guarateed until 4.0.

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-ea49ffd3fee5264c.rlib
    warning: overriding the module target triple with x86_64-apple-macosx10.12.0 [-Woverride-module]
    1 warning generated.
    % ./test
    Hello, world!
    % rustc --version
    rustc 1.18.0-nightly (91ae22a01 2017-04-05)
    % xcrun --toolchain XcodeDefault clang --version
    Apple LLVM version 8.1.0 (clang-802.0.42)
    Target: x86_64-apple-darwin16.6.0
    Thread model: posix
    InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
That's using Apple's compiler to compile bitcode from rustc. The .bc file has significant chunks of Rust's libstd embedded, so the test isn't as trivial as it seems. To embed bitcode as they want for the App Store, you can use -fembed-bitcode, except it doesn't work because liballoc_jemalloc wasn't compiled with that option (but that's trivial to fix).

I also tried compiling for iOS, which seems to work, but I didn't bother to test the resulting binary.

(As for stability, according to the announcement[1], the previous policy was that bitcode would be readable "up to and including the next major release", which was already reasonable from the perspective of keeping a third-party compiler's output compatible.)

[1] http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.htm...

Re: Making a Game in Rust

#77

Post by bluejekyll »

comex wrote: post #76
bluejekyll wrote: post #73

Earlier quoted context omitted.

I agree that ostensibly it is possible. But what I would love is to see either: Apple show how to do it in a supported manner; or someone at least prove that it's possible. So far I haven't seen either. To your comment about bitcode being stable, I don't think that bitcode stability and forward compatibility was something guarateed until 4.0.

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.

Re: Making a Game in Rust

#78

Post by eridius »

dragonwriter wrote: post #67
eridius wrote: post #66

Earlier quoted context omitted.

"products made by one brand" isn't a category of products. If they're the only brand that makes products for a particular category, then they're a monopoly, but you cannot simply define a category as "stuff made by that company", because by that logic, every company is a monopoly on stuff made by them.

Actually, a makers own products are a distinct market for antitrust purposes if people empirically don't substitute out of it, as shown by the producer having market (pricing) power. I wouldn't be surprised if that's true for Apple for some of its offerings.

It's not. The only product you could even try to make the argument for is the iPhone, but the generally-accepted categorization here is that iPhone and Android phones (and Windows phones) are part of the same category, which makes sense because people absolutely do switch between them.

Re: Making a Game in Rust

#79

Post by eridius »

vvanders wrote: post #71
eridius wrote: post #64

Earlier quoted context omitted.

A long time ago I wrote bindings to Lua 5.1 ( https://github.com/kballard/rust-lua ), but there was a nasty problem where Lua uses longjmp() for errors (it can be configured to use C++ exceptions, but that doesn't work because you can't throw those past an extern C boundary without hitting undefined behavior). longjmp(), of course, will just skip right past the intervening stack frames, meaning if your Rust code call…

That's still pretty much the state of the world. I think that's a trade-off that makes sense as long as you're aware that you shouldn't be depending on drop functionality in callbacks(I would hope that your initial point is dostring/dofile and let that catch handle things). Generally I've found that any time you're interacting with an FFI in Rust all bets are off and you need to be very aware of what your libraries d…

I had intended to write a compiler plugin for rust-lua that added a lint that would ensure you have nothing on the stack with Drop when you call a (potentially-error-throwing) Lua function. But I never got around to doing that because I stopped using rust-lua (I canned the one project I was doing that motivated rust-lua in the first place).
Post reply on HN