cloudhead / rgx.legacy Goto Github PK

What changed in version 0.2.0? Adding a changelog would be very nice.

Hi! I'm interested in creating a filled in polygon from a series of lines. I noticed rgx has the ability to create lines, so I could create the outline of a polygon from a series of lines, but not sure about filling it in. Is this currently possible? If it's possible, I'm willing to add an example to the examples/ folder to demonstrate it!

It looks like the switch to put the renderer in its own feature flag caused the documentation for the core module to be omitted from docs.rs:

https://docs.rs/rgx/0.8.1/rgx/

compared to:

https://docs.rs/rgx/0.6.0/rgx/

I'm a bit new to publishing crates myself, and my quick google-fu failed me, so I'm putting in this issue in hopes someone with more know-how can submit a PR.

In the process of adding more to my engine, I've identified two minor inconsistencies in the public API.

• shape2d::Circle does not have its fields marked as pub, which means if you're trying to modifying a Circle either by mutation or by copying to a new structure, you can't actually retrieve the inner values of the Circle struct. This is different than the rest of the shape2d kit.
• shape2d::circle() takes a Point2<f32> rather than an Into<Point2<f32>>. The other shape2d types take Into<> values

I'll be submitting a small PR for these changes shortly

cargo run --example shapes --features="renderer" creates a window but it does not draw anything.
I had to comment out two occurences of window.request_redraw(); to make it work.
All the other examples work normally.

Are there plans to include this functionality?

It could be done using wgpu_glyph, but this requires the wgpu::Device handle to be exposed (a simple method on rgx::core::Device would suffice I think).

My engine that I based on rgx is panicing on linux. All of the examples work fine except the threaded example. Here's the backtrace:

thread '<unnamed>' panicked at 'assertion failed: `(left == right)`
  left: `0`,
 right: `1`', /home/ecton/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-native-0.4.3/src/command/mod.rs:266:23
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:78
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1069
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1504
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:198
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:218
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:511
  11: rust_begin_unwind
             at src/libstd/panicking.rs:419
  12: std::panicking::begin_panic_fmt
             at src/libstd/panicking.rs:373
  13: <wgpu_native::hub::Storage<T,I> as core::ops::index::Index<I>>::index
             at /home/ecton/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-native-0.4.3/src/hub.rs:120
  14: wgpu_native::command::command_encoder_begin_render_pass::{{closure}}
             at /home/ecton/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-native-0.4.3/src/command/mod.rs:266
  15: core::option::Option<T>::map
             at /home/ecton/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/option.rs:456
  16: wgpu_native::command::command_encoder_begin_render_pass
             at /home/ecton/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-native-0.4.3/src/command/mod.rs:264
  17: wgpu_command_encoder_begin_render_pass
             at /home/ecton/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-native-0.4.3/src/command/mod.rs:739
  18: wgpu::CommandEncoder::begin_render_pass
             at /home/ecton/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-0.4.0/src/lib.rs:1059
  19: rgx::core::Pass::begin
             at src/core/mod.rs:837
  20: rgx::core::Frame::pass
             at ./src/core/mod.rs:794
  21: threaded::main::{{closure}}
             at examples/threaded.rs:68
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

If I enable Vsync, the panic goes away both in the example and in my code. I attempted to investigate updating rgx to wgpu 0.5 to see if that would help, but there are significant API changes that I wasn't sure how to handle.

Are there any plans to introduce an ability to rotate sprites added to the sprite batch?

In theory, it should be pretty easily done by introducing something like RotationRect as an extension of Rect, which will contain additional info about the angle and origin of rotation. Later this RotationRect may be used by calling batch.add_rotated.
As an alternative, it might be a good solution to go "XNA" way by adding both angle and origin to the direct batch.add call.

I'm trying to understand the coordinate system in RGX and think that there is an inverted y-axis somewhere. I've modified the sprite example to only create one instance of the sprite in the batch as follows:

                let rect =
                    Rect::new(0.0, 0.0, sw, sh);
                batch.add(
                    anim.val(),
                    rect,
                    ZDepth::default(),
                    Rgba::new(0.5, 0.5, 0.5, 0.5),
                    1.0,
                    Repeat::default(),
                );
                batch.offset(mx, my);

then the pipeline is set to:

                r.update_pipeline(
                    &pip,
                    kit::ortho(out.width, out.height, Origin::BottomLeft),
                    &mut frame,
                );

However, the sprite then appears in the upper left (and is upside down). Similarly, if I change the origin in kit::ortho to Origin::TopLeft, the the sprite is in the BottomLeft.

This is on metal backend.

This method is clearly broken (try resizing one of the example windows like shapes, then replace pip.resize(..) with pip = r.pipeline(w, h, Blending::default()); and compare).

My guess is that the new ortho matrix needs to be copied into buf, but I may be wrong.

https://github.com/cloudhead/rgx/blob/a3d3a37f638df1a9d44fd4c3a2f90e07538a478b/src/kit/shape2d.rs#L107-L111

Hi there!

Just posting this as an idea here. What about defining a very high-level API in something like Protocol buffers? Considering there will be a server-like wrapper for the RGX itself that will receive serialized commands via a customizable transport layer (TCP, UDP or inter-process) it will allow this library to serve as a simple graphics system for something like Deno or Wasmer. Obviously, such an API should be centered around a concept of batches to reduce the cost of transporting the requests. That, probably, means something like command queues in normal graphics.

Most probably, something like this should be implementable on the side as an external solution using RGX, however, I am interesting in your input on such an idea.

Cheers!

Likely done with glslc but it would be good to document or even have a command/script to regenrate the spirv of the shaders. As an example while working on the shape2d pipeline I used this command for the vertex shader:

glslc -Werror -o src/kit/data/shape.vert.spv  src/kit/data/shape.vert