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

91–100 of 125 posts

Re: Making a Game in Rust

#91

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.

Actually I have a better argument against this than my other.

No, "products from brand A" is never a category. However, a company may create a brand new market with a product, and they may be the only company with a product in that market for a while. But that still doesn't mean the category is "products by that company", it just means it's whatever new category was created from the product.

For example, the iPhone arguably created a new category of smartphones. But competitors quickly introduced their own products in this same category (e.g. Android).

Re: Making a Game in Rust

#92

Post by MaulingMonkey »

Buge wrote: post #88

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.

I'd guess any performance problems are probably on the GPU / OpenGL side of things, which Rust won't help with (nor hurt). The Nexus 6 has a 1440p screen powered by a mobile GPU maybe a little weaker than previous generation consoles (~172 gflops max for the Adreno 420, vs e.g. ~220 for the PS3 [1]) that were often handling 720p titles (a quarter of the pixels). Very easy to exceed your frame budget.

[1] http://gpuflops.blogspot.com/

Re: Making a Game in Rust

#93

Post by esistgut »

It is an interesting educational project but staying away from Unreal or Unity3D is really a tough decision if your project is going to need some more features that are already developed and well tested in one of these engines.

Re: Making a Game in Rust

#94

Post by kbenson »

Manishearth wrote: post #70
kbenson wrote: post #63

Earlier quoted context omitted.

It's unfortunate that our profession emphasizes ease of learning so much. There are things you can make better to make a language easier to learn that don't affect usefulness, but at some point those mostly run out and there is a trade-off between making something easier to learn and easier to use . One brings more new people into the community, the other retains them by continuing to provide good value for invested…

I don't think the intent is to compromise on these :) But lots of things can be made easier to learn via better tooling, better docs, or better diagnostics. Or just removing papercuts. One such thing I've recently been thinking about is https://github.com/Manishearth/rust-clippy/issues/1737 , which would be cool if it got big.

Oh, that would be nice. :)

Rust, being largely of new things (in implementation and and presentation, if not theory), has plenty of room currently to explore changes and features that have little or no negative aspects. I'm a little worried about what happens when the low hanging fruit is fine though.

That said, rust has been very good so far at assessing the merit of proposed changes. I recall a few months back that reasoning was explained, and it assessed positive and negative aspects on a few well defined axes.

Re: Making a Game in Rust

#95

Post by golergka »

esistgut wrote: post #93

It is an interesting educational project but staying away from Unreal or Unity3D is really a tough decision if your project is going to need some more features that are already developed and well tested in one of these engines.

In my experience, the real value of the engines aren't "features", but tools oriented at level designers and artists. Once you have a project with 10 or more members, managing art and assets becomes a real headache - and most of homegrown solutions, as well as open source engines start to fall apart at this point.

Re: Making a Game in Rust

#96

Post by yorwba »

lifthrasiir wrote: post #90
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.

The problem was in the context of looking up min_by_key with the key being a floating-point number, so I think the only NaN-check necessary should be for that key. I did not intend to imply that it should be done for all calculations, only those that need totally-ordered floats. (Or if you are really sure NaN will never happen, you leave out the check altogether, and claim total ordering anyway.)

Re: Making a Game in Rust

#97

Post by frubar »

lifthrasiir wrote: post #90
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.

If the type proved there could be no NaN, why would the check be needed?

Re: Making a Game in Rust

#98

Post by talldan »

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/

Unfortunately, some of those syntax niceties the Garry's mod creator mentioned are things that have been identified as leading causes of bugs.

++ mutates a variable in place, has non-trivial pre/post behaviour (many junior devs don't understand it), and its brevity causes it to be used inline, which results in complex one liners.

String concatenation using '+' is not considered to be a great feature in dynamically typed languages. When you can't guarantee the types of the operands, it can lead to unexpected results. Pass in two numbers, and it this returns the result of the sum. Pass in two strings, and they're concatenated.

'continue' is a strange one. I just don't use it, and I'm not sure why anyone thinks it adds anything. It's like an early return, in that it can cause some difficulty in code comprehension.

So it feels a little like Lua is being criticised for making some good calls.

Re: Making a Game in Rust

#100

Post by stevedonovan »

curun1r wrote: post #51
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/

One that's not listed there but might be a good candidate for a Rust project is miri [1] since it's both interpreted and still Rust. It's still pretty rough, but the approach it takes should perform pretty well and won't require people to learn a new language. [1] https://github.com/solson/miri

It is outrageously fast (at least compared to compile) but would need integration via libffi to speak to the rest of the universe. This is not a priority for the maintainer, since he's exploring compile-time metaprogramming (where you want a very restricted sandbox)
Post reply on HN