Skip to content

N23: Add "Writing the Bevy Retro Renderer" #700

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Merge branch 'source' into features/n23-writing-bevy-retro-renderer
  • Loading branch information
ozkriff authored Jul 6, 2021
commit 29b67e2e7d68731efa145cbf2ec7ac4f7cbb462e
132 changes: 131 additions & 1 deletion content/news/023/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -288,7 +288,137 @@ they tried and explain why they wrote their own renderer in the first place.
[bevy_retro]: https://github.com/katharostech/bevy_retrograde
[@katharostech]: https://github.com/katharostech

## Library & Tooling Updates
## Tooling Updates

### [Sugarcubes]

![Sugarcubes Example](sugarcubes.png)

[Sugarcubes] by [@henryksloan] is a tool for designing and testing automata.

Sugarcubes allows for easy creation of models used in the theory of computing.
It is designed to be a more intuitive and useful alternative to JFLAP,
the most popular tool for designing automata and formal languages.
It uses macroquad for the editor, and egui for the toolbars. Sugarcubes
currently features a fully functional finite automaton editor and simulator,
and many other models, editing features and simulations are planned.

You can check out a [live WASM demo here][Sugarcubes],
or the [source code on Github][Sugarcubes source].

[Sugarcubes]: https://henryksloan.github.io/sugarcubes/
[Sugarcubes source]: https://github.com/henryksloan/sugarcubes
[@henryksloan]: https://github.com/henryksloan

### [Rusty Slider]

![Rusty Slider code block example](rustyslider.png)
_Supports syntax highlighting of code blocks_

[Rusty Slider] by [@ollej] is a markdown slideshow viewer
written with macroquad.

The game engine Macroquad can be used for more than just games. It’s also a
great way to quickly build multi-platform tools with graphics.

It’s possible to write presentations in plain text using Markdown. The
application runs natively on all major platforms, and can also be used within
a browser.

- Supports headers, bold/italic, blockquotes, lists, and code blocks with
syntax highlighting.
- Automatically change slides.
- Themes separated from content.
- Toggle a CRT shader.

The latest feature added was to execute bash code blocks. The output of the
execution will be shown below the code block. This is meant to be used for
demo purposes, to show actual results of commands.

[Rusty Slider]: https://ollej.github.io/rusty-slider
[@ollej]: https://twitter.com/ollej

## Library Updates

### [backroll-rs] and [GGRS]

[backroll-rs] ([Discord](https://discord.gg/VuZhs9V),
[crates.io](https://crates.io/crates/backroll)) by [@james7132] and
[GGRS]([crates.io](https://crates.io/crates/ggrs)) by [@g_schup] are pure
Rust implementations of the [GGPO] rollback networking library.

![Evo Moment 37](rollback.jpg)
_[Evo Moment 37](https://www.youtube.com/watch?v=JzS96auqau0):
Only offline or with rollback!_

Rollback networking is a peer-to-peer network technique designed to hide
network latency in fast-paced games with precise inputs. Traditional techniques
account for network transmission time by delaying the game execution, resulting
in a sluggish game-feel. Rollback uses input prediction and speculative
execution instead. Upon receiving inputs from remote clients, resimulation of
incorrect game states occurs. This allows for gameplay that "feels just
like offline". The open source standard for rollback netcode [GGPO] is used
in successful games like Skullgirls, Guilty Gear XX Accent Core +R or
Fightcade. For further explanation about rollback,
[click here](https://ki.infil.net/w02-netcode.html).

Two projects in Rust were independently created to provide a working
implementation as well as helpful resources for developers.
backroll-rs features an added abstraction for the transportation layer and
also provides a bevy plugin, [bevy-backroll]. GGRS replaces the
C-style callback API of GGPO with a simpler, more understandable control flow.
The authors of both libraries recommend backroll-rs for developement,
as it is currently more actively collaborated on.
GGRS is recommended as a learning recource and entry point,
with a plethora of internal documentation and explanation.

The main requirement to make use of both presented libraries is determinism
in your game execution. Resimulation requires that the result of progressing
the game state depending on the given inputs yield the exact same results
every time. Additionally, you need to be able to load, save and progress
your gamestate without rendering the outcome.

If you are interested in integrating rollback networking into your game or
just want to chat with other rollback developers (not limited to Rust),
check out the [GGPO Developers Discord]!

[backroll-rs]: https://github.com/HouraiTeahouse/backroll-rs
[bevy-backroll]: https://github.com/HouraiTeahouse/backroll-rs/tree/main/bevy_backroll
[GGPO Developers Discord]: https://discord.gg/8FKKhCRCCE
[GGRS]: https://github.com/gschup/ggrs
[GGPO]: https://www.ggpo.net/
[@g_schup]: https://twitter.com/g_schup
[@james7132]: https://twitter.com/james7132

### [CrystalOrb]

[![CrystalOrb demo animation](crystalorb.gif)][crystalorb-demo]
_Interactive [demo][crystalorb-demo] that uses the [Rapier] physics engine._

[CrystalOrb] by [@ErnWong] is a new networking library that aims to help
fast-paced client-server games synchronize their game state across multiple
clients. Just like [backroll-rs] and [GGRS], each CrystalOrb client predicts
the next game state without waiting for other remote players' inputs to arrive.
Unlike backroll-rs's and GGRS's peer-to-peer approach which only send input
data between its peers, CrystalOrb relies on having a server to send
authoritative snapshots of the entire game state to each client. In response,
each client unconditionally rolls-back to that snapshot. Although this may lead
to higher network and memory usage, it means that CrystalOrb clients can join
and leave at any time, and games that cannot guarantee full-determinism can
still work with CrystalOrb.

This library was written as a learning exercise for the author, and as such,
the author warns that this library may not be suitable for serious games.

There is an [interactive demo][crystalorb-demo] of CrystalOrb that features the
[Rapier] physics engine.

[CrystalOrb]: https://github.com/ErnWong/crystalorb
[@ErnWong]: https://github.com/ErnWong
[crystalorb-demo]: https://ernestwong.nz/crystalorb/demo
[backroll-rs]: https://github.com/HouraiTeahouse/backroll-rs
[GGRS]: https://github.com/gschup/ggrs
[Rapier]: https://rapier.rs

### [erupt]

Expand Down
You are viewing a condensed version of this merge commit. You can view the full changes here.