$ cargo run --example hello_world
Finished dev [optimized] target(s) in 0.38s
Running target\debug\examples\hello_world.exe
thread 'main' panicked at 'assertion failed: !gl_dx_interop_device.is_null()', D:/rust/.cargo\registry\src\mirrors.tuna.tsinghua.edu.cn-df7c3c540f42cdbd\surfman-0.4.3\src\platform\windows\wgl\device.rs:159:13
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
error: process didn't exit successfully: target\debug\examples\hello_world.exe (exit code: 101)

cargo 1.55.0-nightly
rustc 1.56.0-nightly
Windows 11
Windows Feature Experience Pack 421.18901.0.3

Hi,

first, thanks for the great work, it looks promising! I'm new to bevy and rust, thanks for your patience. I was trying to adapt the ldtk map loading for my project and I encountered some issues. I think it's a bug, but not 100% sure.

First, to test it, I ran the actual ldtk_map.rs example from the cloned repo, it works fine. Then, I moved the example to main.rs. It still compiles fine. Then, I also linked to the online crates what I could.

At this point I have:

[package]
...
name = "bevy_retrograde"
...

[features]
default = ['ldtk']
ldtk = ["bevy_retrograde_ldtk"]

[dependencies]
bevy = {version = "0.5", default-features = false}

bevy_retrograde_core = {version = "0.2"}
bevy_retrograde_ldtk = {version = "0.2", optional = true}
bevy_retrograde_macros = {version = "0.2"}
hex = "0.4.3"

[dev-dependencies]
hex = "0.4.3"
rand = "0.8.3"

[profile.dev]
debug = 0
opt-level = 1

that I can run with cargo run. This runs fine. The bevy_retrograde is still loaded from the lib.rs !

Then I copy the exact same code (main.rs and Cargo.toml) to my project. The difference is that the lib.rs is not present, so I add the line:
bevy_retrograde = "0.2"
in the Cargo.toml file.

But somehow running the same code from my project, it still compiles fine, but when running it, it panics:

Finished dev [unoptimized] target(s) in 26.22s Running target/debug/my_projectOct 02 21:25:26.869 WARN bevy_asset::asset_server: noAssetLoaderfound for the following extension: ldtk thread 'Compute Task Pool (4)' panicked at 'Requested resource does not exist: bevy_asset::assets::Assets<bevy_retrograde_ldtk::asset::LdtkMap>', /home/luc/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_ecs-0.5.0/src/system/system_param.rs:244:17 note: run withRUST_BACKTRACE=1 environment variable to display a backtrace thread 'main' panicked at 'task has failed', /home/luc/.cargo/registry/src/github.com-1ecc6299db9ec823/async-task-4.0.3/src/task.rs:368:45

However, if I copy the lib.rs from the repo, it compiles and run fine (all the code is identical, so...yeah, makes sense ^^) if I include the lib:

[lib]
name = "bevy_retrograde"
path = "src/lib.rs"

Am I missing something or is there an issue with loading the ldtk plugin from the crate?

I'm struggling to access world coords with a mouse click. My current attempt is along the lines of:

if let Some(pos) = window.cursor_position() {
    if let Ok((camera_transform, camera)) = q_camera.single() {
        let low = camera.get_target_sizes(window).low;
        let size = Vec2::new(low.x as f32, low.y as f32);
   
        let p = pos - size / 2.0;
        let pos_wld = camera_transform.compute_matrix() * p.extend(0.0).extend(1.0);
        let pos = Vec2::new(pos_wld.x, -pos_wld.y);

        info!("world xy", pos);
    }
}

However I can't seem to figure out the correct way to find the coords and am not sure whether bevy_retrograde will require a different calculation (I'm trying to move a sprite to an ldtk tile).

Apologies for making an issue as I know it's not a bug, but I'm not sure where else to ask and have been stuck on this for a while!

Related to the text rendering comment in #50.

There are three different strategies that we know of that Bevy Retrograde could use for pixel rendering. We currently use what we dub here the "Crips Scalable" version, but there are also a couple other versions that we should implement as configurable modes.

Summary

Crisp Scalable ( Current )

The crisp scalable model uses simple "nearest" mode filtering for the pixels, which retains the pixels' sharp edges, and we allow scaling the screen to match the camera size to the window size, allowing the game to be played at any zoom.

The disadvantage of this technique is that at non-integer scales, the in-game pixels will not line up perfectly with the physical pixels of the users screen and the result will be that some rows and columns of pixels may be taller or wider than the others.

Smooth Scalable

The smooth scalable model uses an anti-aliased filtering technique that preserves the squareness of pixels at any scale, but results in a blurrier appearance and can lose the crisp edges.

Crisp Fixed Scale

The crisp fixed scale model will preserve the sharp edges of the pixels, and make sure that they remain perfect squares, but will restrict the scaling level to integer values such as 1x, 2x, 3x, 4x, etc. This means that when the window size is, for instance, 1.5x the game will render at 1x scale with a border around it.

We need to derive Reflect on all of our Bevy Retro types and we need to register them so that you can load and save Bevy RON scenes with Bevy Retro components in them.

This might be related to #7, but I've tried to integrate bevy_retro into my project but I'm getting the same error the mentioned issue got:

    ... required by package `luminance-glow v0.0.0 (https://github.com/katharostech/luminance-glow?branch=master#ca5a0b62)`
    ... which is depended on by `bevy_retro_core v0.0.0 (https://github.com/katharostech/bevy_retro?branch=master#a3086444)`
    ... which is depended on by `bevy_retro v0.0.0 (https://github.com/katharostech/bevy_retro?branch=master#a3086444)`
    ... which is depended on by `zworld v0.1.0 (/home/zebra/projects/zworld-rs)`
versions that meet the requirements `^0.3.48` are: 0.3.50, 0.3.49, 0.3.48

all possible versions conflict with previously selected packages.

  previously selected package `web-sys v0.3.46`
    ... which is depended on by `bevy_app v0.5.0`
    ... which is depended on by `bevy_asset v0.5.0`
    ... which is depended on by `bevy_audio v0.5.0`
    ... which is depended on by `bevy_internal v0.5.0`
    ... which is depended on by `bevy v0.5.0`
    ... which is depended on by `zworld v0.1.0 (/home/zebra/projects/zworld-rs)`

As the issue said, I tried to cargo update with no success. My Cargo.toml looks like this:

[dependencies]
bevy = "0.5"
bevy_retro = { git = "https://github.com/katharostech/bevy_retro", branch="master" }
bevy_tilemap = { git = "https://github.com/joshuajbouw/bevy_tilemap", branch="master" }

I am pretty new to rust, but I added this to my Cargo.toml:

[dependencies.bevy]
git = "https://github.com/bevyengine/bevy"
branch = "main"
default-features = false
features = ["bevy_winit", "x11"]

[dependencies.bevy_retro]
git = "https://github.com/katharostech/bevy_retro"
branch = "master"
default-features = true

I get this error when I try to cargo run demo code:

    Updating git repository `https://github.com/bevyengine/bevy`
    Updating git repository `https://github.com/katharostech/bevy_retro`
    Updating crates.io index
    Updating git repository `https://github.com/katharostech/luminance-glow`
    Updating git repository `https://github.com/katharostech/luminance-surfman`
    Updating git repository `https://github.com/GrovesNL/glow.git`
error: failed to select a version for `web-sys`.
    ... required by package `luminance-glow v0.0.0 (https://github.com/katharostech/luminance-glow?branch=master#ca5a0b62)`
    ... which is depended on by `bevy_retro v0.0.0 (https://github.com/katharostech/bevy_retro?branch=master#1642ef8b)`
    ... which is depended on by `pakemon v0.1.0 (/Users/konsumer/Documents/otherdev/pakemon-rust/crates/pakemon)`
versions that meet the requirements `^0.3.48` are: 0.3.50, 0.3.49, 0.3.48

all possible versions conflict with previously selected packages.

  previously selected package `web-sys v0.3.46`
    ... which is depended on by `bevy_app v0.5.0 (https://github.com/bevyengine/bevy?branch=main#bc13d11c)`
    ... which is depended on by `bevy_asset v0.5.0 (https://github.com/bevyengine/bevy?branch=main#bc13d11c)`
    ... which is depended on by `bevy_internal v0.5.0 (https://github.com/bevyengine/bevy?branch=main#bc13d11c)`
    ... which is depended on by `bevy v0.5.0 (https://github.com/bevyengine/bevy?branch=main#bc13d11c)`
    ... which is depended on by `bevy_retro v0.0.0 (https://github.com/katharostech/bevy_retro?branch=master#1642ef8b)`
    ... which is depended on by `pakemon v0.1.0 (/Users/konsumer/Documents/otherdev/pakemon-rust/crates/pakemon)`

failed to select a version for `web-sys` which could resolve this conflict
make: *** [pakemon] Error 101

Hi, I am really new to rust & Bevy, I tried to import the Bevy Retro plugin but I am unable to build it
My depencies are setup as that :

[dependencies]
bevy = { version = "0.5", default-features = false }
bevy_retro = { git = "https://github.com/katharostech/bevy_retro.git" }

However when trying to build (=running cargo run), this is what I get :

Any ideas of what I am doing wrong ?

I tried adding this plugin to my project, but there is a conflict happening when using Color, I know I can resolve it by using the explicit import, but if this keeps happenning with other things it would be bad. And there are some errors of non-implemented traits as shown in the error:

error[E0659]: `Color` is ambiguous (glob import vs glob import in the same module)
  --> src\main.rs:42:31
   |
42 |             background_color: Color::new(0.2, 0.2, 0.2, 1.0),
   |                               ^^^^^ ambiguous name
   |
note: `Color` could refer to the enum imported here
  --> src\main.rs:1:5
   |
1  | use bevy::prelude::*;
   |     ^^^^^^^^^^^^^^^^
   = help: consider adding an explicit import of `Color` to disambiguate
note: `Color` could also refer to the struct imported here
  --> src\main.rs:2:5
   |
2  | use bevy_retro::prelude::*;
   |     ^^^^^^^^^^^^^^^^^^^^^^
   = help: consider adding an explicit import of `Color` to disambiguate

error[E0277]: the trait bound `bevy_retro::RetroPlugins: bevy::prelude::PluginGroup` is not satisfied
 --> src\main.rs:7:22
  |
7 |         .add_plugins(RetroPlugins)
  |                      ^^^^^^^^^^^^ the trait `bevy::prelude::PluginGroup` is not implemented for `bevy_retro::RetroPlugins`

error[E0599]: no variant or associated item named `new` found for enum `bevy::prelude::Color` in the current scope
  --> src\main.rs:42:38
   |
42 |             background_color: Color::new(0.2, 0.2, 0.2, 1.0),
   |                                      ^^^ variant or associated item not found in `bevy::prelude::Color`

error[E0277]: the trait bound `bevy_retro::prelude::CameraBundle: Bundle` is not satisfied
  --> src\main.rs:38:27
   |
38 |       commands.spawn_bundle(CameraBundle {
   |  ___________________________^
39 | |         camera: Camera {
40 | |             // Set our camera to have a fixed height and an auto-resized width
41 | |             size: CameraSize::FixedHeight(100),
...  |
46 | |         ..Default::default()
47 | |     });
   | |_____^ the trait `Bundle` is not implemented for `bevy_retro::prelude::CameraBundle`

error: aborting due to 4 previous errors

my cargo.toml dependecies looks like this:

[dependencies]
bevy = { version = "0.5.0", default-features = false }
heron = { version = "0.5.0", default-features = false, features = ["2d"] }
bevy_retro = { git = "https://github.com/katharostech/bevy_retro", branch = "master" }

I'm also very new with Rust and Bevy, so maybe I am doing something wrong?

• Spawn a camera in a fixed virtual height mode, like the examples do manually
• Add an Egui scaler system that uses the camera settings to adjust the UI scale.

We need the basics necessary for UI:

• Sprites that can be anchored to different sides of the screen
• Possibly use a ninepatch system similar to bevy_ninepatch.
• A sprite-based text and font system.

Here is a print of what is happening:

Currently Bevy Retro has not been found to work on MacOS. Being that we do not have a Mac readily available to test on, it is difficult for us to debug, though it should be possible to make Bevy Retro work on Mac, and it is a goal to do so, at least eventually.

We could use help from anybody who develops on MacOS and has time to test and possibly attempt to fix issues, with which I would be glad to assist.

Current State

In our only test done on a Mac, we got a solid red screen. I'm not sure what that means. I have heard that OpenGL is being deprecated on Mac, but I have not heard of them totally disabling it yet. I believe that Bevy Retro, on desktop, runs on OpenGL 3.0, but on web it uses WebGL 1.0 which is very close to OpenGL ES 2.0. I believe that it would be possible to make Bevy Retro run on desktop using OpenGL ES 2.0 without changes to the renderer, if we are using OpenGL 3 it is because it was what was easy to get the surfman crate to give us on desktop.

The red screen may be a simple driver issue or rendering setting that needs to be fixed to make it work on Mac.

Something worth investigating is to use MetalANGLE which could be used to run using the non-deprecated Metal API on MacOS by translating our OpenGL ES 2.0 calls to Metal calls. We might be able to gain some insight from the experience of wezterm.

Other Options

Another possiblity for targeting MacOS, that would be unfortunate but still worth it if it is the only way, is to use a native webview such as Tauri and wrap that around the WebGL 1.0 build of the game. This is less desirable because of performance limitations, we only get one thread, and the fact that it may require more manual bindings to the webview to emulate native behavior such as file access, etc.

Bevy has been updated to version 0.6.0 but this package doesn't support it

This should be an external crate that is included with a default feature flag into Bevy Retro. We need a plugin that can be used for saving arbitrary data that works with Browser Local Storage or files on your filesystem.

Currently, when loading sounds specifically, blocking tasks can freeze the main game and cause drastic visible lags. What we need is a task pool that can be used for running blocking tasks that can use a separate thread on native platforms and on WASM can use a web worker.

When i run any program made with bevy_retrograde i have a bug that make a seccond window pop and stay for less than 0.1s while the game's window is loading

• Fix WASM screen size adjustment
• Fix WASM/OpenGL Map Rendering Bleeding Issues : StarArawn/bevy_ecs_tilemap#197
• Update README and API docs

Just wanted to ask whether the owners are intending to continue development on this project! There are no new features as such that I need, more so asking out of curiosity.

probably 1st thing I've encountered is long compile time of examples in release:

adsick@pop-os:~/Rust/Crates/bevy_retrograde$ cargo run --features ldtk,epaint --example epaint --release
   Compiling bevy_retrograde v0.1.0 (/home/adsick/Rust/Crates/bevy_retrograde)
    Finished release [optimized] target(s) in 5m 00s
     Running `target/release/examples/epaint`

I'm not kidding, it really takes 5m taking into account that I've already built the bevy_retrograde crate in release mode.
yep my hardware is old (4c intel core i5-3330 & 8G DDR3 RAM & 1Tb HDD), but that not seems like an excuse for it (at least I think so)

2nd text.rs example is not pixel perfect (not sure if it has to be)
looks kinda odd to me

3rd sprite movement in hello_world is odd too, it is not smooth&looks glitchy
4rd epaint results are not looking pleasant

not awful but not perfect

We want Bevy Retro to be a on-stop-shop, kind of like an alternative "Bevy standard library" so it should come with a sound plugin that is suitable for basic game music and sound-effect needs and that runs on desktop and in the browser. This should probably implemented as an independent Bevy plugin that can be used without Bevy Retro, but that comes with Bevy Retro behind a default-enabled feature flag.

After some investigation, we think we are going to try switching to Bevy's renderer, instead of using our own. Here's the pros and cons:

Pros:

• Better support for MacOS: while we could very likely get our current renderer to work on MacOS, it might be with deprecated technology ( aka. OpenGL ) or a workaround technology such as MetalAngle which would be less optimal
• More work offloaded onto Bevy: we have to maintain less technology ourselves because Bevy is taking care of a larger portion of the work
• ( maybe ) Higher performance ( maybe also lower performance until bevy has batching, but that will come )
• We depart less from the typical Bevy way of doing things and probably allow for integration between Bevy Retro and non Bevy Retro projects ( we are currently fully in-compatible with any normal Bevy rendered projects ).

Cons:

• We have to change our current renderer: just some work, but probably not too bad ( optimistically ~2 weeks, but maybe a month. We'll know more after we get into it ).
• We lose support for iOS web browsers: being that we are getting better MacOS support, and we can eventually make a full-powered iOS app instead, this is not a huge deal
• Won't run on old desktops without Vulkan support without a little extra work: This is not a big deal, though because it would probably take not more than 4 days of work to get that functionality back by porting bevy_webgl2 to run on desktop ( mrk-its/bevy_webgl2#45 ) The work-in-progress WGPU on master has support for OpenGL ( and WebGL2 incomming ) and we have been actively helping with the effort to fix some outstanding bugs.

Bevy's renderer is currently in the middle of an overhaul ( bevyengine/bevy#2351 ) so now is not the best time to do the actual port. Once Bevy work is finished, though, I think this is a good thing to do.

Tasks

• Get initial OpenGL support working with Bevy ( not all the examples work with the new pipelined renderer )
• Migrate Bevy Retrograde's pixel-perfect camera to use Bevy's renderer
• 🚧 Get WebGL2 support working in WGPU for the WGPU examples
• Fix anything necessary in WGPU to get the new renderer working on OpenGL. For now Bevy rendering bugs on OpenGL that don't effect our 2D rendering is out of scope.
• Get our renderer and Bevy working on on WebGL2. For now Bevy rendering bugs on WebGL2 that don't effect our 2D rendering is out of scope.

We need to integrate Egui instead of RAUI for UI.

It should be trivial to just re-use the existing bevy egui plugin.

• Integrate Egui plugin
• Implement with 9-patch widget for Egui
• Implement image-themed buttons
• Implement retro-font handling

Heho,
I've been stumbling across your crate noticed following things:

The hello_world example was removed from the crate in commit 165107b .
Was this intentional? A simple example is a good idea and I think you'd want to add it again.

Is a new release planed? It seems the main branch is already up to date with the current bevy version but you have no new release. This makes usage of the crate a bit harder.

A common problem with the current bevy design is that it doesn't allow for y-ordering of sprites in case of the same z.
This is a very common for top-down games for the player to walk behind objects as well as be able to stay infront.
I think this would fit perfectly in a crate targeting 2d pixel games! :)

I noticed there was no LICENSE.md on this repo, which makes it very challenging for others to build off of safely.

This work looks incredible, and I (among many others) would love to be able to use it, contribute to it, promote it and so on. To do so though, it needs a reasonably standard open source license.

The Katharos license used on your other projects, independent of any planned uses or ethical / religious disagreements, is a complete deal breaker for every interested user I've talked to :( It induces very complex legal risk due to challenges in definition and lack of case law, and even incorporating a library with the license presents a serious barrier to getting downstream users and contributors who may disagree with certain ethical or religious implications contained within the license.

Promoting good in the world and staying true to your beliefs is the right thing to do, and I admire your devotion to what you believe in. I'm just not convinced that ethical open source licenses are a good tool to get there.

The intent behind them is twofold:

1. Prevent your work from being used for objectionable purposes.
2. Allow others who share your goals to benefit from your work.

But in effect, the level of uncertainty induced by them is such that only the first goal succeeds at all, leaving these fantastic projects that can't be used by anyone completely stranded.

Feel free to reach out, either here or by email. I'm happy to talk at length about my perspective on these matters, and see if I can help you come to a solution that helps you share and collaborate in a way that's compatible with your values.

The following error was found when trying to get setup on a Mac system on nightly rust. I noticed that currently there isn't support for Mac after the fact but the description outlined in the Mac OS support ticket is different then what I ran into trying to get started.

error[E0658]: use of unstable library feature 'assoc_char_funcs': recently added
   --> /Users/teodorcrnobrnja/.cargo/registry/src/github.com-1ecc6299db9ec823/bevy_retrograde_text-0.1.0/src/bdf.rs:140:33
    |
140 |                 let codepoint = char::from_u32(encoding).ok_or("Could not parse character encoding")?;
    |                                 ^^^^^^^^^^^^^^
    |
    = note: see issue #71763 <https://github.com/rust-lang/rust/issues/71763> for more information
    = help: add `#![feature(assoc_char_funcs)]` to the crate attributes to enable

After running into this I added #![feature(assoc_char_funcs)] to my main.rs file but there was no change. I am currently running the following toolchain: info: default toolchain set to 'nightly-x86_64-apple-darwin'

Another thing to note is that there is currently a discrepancy in the Sample on crates.io and on Github, the Github version resulted in some errors regarding the Transform function which wasn't present on crates.io, so it should be noted the errors above happened when running the Sample on crates.io.

Somebody has apparently taken the bevy_retro name on Crates.io recently. It's my fault I didn't claim the name earlier!

That brings up the question of what we should do. I think we have two options:

• Rename our Bevy Retro to something else
• Ask if the person who has taken the name would mind transferring it to us

I think that we should try to come up with names and if we can't find one we like better to ask if the owner minds a transfer.

Any ideas for names? 🙂

The epaint integration is currently rather half-baked. The rendering does not look smooth, like the anti-aliasing is broken somehow. This is not a very high priority item currently, and will probably wait until #41 is finished, at which point we might just be able to re-use bevy_egui, but this issue is to make sure we don't forget to address this.

Today my console started being flooded by these messages, any idea what could be causing it?

PS C:\Users\user\Documents\Bevy Projects\platformer> cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 1.92s
     Running `target\debug\platformer.exe`
[C:\Users\user\.cargo\git\checkouts\bevy_retro-714805c4148cd6d9\8a44707\crates\bevy_retro_core\src\graphics\hooks\sprite_hook.rs:114] ent = 3v0
[C:\Users\user\.cargo\git\checkouts\bevy_retro-714805c4148cd6d9\8a44707\crates\bevy_retro_core\src\graphics\hooks\sprite_hook.rs:114] ent = 1v0
[C:\Users\user\.cargo\git\checkouts\bevy_retro-714805c4148cd6d9\8a44707\crates\bevy_retro_core\src\graphics\hooks\sprite_hook.rs:114] ent = 2v0

Trying to run an example via:
❯ cargo run --features="ldtk" --example ldtk_map

The window loads but with a black screen. This seems to be the case for all examples (hello_world)
Testing on OSX 10.14.6.

adsick@pop-os:~/Rust/Crates/bevy_retrograde$ cargo build

    Updating crates.io index
    Updating git repository `https://github.com/katharostech/heron.git`
error: failed to get `heron` as a dependency of package `bevy_retrograde_physics v0.1.0 (/home/adsick/Rust/Crates/bevy_retrograde/crates/bevy_retrograde_physics)`

Caused by:
  failed to load source for dependency `heron`

Caused by:
  Unable to update https://github.com/katharostech/heron.git?branch=ktech-patches#c555ad6f

Caused by:
  object not found - no match for id (c555ad6f4f327fe23276df0d87ac8879e5ced744); class=Odb (9); code=NotFound (-3)