Bevy game engine 0.6(bevyengine.org) |
Bevy game engine 0.6(bevyengine.org) |
But good tutorial!
Bevy's First Birthday: a year of open source Rust game engine development - https://news.ycombinator.com/item?id=28132114 - Aug 2021 (13 comments)
Bevy 0.5: data oriented game engine built in Rust - https://news.ycombinator.com/item?id=26716166 - April 2021 (65 comments)
Bevy: A game engine built in Rust - https://news.ycombinator.com/item?id=26131350 - Feb 2021 (117 comments)
Bevy 0.4: data oriented game engine built in Rust - https://news.ycombinator.com/item?id=25480321 - Dec 2020 (23 comments)
Making a Snake Clone with Bevy - https://news.ycombinator.com/item?id=24999073 - Nov 2020 (11 comments)
Bevy 0.3: game engine built in Rust - https://news.ycombinator.com/item?id=24983956 - Nov 2020 (55 comments)
Bevy 0.2 - https://news.ycombinator.com/item?id=24530698 - Sept 2020 (43 comments)
Bevy: A Game Engine in Rust - https://news.ycombinator.com/item?id=24334307 - Aug 2020 (42 comments)
Bevy: A data-driven game engine and app framework built in Rust - https://news.ycombinator.com/item?id=24123283 - Aug 2020 (103 comments)
I was wondering if there is any low hanging fruit for WebGL build size improvements.
I did a Unity test build for comparison against your rect example, with a cube and a single script that does nothing (so they can't e.g. strip out Mono).
Listing sizes uncompressed, 7z Ultra (a decent proxy for Brotli), and wasm-opt + 7z Ultra respectively:
Rect example: 13473kb, 1964kb, 1720kb
Basic Unity: 9528kb, 2304kb, 2291kb
Bevy is still leading, but it's getting uncomfortably close.
The uncompressed sizes matter a lot more than any other asset type, as it's all code that has to be compiled, running poorly until the optimized compiler has finished with it. On a Chromebook, my experience is that much code gives you 30-60s of poor FPS before it comes good.
I understand this is not necessarily a focus of Bevy, but I do think that you have an opportunity here to build the first game engine without significant downsides on any single platform. Filling the code base with a bunch of feature flags may not be worth it to achieve that goal, though.
The modularity of Bevy is super exciting (I've asked you before about WebGL builds on here before and you mentioned this). But Unity ships quite a bit of stuff in a basic build and is probably fairly similar in scope to Bevy with all crates.
Please also consider Unity web used to be significantly worse and it took multiples of bevy's lifetime for it to get to where it is now :)
I've been sponsoring for close to a year, but haven't kept up with the Discord in many months. Currently I'm just been checking for updates every couple of weeks, and sometimes checking the state of GitHub issues and milestones.
However, is there any better way for me to keep up with progress? If not, has there been any thought about having regular status updates? They don't have to take a lot of your (or someone else's) time, but just a few sentences on what's been decided, what's happened, etc, would be nice! Once every 30 or 60 days would definitely be enough.
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<T> and Result<T, Err> 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<T> 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.)
https://github.com/bevyengine/bevy/tree/main/examples/input https://github.com/bevyengine/bevy/blob/main/examples/3d/loa...
We're planning to follow Godot and dogfood the UI to build out the editor, so support for pure GUI applications is something that we'll be actively testing.
Also, I tried to search for the answer to this: is there any information on ways to make a game build with bevy moddable?
I wonder why do you have version zero.something - this looks good enough for a version 1.
What do you like to accomplish?
And... What kind of help you'll need to get there??
For example, we want to rework our input handling, asset handling and UI; supporting this current UI solution indefinitely would be frustrating when we hope to make something much better once we can focus on that. As an example of this, we massively changed our rendering APIs for this release, allowing the improvements listed in the blog post to be implemented.
The What's Next For Bevy? heading in the release announcement covers this:
The birds in the logo tie into the name! But I don't know about its origin beyond that.
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 my screen not being full of moving, weird, and distracting grainy patterns.
This involves more than just softening the edges around polygons. There's also textures that contain shapes and the borders in textures with transparency to think about (usually foliage).
My go-to solution in games with lackluster anti-alias is to just render them at a super-high resolution (4k/8k) and downscale, but that's not great for performance usually. You can compensate a bit because you won't need as much anisotropic filtering and such if you downscale, but even on expensive hardware that's not a solution in all games.
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. I'd love to see that technique revived in more modern games, possible with the help of AI to detect patterns/edges on textures that may be susceptible to aliasing, and selectively running those through a filter - basically shifting the work from the artists having to design textures that don't create artifacts to something automatic.
In general good AA tends to be a second-class citizen in many modern game engines, partly because of how their renderer is configured by default (looking at you, Unreal). I really wish it wasn't so.
If you use this project and you can afford to donate, you definitely should!
Having paid close attention to the Bevy Discord this past year, the sheer amount of work that's happened on this release is mind-boggling.
Maybe what I'm asking for is impossible, because fighting those patterns any further would just go too far into blurry territory. It might just be an inherent property of projecting something on a grid of neatly ordered pixels, which is very unlike the receptors in our eyes.
Though to be honest, I didn't even consider that it may just be missing mipmaps making it look like that. My perspective is much that of a consumer who spend a lot of time trying out various settings/technologies and ordered them into "looks bad" and "looks better".
If you check the release notes, you'll see HDR/Bloom support was dropped at the last minute, and several other major rendering features are still pending implementation. [0]
The great part about Bevy is that it's modular, so you can swap out the renderer if you like. For example, there's already several people using Bevy with Embark's kajiya renderer.[1]
[0] https://bevyengine.org/news/bevy-0-6/#more-renderer-features
I don't think I've ever heard this perspective before. Thank you for sharing your thoughts. This one is pretty unique, I think.
By "lackluster anti-alias" do you mean some sort of home-grown MSAA that's garbage?
Because you're hand-rolling SSAA/FSAA, can't you just override the AA settings in the graphics driver to force FSAA or something?
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/
But also the suggestions are spot on quite often, eg finding the right import that you can just click without scrolling up to the top to insert, or adding/removing the & and * operators. You'll almost never come across a situation where you think it will compile but it doesn't.
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't very stable around 6 months ago, but it was stable enough to be used regularly.
> it's not clear if it now supports OpenGL
Why do you need opengl when you have support for D3D, Vulkan, Metal, OpenglES, and WebGL2? What amount of the market are you missing?
The reason you don't see many Bevy games is 1) yes, it's new and relatively immature and 2) it takes a long time to make a game. That said, I've had a lot of fun building out a tbs game with it and have been very impressed with the foundation so far. On top of that you get to write in Rust which for me is a huge productivity boost when compared to writing in say C# for Unity, but that's subjective.
Don't forget to also add Microsoft's C/C++ tooling for the debugging support.
I had a runtime error with my first Bevy game too, because I forgot to add a resources to my app before I used it.
It just means the render stages are customizable, therefore is more flexible. See Unity as an example.
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.
My take: Software isn't used exclusively on new computers.
I was just reading a forum thread full of complaints that a certain emulator won't work on 4th-gen i5 laptops. I want the software I write to be accessible to owners of machines at least as old as that, and I hope I can do that with Bevy.
That being said, as far as I know Bevy is modular enough to write third party render backends. If it keeps growing, I'm sure someone will do that.
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 the texture files. It can probably be disabled but I can't remember seeing that option in a game for a while.
I'm curious to see how Bevy's doing it. I'm making a game in Godot at the moment, and their is the option there to generate mipmaps or not for an imported texture, and you can choose use a bilinear or trilinear filtering for the mipmaps, but that's about it (maybe there's more in the API, I haven't checked.)
> Maybe what I'm asking for is impossible, because fighting those patterns any further would just go too far into blurry territory. It might just be an inherent property of projecting something on a grid of neatly ordered pixels, which is very unlike the receptors in our eyes.
Basically it solves this exact problem - that rendering a high res image at a lower size can lose details at points you don't want them to (e.g. because some part of the texture like a line is entirely in subpixel "space"), and pre-processing a lower res image to switch to at different distance thresholds from the camera. The result is actually better details at scaled down sizes, with much less flickering, even though the actual rendered texture at a distance can be much lower quality.
They can also save a bit of GPU power and possibly VRAM, as the lower res, distant textures stream much more quickly than the ultra high res, near ones.
John Carmack tweeted about it a few days ago (it always annoys me when I can't remember where I saw something).
I thought I saw somewhere rust devs themselves recommending Rust Analyzer too