I have been able to run my own programs using piston for a while, but since a few days I suddenly get this error.

When trying to run cargo run --bin hello_world from the piston_examples:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "Couldn\'t find any pixel format that matches the criterias."', /checkout/src/libcore/result.rs:860:4
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
             at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::_print
             at /checkout/src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at /checkout/src/libstd/sys_common/backtrace.rs:60
             at /checkout/src/libstd/panicking.rs:380
   3: std::panicking::default_hook
             at /checkout/src/libstd/panicking.rs:396
   4: std::panicking::rust_panic_with_hook
             at /checkout/src/libstd/panicking.rs:611
   5: std::panicking::begin_panic_new
             at /checkout/src/libstd/panicking.rs:553
   6: std::panicking::begin_panic_fmt
             at /checkout/src/libstd/panicking.rs:521
   7: rust_begin_unwind
             at /checkout/src/libstd/panicking.rs:497
   8: core::panicking::panic_fmt
             at /checkout/src/libcore/panicking.rs:92
   9: core::result::unwrap_failed
             at /checkout/src/libcore/macros.rs:41
  10: <core::result::Result<T, E>>::unwrap
             at /checkout/src/libcore/result.rs:738
  11: hello_world::main
             at src/hello_world.rs:7
  12: __rust_maybe_catch_panic
             at /checkout/src/libpanic_unwind/lib.rs:98
  13: std::rt::lang_start
             at /checkout/src/libstd/panicking.rs:458
             at /checkout/src/libstd/panic.rs:361
             at /checkout/src/libstd/rt.rs:59
  14: main
  15: __libc_start_main
  16: _start

System

Antergos, based on Arch Linux $ uname -r: 4.12.12-1-ARCH $ cargo --version: cargo 0.21.0 (5b4b8b2ae 2017-08-12) $ rustc --version: rustc 1.20.0 (f3d6973f4 2017-08-27) $ rustup --version: rustup 1.6.0

glxinfo recently updated packages, most notably:

• upgraded mesa (17.1.8-1 -> 17.1.8-2)
• upgraded gtk3 (3.22.19-2 -> 3.22.20-1)
• upgraded linux (4.12.10-1 -> 4.12.12-1)

Update 4: All intermediate versions of mesa (17.1.8-1, 17.1.8-2, 17.2.0-2, 17.2.0-3, 17.2.1-3, 17.2.2-1) have this same problem.

Let me know if you need more information 😄

Update: Seems to be the case for all OpenGL versions. Rebooting didn't work either. Update 2: Also happens on a clean Debian 9 (kernel 4.9.0-3-amd64) build in VirtualBox 5.1.26 Update 3: Also happens on Rust 1.19.0, and Rust 1.18.0 and earlier don't compile

One problem is after redesigning the iterator to take advantage of the stack environment, they will no longer be isomorphic. You can't take a game written with the Game trait and translate it to using iterators by just copying and pasting code.

Trying to the run the example in the README.md with the red square, I compile successfully ( I ran cargo build twice just in case, the first one was successful, the 2nd one was a failure to build glutin because the system couldnt not find a file) but encounter a panic "Couldn't find any pixel format that matches the criterias.". I'm probably missing a dependency, just not sure what.

Some of you might have read the issue #670 about collaborating on a new open source game. I have been in touch with @bvssvni to let him know about my current plan to develop a game.

My motivation to create such a game is to expose as many people as possible to the "open source" way of doing things . Not only to developers who already understand the benefits but also for people of other trade such as designers, musicians, voice actors, movie directors, … I believe a game is the ideal medium to converge all our the efforts to create something meaningful, something we can be proud of.

Hopefully this project can help generate momentum for the Piston framework and promote the creation of a new set of libraries that in turn could be used in other projects. It can be a testing ground for new features and test the limits of their implementation.

Now let's talk about the game. It is currently called project R where the "R" stands for Renaissance. It is a reference to the cultural movement following the "dark ages". Project R doesn't take place during that historical period but I hope we can achieve a renaissance 2.0 of our own.

The goal of this project is to create a highly customizable multiplayer game.

The main game: As a new player, you are asked to select a zone where you would like to start the adventure from. Every zone is culturally and architecturally different but it is possible as you evolve to travel to remote regions. You also receive some piece of land where you can build your home but Since you just started the adventure you don't have any gold to buy raw material and make your home. You are now required to go to the mountain area and collect some raw material. Because you have selected a specific zone, the bricks, tiles, and other structural element will look similar to the existing buildings.

Now that you have built your home, you can still go to the mountain area to collect raw material but this time to sell it to the local construction store. The resell price is subject to supply and demand. This is one of the many ways you can earn extra gold.

Gold can buy food and useful items that can be stored in your home for later use. Without food your character can't survive long enough to explore this world and join new games.

Some items are free some other require gold. These items will be crafted by the community so they can set their own price or requirements. This is where the community can get creative.

You can customize your character look and personality. You can buy clothing and accessories to express yourself. Not all customization are available for purchase. For example, your daily food intake and energy expenditure will define your stamina and overall shape.

That's nice and all but it's pretty boring to collect items for no other reason than storing them. This is where you get to join a game .

Secondary game: The first game will be a 2D plan fighting game where characters are rendered in 3D but the "hitbox/hurtbox" collision is calculated on 2D objects. A fighter is a good first game because it doesn't require the creation of complex puzzle or intricate story. With a minimal set of tools it is possible to play for hours. You have to understand your options and their consequences , make decisions in real time and also try to guess what your opponent is thinking by observing his/her movements and habits. Also for those who have heard about the project mugen, you can see what is possible when the community is given control over content creation.

You can join the fighting game by enrolling in a school or dojo . Every zone has a specific fighting style and mastery of one or more of the elements that make up the game universe. You learn from your master the basics of your fighting style and train with players that are about the same level as you. You don't get to use the power of the elements just yet but you can already start leveling up your basic attacks and can also compete for the rookie title.

Every week a competition is taking place and you have to fight a member of a competing style. You know in advance who you will be fighting so you can prepare and level up accordingly. All the fights are recorded and can be watched live by players who decided not to join the competitive mode or are just waiting for their fight to start. The next day is the main event where masters fight each other. The "master tournament" outcome will influence the game story and this is where we get to watch the next "episode"...

That's pretty much the idea behind this project I have skipped some of the features/ideas but I think for now it should be enough to get the conversation started. I hope some of you are still interested and if so I will be answering questions on this thread.

thanks for reading

Executing "image" produces a blank window.

Linux 3.14.5-1-ARCH #1 SMP PREEMPT Sun Jun 1 07:38:50 CEST 2014 i686 GNU/Linux Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) OpenGL version string: 2.1 Mesa 10.1.4

How do we go from (c++, from http://gameprogrammingpatterns.com/game-loop.html)

double previous = getCurrentTime();
double lag = 0.0;
while (true)
{
  double current = getCurrentTime();
  double elapsed = current - previous;
  previous = current;
  lag += elapsed;

  processInput();

  while (lag >= MS_PER_UPDATE)
  {
    update();
    lag -= MS_PER_UPDATE;
  }

  render();
}

to using piston in our editor?

From the comment http://www.reddit.com/r/rust_gamedev/comments/2jiep0/the_new_look_of_wwwpistonrs/clcpyc9

The way you describe Piston sounds like it has more in common with game frameworks than game engines; if that's the case some rebranding might be in order to prevent future confusion.

I'm attempting to compile my project via cargo build, but compilation freezes when compiling piston. Eventually it exits out with the following error:

vagrant@vagrant-ubuntu-trusty-32:/vagrant$ cargo build
       Fresh image v0.0.0 (https://github.com/PistonDevelopers/rust-image)
       Fresh codegen v0.0.1 (https://github.com/AngryLawyer/rust-sdl2)
       Fresh graphics v0.0.0 (https://github.com/PistonDevelopers/rust-graphics)
   Compiling piston v0.0.0 (https://github.com/PistonDevelopers/piston)
       Fresh gl v0.0.1 (https://github.com/bjz/gl-rs)
       Fresh sdl2 v0.0.1 (https://github.com/AngryLawyer/rust-sdl2)
       Fresh opengl_graphics v0.0.0 (https://github.com/PistonDevelopers/opengl_graphics)
Could not execute process `rustc src/lib.rs --crate-type lib --out-dir /vagrant/piston/target -L /vagrant/piston/target -L /vagrant/piston/target/deps` (status=9)

Attempting to clone and build piston individually with cargo build results in the following error:

vagrant@vagrant-ubuntu-trusty-32:/vagrant/piston$ cargo build
   Compiling piston v0.0.0 (file:/vagrant/piston)
Could not execute process `rustc src/lib.rs --crate-type lib --out-dir /vagrant/piston/target -L /vagrant/piston/target -L /vagrant/piston/target/deps` (status=9)

Attempting to build piston with the above command results in compilation freezing and no progress being made (it doesn't error or crash, just waits for the command to exit):

vagrant@vagrant-ubuntu-trusty-32:/vagrant/piston$ rustc src/lib.rs --crate-type lib --out-dir /vagrant/piston/target -L /vagrant/piston/target -L /vagrant/piston/target/deps

Any ideas?

rustc -v: rustc 0.11.0-pre
uname -a: Linux vagrant-ubuntu-trusty-32 3.13.0-29-generic #53-Ubuntu SMP Wed Jun 4 21:02:19 UTC 2014 i686 i686 i686 GNU/Linux

AFAICT, we don't currently provide events for when the mouse enters/leaves the window (a separate event from focus gained/lost), which would help situations like https://github.com/PistonDevelopers/drag_controller/issues/20.

Obviously, since this would be a pretty widespread breaking change, it'd be a good idea to bikeshed the design first. Perhaps add one or two new variants to input::Motion, since it concerns movement of the mouse cursor:

pub enum Motion {
    // Existing variants omitted for brevity.
    /// The mouse has entered the window area.
    MouseEnter,
    /// The mouse has left the window area.
    MouseLeave,
}

Or, it could be added as a single variant to input::Input, in parallel with Focus. I'm having difficulty coming up with a short variant name that clearly describes a mouse enter/leave event as a boolean. This was the best I could do:

pub enum Input {
    // Other variants omitted
    /// Window gained or lost focus.
    Focus(bool),
    /// Mouse cursor entered or left the window area.
    Cursor(bool),
}

Gfx got some abstractions now that require integration between window and graphics. We could add a library gfx_window to glue this to wrapped piston window abstractions, or we could start a piston_window that uses Glutin directly.

The argument is as following: If you want to use Gfx, which you need to use many 3D Piston libraries, then why would you want to use SDL2 or GLFW when Piston does the event abstraction, and Glutin provides a cross platform interface?

The idea is to execute render, update and input logic on a second/multiple threads while using the main thread to poll events and synchronize with the GPU.

Major motivation is to create more room for library design that depend on a set of conventions, where the accessibility to certain resources are taken as granted. For example 1) window 2) device 3) sound.

At the moment we struggle with the borrow checker because it forces us to pass around objects representing these resources, and all structures need to mutate their internal state to keep them around. It makes it impossible to use closures safely that specify a subroutine of some significant game logic, because the closure captures the objects that represent the resources. This prevents other parts from using those resources, even if they don't use them at the same time.

One issue is that on some platforms, both rendering and event loop needs to happen on the main thread. This puts an upper limit of the accuracy of user input. If we use a second thread for updates and render logic, then the main thread will get better accuracy and can time stamp the events.

Creating textures on demand without access to the device is simply not possible with Gfx's design. We could have channels for creation of different textures, such as glyph caching for Conrod. This could be implemented on library level such that whenever you depend on glyph caching, it is assumed that a channel is set up for that resource.

The new asset_store makes it possible to load assets asynchronously, so this kind of thinking is not that far away from what we are currently doing. It might be that with the current design, we try to do too much on the same thread and is punished by the borrow checker for it.

We might get rid of some of the boilerplate code, and some people here got ideas about "setups" that combine certain library. Perhaps it is time to brainstorm how we can improve the overall ergonomics and try to come up with some conventions that are efficient but easy to scale.

Hello,

I noticed today when I disconnected my development laptop from power, game updates in my, very simple, Tetris clone slow down noticeably.

To confirm the issue is not with my game code, I tested this on the piston getting started tutorial code and see the same slowdown occurs there. Attached a GIF of what I am seeing. You can clearly see the slowdown when the laptop is disconnected from power, and then speeds up when reconnected shortly after.

This seems like it shouldn't be normal behavior, right?

hello. is it possible to make audiogames in piston? is there a guide to create an audio game in piston? an audiogame is a computer game for the blind that uses only audio to present the gameplay. also we use keyboard only to play games. for example in archery game, you hear a target sound that moves right and left in the stereo sound field. and when it reaches center, you press space to shoot. or in the car racing game, you here the other cars in the stereo field and try to avoid them by turning away. so i am thinking to make audio games in rust. what do I need: create an empty window and catch key presses, play 3d or 2d sound, interact with a screenreader, (tell my active screenreading software to speak a message in a game), (i have a rust lib for that but it's quite old). or speak out the necessary game message using tts or a sound file.

Hi,

I'm just getting started with Rust and Piston, but it seems like I already run into an issue. I figured out that I can poll events to get button or press/release events to check which Key was pressed, and I noticed that a modifier key enum is already available too, but I don't seem to be able to actually access that in any way via the button- press/release events. Is there full support for the modifier keys in piston already and if yes, how can I access them?

Thanks!

The documentation says

draw_state draw state, draw_state::Default::default() can be used as a default,

It should be draw_state::DrawState::default() https://docs.piston.rs/piston_window/graphics/rectangle/struct.Rectangle.html#method.draw

Looking around our repos, there are lots of long-living repos some of which are written in 2015 edition style. I think we can improve them by adapting to the newer edition. Is there an edition or MSRV policy we must conform to?