Live data from Hacker News

Bevy game engine 0.6

bevyengine.org

81–90 of 93 posts

Re: Bevy game engine 0.6

#81
post #47

Earlier quoted context omitted.

Make sure to use the Rust Analyzer extension, it's is significantly better than the default Rust extension.

I tried for a minute but it just wouldn't work out of the box and I didn't have time to investigate, so I reenabled the default for now. I thought I saw somewhere rust devs themselves recommending Rust Analyzer too

https://github.com/rust-lang/www.rust-lang.org/pull/1620

Re: Bevy game engine 0.6

#82

It looks great in a lot of respects, but I can't help but notice the aliasing. In the example scene at the top, when in motion, it probably looks like there's a snow storm going on in the foliage and on most of the wall/floor textures. To me good anti-aliasing strategies is the single most important factor when it comes to graphics. I don't really care about things looking realistic or whatever, but I do care about m…

> To get to the point: In some older games I've seen blurring (possibly due to hardware limitations) of further-away detailed textures reducing aliasing.

It sounds like your complaint might actually be with anisotropic texture filtering [0] which reduces the blurring you're describing, and is generally considered to improve quality.

[0] https://www.pcgamer.com/pc-graphics-options-explained/3/

Re: Bevy game engine 0.6

#83
post #44
post #21

Earlier quoted context omitted.

Thanks for your work. What is the support for low-end and mobile devices? I have tried developing with bevy on my old macbook with an Intel Iris graphics card, maybe not ideal but that is what I have and I want to support most hardware. Last time I tried the simple cube example made my fans spin. Is this something that can be alleviated?

We support low-end devices well (although this is a constant balancing act)! Bevy runs well on iOS currently (and we have WIP Android support ... we're working on re-enabling that asap). Fans spinning is a known issue, but it is generally decoupled from framerates (which tend to be fine). On some machines we are over-engaging cores, even with empty apps that do nothing ... my current theory is that we need to adjust…

iPhones have insanely performant GPUs for the form factor. I wouldn’t be surprised if the newer ones get better performance in Bevy than a lot of perfectly usable laptops.

Re: Bevy game engine 0.6

#85
post #72
post #4

Lead Bevy developer here: feel free to ask me anything!

I spent a few days making a (very) basic 2D game engine in Rust for fun. One thing I found is that I didn't find Rust that helpful in preventing bugs due to the nature of game engine code. For instance, I was using a generational array to store components. At some point I had a use-after-free bug in the generational array code that the Rust compiler could never catch. Also, components tend to have circular references…

I want to point out to unfamiliar readers that use-after-free in a rust generational array is a logic bug, where as use-after-free in just about any other non-rust context is undefined behavior. Rust's safety is helping here, not by preventing the bug altogether, but by severely limiting the damage it can cause.

Re: Bevy game engine 0.6

#86
post #72
post #4

Lead Bevy developer here: feel free to ask me anything!

I spent a few days making a (very) basic 2D game engine in Rust for fun. One thing I found is that I didn't find Rust that helpful in preventing bugs due to the nature of game engine code. For instance, I was using a generational array to store components. At some point I had a use-after-free bug in the generational array code that the Rust compiler could never catch. Also, components tend to have circular references…

[deleted]

Re: Bevy game engine 0.6

#87
post #72
post #4

Lead Bevy developer here: feel free to ask me anything!

I spent a few days making a (very) basic 2D game engine in Rust for fun. One thing I found is that I didn't find Rust that helpful in preventing bugs due to the nature of game engine code. For instance, I was using a generational array to store components. At some point I had a use-after-free bug in the generational array code that the Rust compiler could never catch. Also, components tend to have circular references…

Although I'm not _cart, I had a similar experience in making a (hobbyist) 2D game engine both in Rust and C++, and the problem you're facing (similar to the ABA problem) is not a memory safety error but more of a logical bug inherent in naively programmed object pools and is totally language-agnostic. When you create an object pool as Vec> and use a single array index as resource IDs, you risk this scenario: "X has a reference to resource A from object pool, A is destroyed and later reused by the object pool for resource B, now X has a reference to resource B". The problem is that the resource IDs will become invalidated as the object pool reuses its slots. The incremental generational counter is a way to check object lifetimes in object pools at runtime, and this is a solution to a logical error (which can be applied regardless if your language has a borrow checker or not). If you've had weird errors while using generational arrays, chances are that 1) you've exhausted your generational counter and it has overflowed 2) your generational array code is incorrect.

The verdict: Rust's lifetimes does not make you safe from non-memory-safety related bugs. It still gives you some really powerful abstractions to fight these bugs (like enums, traits, Option and Result types), but other than that you're on your own.

(About circular references between components... doesn't this also get solved by generational indices? With Arc types you're going to have circular dependencies that don't get freed because of reference counting, but with generational indices you're free from that issue since you're manually managing resource lifetimes anyway. And if you're having trouble figuring out how to manage these dependencies, the solution might be to refactor your code. My experience of using generational arrays was that it will naturally move your code-base towards centrally managing resources in a unified fashion, which is rather different than the usual Rust/C++ model of every object having its own independent ownership. After embracing it I tend to have less of those resource management dependency headaches.)

Re: Bevy game engine 0.6

#88
post #70

Earlier quoted context omitted.

I've tried Bevy v0.5 and it was very immature (as a matter of fact, all the Bevy "games" are single-screen). By looking at the release notes, it's not clear if it now supports OpenGL, which means that on some setups, it's not even possible to run correctly at all. It may be fun to write a hello world, but in this case, there are much easier (and more stable) engines. A typical setup if VSCode + Rust Analyzer. RA wasn…

What do you mean by single screen? There's no technical reason for that to be the case and there are already games that have multiple screens, even past the basic main menu + main game loop ones. You can find multiple functioning and fun, if small, games here https://bevyengine.org/assets/#games . > it's not clear if it now supports OpenGL Why do you need opengl when you have support for D3D, Vulkan, Metal, OpenglES,…

> What do you mean by single screen? There's no technical reason for that to be the case

I've programmed on v0.5, and SystemSet, which is the base for state management, was very immature - it didn't even work with FixedTimeStamp (because they will compete on RunCriteria); I think it's this one: https://github.com/bevyengine/bevy/issues/2233.

I've tried implementing multiple states in a game, and it just didn't work. And I don't even know if it was a bug in my code or in Bevy, because state support is not stable, and the documentation is lacking.

Without proper state management, you'll end up running either a large amount systems, or fewer systems, with code for all the cases inside.

Due to the problematic RunCriteria design, even synchronous assets loading is problematic. There is a plugin for that, but what if another plugin causes RunCriteria conflicts? Who knows.

> Why do you need opengl when you have support for D3D, Vulkan

Because Vulkan may be broken for one reason or another, and then one ends up with a system where OpenGL is not supported, and Vulkan doesn't work. My (modern) system is such case.

Re: Bevy game engine 0.6

#89
post #62

Earlier quoted context omitted.

There's a really good blog post about the engineering of mipmaps from the perspective of mipmapping messing up their VR game's text legibility here: https://bgolus.medium.com/sharper-mipmapping-using-shader-ba... (May have been featured on HN recently, I can't remember how I got there). Often mipmaps are pretty much automatic from the player's perspective, it's often kind of baked in by the developers when processing…

> (May have been featured on HN recently, I can't remember how I got there). John Carmack tweeted about it a few days ago (it always annoys me when I can't remember where I saw something).

Ohh, yes that's right, thanks!

Re: Bevy game engine 0.6

#90
post #47

Earlier quoted context omitted.

I tried for a minute but it just wouldn't work out of the box and I didn't have time to investigate, so I reenabled the default for now. I thought I saw somewhere rust devs themselves recommending Rust Analyzer too

https://github.com/rust-lang/www.rust-lang.org/pull/1620

[deleted]
Post reply on HN