Running the samples (or anything I build myself) on my MacBook Pro 2015 with 2560x1600 screen resolution, causes all rendering to only cover the lover left quarter of the window, doesn't matter if it's full screen or windowed. Most likely has something to do with DPI settings but I can't seem to impact this with tetra? Have tried to change internal vs external size on window, but nothing seems to change.

Any ideas? SDL2 related I guess, since I do have these issues with "plain" SDL2 projects as well.

Running on osX mojave. Macbook pro retina. Download from GIT and run

cargo run --example hello_world

Compiling tetra v0.2.1 (/Users/pabloweremczuk/Documents/Proyectos/rust/tetra) Finished dev [unoptimized + debuginfo] target(s) in 6.41s Running target/debug/examples/texture OpenGL Device: AMD Radeon R9 M370X OpenGL Engine OpenGL Driver: 2.1 ATI-2.4.9 OpenGL Vendor: ATI Technologies Inc. Swap Interval: VSync Error: OpenGl("ERROR: 0:1: '' : version '130' is not supported\n")

I'm not sure whether I plan on using anything as heavy duty as Specs for now, but it'd be good to have an example in the repository, both for the sake of documentation and to make sure any API changes we make play nicely.

I ported my rl demo from GGEZ to Tetra and it seems to work well, although it's probably a bit more complicated than what we're looking for here.

After installing the -lSDL2 dependency:

apt-get install libsdl2-dev

I can compile and run the examples (on Debian), but they all render black without error messages:

$ uname -a
Linux purism 4.15.0-2-amd64 #1 SMP Debian 4.15.11-1 (2018-03-20) x86_64 GNU/Linux
$ cargo run --example hello_world
    Finished dev [unoptimized + debuginfo] target(s) in 0.05s
     Running `target/debug/examples/hello_world`
OpenGL Device: Mesa DRI Intel(R) Iris 6100 (Broadwell GT3)
OpenGL Driver: 3.0 Mesa 18.1.9
OpenGL Vendor: Intel Open Source Technology Center
Swap Interval: VSync

Summary

My game randomly crashes at the start of the runtime with the error message Segmentation fault: 11 and this error appear when 2 gamepads connected with the computer before running the game using cargo run

• error message after call cargo run

• main function. I printing start main message when it start.

• GameState::new(). It should called from main() with printing message main::new at start of the function.

From the printing message. I assume that the game crash before enteringGameState::new()

Steps to Reproduce

• Connect 2 gamepads
• call cargo run
• using get_gamepad_name(), get_gamepad_axis_position(), is_key_down(), is_gamepad_button_down()
• close the app by pressing Esc
• call cargo run again. The error should appear. If it not appear try it again 2 or 3 times.

Additional Info

OSX Catalina 10.15.7 tetra = "0.6.2" gamepads:

• Logitec Gamepad F310 USB
• 8BitDo arcade stick bluetooth

Summary: There does not seem to be a way to find information about the system. It would be nice to at least be able to find the screen size before creating the context (or, if not possible, create a context without creating a window first).

Why is this needed? Code examples show something like

ContextBuilder::new("Hello, world!", 1280, 720)
    ...

But that size may or may not be suitable for the screen. Being able to find out whether it's a massive 3440x1440 screen or a tiny Raspberry Pi 320x200 screen would be really useful. Ideally, this information should be available before creating a window, to avoid having to create a default sized window (or a full screen context) only to then find out that it's not a good size and change the size when the window is already visible.

Summary: I used a font that is made for pixel perfect text, at size 9. In tetra, it looks very blurry with size 9, but looks fine in size 10. Tried the font in godot engine, where it works fine at size 9, but not 10. The font is "Vector", from Chevy Ray's font pack. I am sure it is reproducible with other (free) fonts as well.

Edit: I tried with another font that should be pixel perfect at size 10, but I could't get it to work at any whole pixel size.

How it looks at size 9:

How it looks at size 10 (expected this at size 9):

Summary: I'm managing my sprites with spritesheets. I slice sprites from sheets with DrawParams::clip(), and draw them on a position with DrawParams::position(). But, when I let the sprites move around, I noticed that they sometimes displays off by 1 pixel.

Steps to reproduce: I wrote a minimal case, and here is the screenshot:

I found this seems to be caused by passing DrawParams::position() some real numbers.

Expected behavior: I expected position() does not affect sprite clipping, but actually it seems do. Is it a intended feature? If so, how can I ensure that the sprites are clipped pixel-perfectly?

Additional info: system info: Debian testing, nvidia-driver 440.100-2

Another one suggested by @xla on Twitter.

This probably wouldn't be too hard to implement out of tree if someone's game required it, but it's such a common requirement that we probably want it built-in.

Here is my mesh creation

        let (pos_i, uv_i) = (Vec2::new(0.0, 0.0), Vec2::new(0.0, 0.0));
        let (pos_j, uv_j) = (Vec2::new(1.25, 1.25), Vec2::new(0.5, 0.5));
        let (pos_k, uv_k) = (Vec2::new(0.0, 2.5), Vec2::new(0.0, 1.0));
        let particle_vertices = &[
            Vertex::new(pos_i, uv_i, Color::WHITE),
            Vertex::new(pos_j, uv_j, Color::WHITE),
            Vertex::new(pos_k, uv_k, Color::WHITE),
        ];
        let particle_mesh = VertexBuffer::with_usage(ctx, particle_vertices, BufferUsage::Static)?.into_mesh();

When I draw it (and try to change the color with DrawParams)

            graphics::draw(
                ctx,
                &self.particle_mesh,
                DrawParams::new()
                    .position(p.position)
                    .origin(Vec2::new(0.0, 2.5))
                    .scale(Vec2::new(p.scale, p.scale))
                    .color(p.color)                //-> p.color is a Color
                    .rotation(p.theta),
            );   
        }

thinking my code had a problem, I performed the same test with the mesh.rs example (removing the texture). Same result, the color does not change

Summary: Minimizing the window jumps up the CPU usage.

Steps to reproduce: Run an empty application and minimize its window.

Additional info: https://github.com/17cupsofcoffee/tetra/blob/62c9a264c8bd35585515e4e43375d5f835f4598f/src/context.rs#L155 Perhaps this problem occurs because std::thread::yield_now() does not wait properly when the application is idle.

This issue is confirmed to occur on Windows and MacOS.

• MacOS Activity Monitor on MacOS shows the percentage of usage of each logical core.

  • 1.7% -> 45% (My application)
  • 2% -> 80% (cargo run --release --example animation)

• Windows

Updates the requirements on lyon_tessellation to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Updates the requirements on half to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Updates the requirements on hashbrown to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Updates the requirements on rodio to permit the latest version.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Summary

I want to implement a non-breaking method for instanced draw calls without the size limit of uniform arrays. For this, I'd like to use instanced arrays as vertex attributes.

The proposed API would look as follows:

let shader = Shader::from_vertex_file(ctx, "path/to/vertex_file")?;
shader.set_instanced_array(ctx, "a_offsets", offsets.as_slice()); // Offsets could be a Vec of any OpenGL attribute type
graphics::set_shader(ctx, &shader);
...
mesh.draw_instanced(ctx, 10_000, Vec2::new(16.0, 16.0));

It is very similar to the current uniform approach. Therefore offsets in this concrete example requires at least 10000 entries.

I am opening an issue for this, as I'd like to inform you about my intentions beforehand and because you may have some feedback or concerns regarding the API design or even overall idea.

Sidenote: As I am very new to OpenGL and barely having much freetime due to school, side job and my diploma thesis, this contribution may well take some time till it is complete.

Motivation/Examples

I'd need this change for a game prototype I am writing. I need to draw the same object 100s of 1000s of times. This leaves quite a performance impact. Instancing would be the ideal solution, but tetra currently only supports instancing using uniform arrays, which have quite a significant size limitation, only allowing some 1000s instances. Using instanced arrays, this limit can practically be (almost) completely removed, allowing even more performance gain due to even less draw calls.

One concrete use case would be very heavy particle effects, where half a million equal particles need to be drawn at the same time. Or for really suffisticated cellular automata simulations, where cellular states are better not to be stored as color in a texture but a more complex object.

Alternatives Considered

Two alternative API designs I've considered are the following:

let shader = Shader::from_vertex_file(ctx, "path/to/vertex_file")?;
graphics::set_shader(ctx, &shader);
...
let mut offset_attribute = Vec::new();
for i in 0..10_000 {
    offset_attribute.push(some_offset); // Push offsets to attribute
}
let mut attributes = Vec::new();
attributes.push((3, offset_attribut)); // Push attribute location and per instance values

graphics::set_instances(ctx, 10_000, attributes); // All draw calls inside will be instanced 10_000 times using the given attributes
mesh.draw(ctx, Vec2::new(16.0, 16.0)); // Will be drawn 10000 times
graphics::reset_instances(ctx); // All subsequent draw calls will be handled normally

But I think this is too long and stateful.

let shader = Shader::from_vertex_file(ctx, "path/to/vertex_file")?;
graphics::set_shader(ctx, &shader);
...
let mut offset_attribute = Vec::new();
for i in 0..10_000 {
    offset_attribute.push(some_offset); // Push offsets to attribute
}
let mut attributes = Vec::new();
attributes.push((3, offset_attribut)); // Push attribute location and per instance values

mesh.draw_instanced_array(ctx, 10_000, Vec2::new(16.0, 16.0), attributes); // Draws the mesh 10000 times using the given attributes

This is concise and effective, but in my humble opinion the originally proposed design better integrates into the current "workflow" for instancing.

Summary

Hi, I am writing this for anyone with the same issue and looking for a solution to solve/avoid it.

Summary:

Buld the app with sdl2 = { version = "0.35.2", features = ["bundled", "static-link"] } on OSX Catalina will throw build error.

I think It is related to this issue https://github.com/Rust-SDL2/rust-sdl2/issues/1203

I work around it by changing the version to sdl2 = { version = "0.35.1", features = ["bundled", "static-link"] } sdl2-sys = "=0.35.1"

Steps to Reproduce

Build app on OSX (Catalina) with sdl2 = { version = "0.35.2", features = ["bundled", "static-link"] }

Additional Info

No response