This is probably outside of the scope of the game engine, but is it possible to use the current target or frame as an image type from the Image crate? My goal is essentially to save the frame as an image file. Thanks

When rendering over 1k PolyLines on a single mesh, as the number of lines increased, I saw other lines disappear and a gradient streak appear, stretching from the top-left corner towards the middle where some line was rendered. See the below image:

Given that my code works for a lower number of lines perfectly, I tried to allocate more than 1 mesh for drawing all the lines. Distributing the total number of lines among several meshes seems to have fixed the bug. I assume that this bug relates to some max bound for how many shapes a mesh can hold, but have not been able to find evidence of that in the documentation. If this bound does exist, it should be documented.

I've made some changes to essentially inject GilRs gamepad events as input events and added GilRs as a dependency.

Currently, there's no way to poll the gamepad directly as everything is event-based. This was a blocker for me to add a nice example but the basics are there and should suffice for handling simple events and button presses.

A catch I encountered is that if an axis event occurs there won't be the following event to "zero" that same axis out, so caching the state of an axis won't work.

This PR, or future PR's could expose more of the GilRs API such as querying the power state and allowing the use of the force-feedback module.

Edit: Currently, these changes expose two GilRs types (GamepadId and EventType) which may not be preferable.

It'd be good if we could get access to set_cursor_visible and set_cursor_icon of winit::Window. This should be fairly simple to do once #62 is merged in.

@hecrj I'd be happy to work on this if you are OK with this addition. I was thinking we could just add these two methods in graphics::Window, which would just call the winit::Window methods. For the CursorIcon enum, I am guessing we'd want to have an enum in coffee that maps one to one with the winit::window::CursorIcon since it doesn't look like winit is exposed to the consumers of this crate at all. If you have other ideas, I am happy to follow them as well, just let me know if you're interested.

For context, the reason I am interested in these methods is to be able to show a different icon in specific cases. Although set_cursor_icon would be enough to show the standard cursor icons, I believe set_cursor_visible is necessary to completely hide it to show a custom icon. I don't know which one I'll go with yet, but I think someone else might also find use for one or the other. Furthermore, a lot of games do hide the mouse icon completely, so the visibility control would be necessary for that as well.

Watch in higher quality / Code

This PR implements a basic UI runtime and integrates it with Coffee.

Features / Goals

• Responsive UI layout based on flexbox, built on top of stretch.
• Generic Widget trait with a Renderer associated type, allowing users to build their own custom widgets and UI renderers.
• Type-safety. No weak references.
• Simple design, heavily inspired by Elm and elm-ui. Users define a function describing their UI layout. The resulting UI produces messages on user interaction. Produced messages are processed by another user-defined function, changing state as desired.
• Simple integration. GUI can easily be added by simply extending your Game with the UserInterface trait.

Built-in widgets

• [x] Column
• [x] Row
• [x] Text
• [x] Button
• [x] Checkbox
• [x] Radio button
• [x] Slider
• [x] ~Progress bar~ #45

Example

This branch includes an example that showcases all the built-in widgets so far (code). If you want to check it out simply run:

cargo run --example ui --features opengl,debug --release

Limitations

This is a first iteration. The current implementation is still missing some basic features like:

• Text input widget. This is a pretty complex widget if we want to do it well. We may need to contribute to glyph_brush a bit more. #46
• Clipping (no scrollables yet). I have a mental roadmap for this. It involves changing Target and the rendering pipelines a bit. I need to further investigate, but it should be doable. #47
• Global scaling. I have some ideas for this too (somewhat related to #6), but I think we should probably focus on other stuff first.

Also, there is no way to overlay elements as of now and there are probably many performance optimizations that we could make. However, I would like to wait a bit and gather use cases before implementing these.

Breaking changes

This PR contains breaking changes that affect the architecture of the engine for the better:

• The View associated type has been removed. Thus, implementors of the Game trait are also meant to hold the game assets. This simplifies the API considerably, and it helps model your game state-view relationship with precision, avoiding inconsistencies.
• The Game::Input associated type now has to implement the new Input trait. This splits code quite nicely, as the on_input method moves away from Game. It also makes Input implementors reusable. For instance, a KeyboardAndMouse type has been implemented that can be used out of the box!
• The Game::LoadingScreen associated type has been introduced. Given that all the Game associated types implement a trait with a load method, wiring a loading screen now is as simple as writing its name. Because of this, the Game::new method is no longer necessary and it is dropped.

Additional implemented features

• Text alignment, using HorizontalAlignment and VerticalAlignment
• Font::measure, which allows to measure any Text
• Rectangle::contains, returns whether or not it contains the given Point
• Sprite::scale
• Default implementation for Sprite

Pending work

• [x] Rename UserInterface::Event to UserInterface::Message
• [x] Move runtime concepts and customization into a (public) module inside ui
• [x] Expose simple concepts using the basic renderer directly on the ui module
• [x] ~Implement ProgressBar~ widget #45
• [x] ~Debug some weird stretch behavior (maybe contact maintainers and/or open an issue)~ #44
• [x] ~Debug glyph_brush measuring functions (they seem to be off)~ #43
• [x] Rethink alignment API
• [x] Support renderer configuration
• [x] Control event propagation
• [x] Remove debug code (maybe split it into another renderer)
• [x] Update examples
• [x] Review API consistency
• [x] Give proper credits (Kenney and stretch)
• [x] Update documentation
• [x] Update README
• [x] Update CHANGELOG

Motivation

I needed a way to project camera coordinates to world coordinates to be able to "pick" tiles using the mouse in a tile based game with a moving camera; In order to do so I needed to project the screen space coordinates into the world using the current Transformation.

Solution

Add the following methods to coffee::graphics::Transformation.

pub fn project(&self, point: Point) -> Point;

pub fn unproject(&self, point: Point) -> Point;

Further Work / Possible Improvements

• [x] ~~Get the inverse matrix in an infallible way?~~

let inverse_mat = self.0.try_inverse().unwrap();

@hecrj I got stuck on some implementation details & decisions to make for #111, so I thought I'd open a draft PR to make it easier to discuss. The main problem revolves around the following:

When we control the cursor icon through the game trait by updating it every frame, we prevent the system taking over the icon. As an example, if I set the icon to Default and then try to Move the window in Windows 10, the Move icon goes away immediately. That might be what some clients want, but I don't think we should force them into specifying an icon at all times unless they want to.

There are several ways to get around the issue, most of which I think will require us keeping state of the cursor, because as far as I can tell, there is no way to get the current cursor icon from winit.

1. In Game instead of fn cursor_icon(&self) -> CursorIcon we could have fn cursor_icon(&self, current_icon: CursorIcon) -> CursorIcon which would let the client decide when and how to update the cursor. It'd provide the knowledge of the current cursor_icon which might come in handy in some cases, although I am not sure if it'd be anything common.
2. We could have an Unchanged variant or something similar in the CursorIcon enum and don't update the icon in this case. I am afraid that this might be a bit more confusing then the first option, but it's hard to say.
3. In Game instead of fn cursor_icon(&self) -> CursorIcon we could have fn cursor_icon(&self) -> Option<CursorIcon>. None could mean that don't set the cursor_icon manually. It'd result in the last cursor icon to remain as is, but would also let the system take over. Without checking the docs, it might be interpreted as Hidden which would be bad.

I don't even know how this all connects to UserInterface and how the cursor is updated from there. I might be thinking too much over this and just a simple implementation might be fine too, I am not sure. Either way, I'd really appreciate your input on what you think is the best course of action.

Notes about the other parts of this WIP PR:

• I don't know if we want to add all the cursor icons from winit or not. I was thinking I'd add only a few of them just to get the implementation out and then separately the different variants could be decided. I am totally fine with implementing the variants you might already have in mind.
• Setting cursor icon and visibility separately makes me a little sad 😬
• CursorIcon::Hidden being mapped to the Default icon makes me even sadder. If we don't end up keeping track of the state, I think it might be best to use TryFrom trait or have a custom function that returns Option<CursorIcon> and don't update the cursor if an icon variant doesn't make sense. I also played with having an enum like below, but I am not sure if added complexity is worth it.

pub enum CursorIconState {
    Visible(CursorIcon),
    Unchanged,
    Hidden
}

• I am leaving the documentation until after the implementation is done to avoid duplicating effort.

@hecrj Sorry for the long PR description. I'd appreciate any feedback you might have. (for the code or the questions) Feel free to ignore the notes for now if you want to focus on the main issue.

Right now, Coffee only exposes three input events (keyboard input, mouse input, and mouse movement).

We should probably expose additional useful events like CursorLeft, CursorEntered, MouseWheel, etc.

I have a small example that moves a circle across the screen based on WASD input.

From experimenting on macOS, it appears that Coffee respects macOS's key repeat preferences:

On the one hand, this is obviously a nice thing to have, as it gives the player control over the behaviour. On the other hand, this is unexpected behaviour for games.

Specifically, even with my preferences set to fast/short, there is still a noticeable delay from the "Delay Until Repeat" option. This means that if I press and hold A to move the circle to the left, it will move to the left once on press down, it will then stop moving for a moment even though A is still held down, and then start moving again as soon as the "repeat" kicks in, until I release the A key.

I've experimented with ggez as well, and that game engine behaves as "expected" on macOS (quotations here because the game behaviour differs from default operating system behaviour, but I believe ggez' behaviour is what people expect in a game).

Given that both engines use winit as a dependency, but ggez is still using 0.19 and Coffee uses 0.22, I suspect it's actually a change in behaviour between winit versions, and I would also suspect that change in behaviour is considered to be a fix, since regular macOS windows are expected to behave this way, but I don't think this is expected for games.

Alternatively, Coffee shouldn't treat key input as "text input". There's some investigation for Piston I found here: https://github.com/PistonDevelopers/piston/issues/1220#issuecomment-569185277.

Another reference is to a long-standing issue for Winit to discuss a better input model, see: https://github.com/rust-windowing/winit/issues/753

And finally, looking at ggez, it appears that they've implemented this behavior themselves by tracking is_key_repeated.

Although I'm not quite sure (yet) how that works, as that still doesn't explain why ggez doesn't have a delay between the first key and the repeat, whereas Coffee does.

Hello, I'm trying to use coffee for learning purposes but I'm unfortunately not able to run the example provided by the documentation. The compiler complains with the following error:

Error: WindowCreation("Couldn\'t find any pixel format that matches the criteria.")
error: process didn't exit successfully:
`C:\Users\_\Desktop\Programming\Rust_Projects\target\debug\coffe_sketch.exe` (exit code: 1)      

This is how my Cargo.toml file looks like:

[package]
name = "coffe_sketch"
version = "0.1.0"
authors = ["_"]
edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
coffee = { version = "0.4", features = ["opengl"] }

Further details:

OS: Windows 10 x64
rustc 1.43.0-nightly (58b834344 2020-02-05)  

How can I solve this issue? Any help and guidance would be truly appreciated. Thanks in advance.

Is there a way to set padding around a widget like ui::Image or ui::Text? I see that examples/image.rs, Text::height is used to set the height in pixels (and, since this was in a column, this results in some padding if the height is larger than the computed height of the text). In the same example, Column::spacing is used to set a constant amount of spacing between the itens of the column (but not before the first and after the last).

Both aren't what I'm looking for; there's also ui::core::Style::padding but I'm unsure how to use this with the current widgets (is it necessary to add a padding method to the widgets, like they have a height method? Shouldn't those methods be added to a trait?).

(ps: since the ui code is being moved to iced perhaps this issue belongs there, but coffee doesn't used iced yet)

Add support for some kind of anti-aliasing to meshes.

Some methods would be:

• MSAA which would bring about the problem of wgpu only supported 4xMSAA or none.
• SSAA expensive but would work irrelevant of backend but requires a whole new render pass to achieve.
• FXAA same as SSAA in that it would require a new render pass however is much more lightweight but can produce less than stellar results at times.
• Custom shader for meshes that smooths the edges, this could be done in the fragment shader not requiring an additional pass but will need a new pipeline if it gets used at the same time as any non-anti-aliased things.

Updated rand version to avoid vulnerability discovered here among others Updated image version to correct vulnerability found here Updated nalgebra to remove this vulnerability Updated glutin to avoid several dependent vulnerabilities

We currently have a project in ggez, but want our system to run headless with a cloud based GPU machine.

ggez does not allow us to run without creating a window, even though we can render to an off-screen canvas. The window is basically blank, but displayed.

Can coffee do what we desire?

Our application does real time video encoding with effects and when deployed, does not require a window, which would require x11 contexts vs just the GPU drivers.

The idea of leveraging wgpu backends vs only opengl is also enticing.

Ideally we'd code our system to utilize a window for feedback when debugging (we'd copy the off screen canvas to the window), but when deployed we'd disable it entirely.

We did not see an example in coffee that would demonstrate a simple headless setup, ie, just draw to a canvas and save out the canvas as an image file as a simple demonstration.

Any insights would be appreciated. We think the port to coffee would be pretty easy if it supports this capability.

Hello!

I'm struggling to get the examples running, I'm using Fedora 31, Coffee 0.4.1. The first frame is rendered, the draw function seems to be called once, and the window has no title or receives events. This locks up and I have to force close it.

I want to try and fix the problem myself, sadly I don't know where to start... Any suggestions would be greatly appreciated!

Hello,

One of my player have a graphic rendering problem:

I'm not sure about which operating system he use but it is probably Windows. What kind of error it can be ?