GithubHelp home page GithubHelp logo

ggez / ggez Goto Github PK

View Code? Open in Web Editor NEW
4.1K 54.0 418.0 5.59 MB

Rust library to create a Good Game Easily

Home Page: http://ggez.rs

License: MIT License

Rust 96.89% WGSL 3.11%
game rust engine game-engine game-development gameengine crates game-frameworks

ggez's Introduction

ggez

ggez logo

What is this?

Build status Docs Status license Crates.io Crates.io Discord chat

ggez is a Rust library to create a Good Game Easily.

The current version is 0.9.3.

More specifically, ggez is a lightweight cross-platform game framework for making 2D games with minimum friction. It aims to implement an API based on (a Rustified version of) the LÖVE game framework. This means it contains basic and portable 2D drawing, sound, resource loading and event handling, but finer details and performance characteristics may be different than LÖVE.

ggez is not meant to be everything to everyone, but rather a good base upon which to build. Thus it takes a fairly batteries-included approach without needing a million additions and plugins for everything imaginable, but also does not dictate higher-level functionality such as physics engine or entity component system. Instead the goal is to allow you to use whichever libraries you want to provide these functions, or build your own libraries atop ggez.

Features

  • Filesystem abstraction that lets you load resources from folders or zip files
  • Hardware-accelerated 2D rendering built on the wgpu graphics API
  • Loading and playing .ogg, .wav and .flac files via the rodio crate
  • TTF font rendering with glyph_brush.
  • Interface for handling keyboard and mouse events easily through callbacks
  • Config file for defining engine and game settings
  • Easy timing and FPS measurement functions.
  • Math library integration with mint.
  • Some more advanced graphics options: shaders, instanced draws and render targets

Non-Features (i.e. things to add from elsewhere if needed)

Supported platforms

  • Fully supported: Windows, Linux, MacOS
  • Not officially supported but might work anyway: Android, iOS, Web

For details, see docs/BuildingForEveryPlatform.md

If you want to run ggez (up to 0.7 as of now) on Android, iOS or the web using WebAssembly right now, take a look at good-web-game.

Who's using ggez?

Check out the projects list!

Usage

ggez requires rustc >= 1.42 and is distributed on crates.io. To include it in your project, just add the dependency line to your Cargo.toml file:

ggez = "0.9.3"

ggez consists of three main parts: A Context object which contains all the state required to interface with the computer's hardware, an EventHandler trait that the user implements to register callbacks for events, and various sub-modules such as graphics and audio that provide the functionality to actually get stuff done. The general pattern is to create a struct holding your game's data which implements the EventHandler trait. Create a new Context object with default objects from a ContextBuilder or Conf object, and then call event::run() with the Context and an instance of your EventHandler to run your game's main loop.

See the API docs for full documentation, or the examples directory for a number of commented examples of varying complexity. Most examples show off a single feature of ggez, while astroblasto and snake are small but complete games.

Getting started

For a quick tutorial on ggez, see the Hello ggez guide in the docs/ directory.

Examples

See the examples/ directory in the source. Most examples show off a single feature of ggez, while astroblasto is a small but complete Asteroids-like game.

To run the examples, just check out the source and execute cargo run --example in the root directory:

git clone https://github.com/ggez/ggez.git
cd ggez
cargo run --example 05_astroblasto

If this doesn't work, see the FAQ for solutions to common problems.

Basic Project Template

use ggez::{Context, ContextBuilder, GameResult};
use ggez::graphics::{self, Color};
use ggez::event::{self, EventHandler};

fn main() {
    // Make a Context.
    let (mut ctx, event_loop) = ContextBuilder::new("my_game", "Cool Game Author")
        .build()
        .expect("aieee, could not create ggez context!");

    // Create an instance of your event handler.
    // Usually, you should provide it with the Context object to
    // use when setting your game up.
    let my_game = MyGame::new(&mut ctx);

    // Run!
    event::run(ctx, event_loop, my_game);
}

struct MyGame {
    // Your state here...
}

impl MyGame {
    pub fn new(_ctx: &mut Context) -> MyGame {
        // Load/create resources such as images here.
        MyGame {
            // ...
        }
    }
}

impl EventHandler for MyGame {
    fn update(&mut self, _ctx: &mut Context) -> GameResult {
        // Update code here...
        Ok(())
    }

    fn draw(&mut self, ctx: &mut Context) -> GameResult {
        let mut canvas = graphics::Canvas::from_frame(ctx, Color::WHITE);
        // Draw code here...
        canvas.finish(ctx)
    }
}

Implementation details

ggez is built upon winit for windowing and events, rodio for sound, and a 2D drawing engine implemented with wgpu. It is entirely thread-safe (though platform constraints mean the event-handling loop and drawing must be done in the main thread), and portable to Windows and Linux.

ggez is pure Rust™.

Help!

Sources of information:

  • The FAQ has answers to common questions and problems.
  • The API docs, a lot of design stuff is explained there.
  • Check out the examples.

If you still have problems or questions, feel free to ask! Easiest ways are:

License: MIT

ggez's People

Contributors

a1phyr avatar aleokdev avatar alexd2580 avatar andy-python-programmer avatar bazhenovc avatar beatgammit avatar chamons avatar dchiquito avatar denialadams avatar elinvynia avatar eosis avatar fu5ha avatar icefoxen avatar jazzfool avatar manghi avatar masche842 avatar matchachoco010 avatar mbillingr avatar mcluck90 avatar nlordell avatar nobbele avatar nvzqz avatar ozkriff avatar psteinhaus avatar ratysz avatar ssciarini avatar svenstaro avatar trvefenris avatar vickenty avatar vixeliz avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ggez's Issues

Streaming data from zip files is a PITA

BECAUSE, it's not multithread-able terribly well, and hides sneaky mutable state via the file handle's current read position, which makes it hard to share between multiple things. You have to open the file multiple times, at which point one might start worrying about buffering, and it's also quite inconvenient to create a new Read for each file you open in a zip, though it is possible. OR, you have to somehow share one file file handle among multiple separate readers (though an RWLock seems the right thing here). So until I can figure out a halfway sane API for this, when we open a zip file we will just read its whole contents into memory and hang on to it there.

See zip-rs/zip#14

Missing word on homepage

It says

ggez is built on the latest stable Rust compiler and distributed on .

Is it meant to say

ggez is built on the latest stable Rust compiler and distributed on crates.io.

scaling problem for non-square res images

Given a 1024x768 image, I would expect a program with window dimensions matching the image, which renders the image at Point::new(512., 384.) , to look roughly identical to the source.

Here's what I put in:
Source image

Here's what came out:
Rendered result

When I encountered this, my quick fix was to add a blank 128px to the top and bottom of the image to make it 1024x1024 (which resulted in no scaling).

I wrote this as an example, but wasn't sure if you'd want that as a PR or what since it's just for debugging the issue, so here's the source as a code block instead:

extern crate ggez;

use std::time::Duration;
use ggez::conf;
use ggez::event;
use ggez::{GameResult, Context};
use ggez::graphics;
use ggez::timer;

struct MainState {
    image: graphics::Image,
}

impl MainState {
    fn new(ctx: &mut Context) -> GameResult<MainState> {
        ctx.print_resource_stats();
        let image = graphics::Image::new(ctx, "checkers.jpg").unwrap();
        let s = MainState { image: image };
        Ok(s)
    }
}

impl event::EventHandler for MainState {
    fn update(&mut self, _ctx: &mut Context, _dt: Duration) -> GameResult<()> { Ok(()) }
    fn draw(&mut self, ctx: &mut Context) -> GameResult<()> {
        graphics::clear(ctx);
        let dest_point = graphics::Point::new(512., 384.);
        graphics::draw(ctx, &mut self.image, dest_point, 0.0)?;
        graphics::present(ctx);
        timer::sleep_until_next_frame(ctx, 60);
        Ok(())
    }
}

pub fn main() {
    let mut c = conf::Conf::new();
    c.window_width = 1024;
    c.window_height = 768;
    let ctx = &mut Context::load_from_conf("ratio-test", "ggez", c).unwrap();
    let state = &mut MainState::new(ctx).unwrap();
    if let Err(e) = event::run(ctx, state) {
        println!("Error encountered: {}", e);
    } else {
        println!("Game exited cleanly.");
    }
}

The GameState model is a bit squirrelly.

The original setup uses a trait to defines callbacks matching Love2D's main callbacks: load, update and draw. Then you just create a new Game object that is parametric on the type you define that trait for, which creates the object using the load callback and then runs it all. The goal was to make it match up with Love2D's model as closely as possible.

This... works, but is really quite painful to do anything fancy with. The problem is really the load callback. In Love2D everything is dynamic, so you can piece together whatever you need in that callback and it works just fine. In Rust everything is static, and so it is much harder to, say, build a scene graph or manage transitions between scenes in this. You can do it, and it works, but it needs adding a lot of machinery and management to even do something as simple as a title screen, with layers of indirection for input events and so on. Magic Happens with regards to creating the ggez Context and bundling it together with your GameState type, so it basically becomes impossible to disentangle any part of the initialization apart from the whole.

I experimented with splitting things apart a little, so that you just have an EventHandler trait that handles update, draw, and event callbacks, and then separating load() out into its own thing. It means an extra three lines of setup code when you create the game objects, but the process becomes much less twisty: you just create a Conf, create a Context, create whatever your EventHandler type is with all your game data, then pass them all to a Game to run your main loop.

Decoupling the Context from the Game creation also has some extra benefits, since a) you can write your own mainloop type stuff if you really want to, which appeals to some people, and b) it makes it trivial (with some minor API changes so the Game returns the Context when it is done) to create one Context and thread it through several Game objects to do simple scene transitions. Or, presumably, do the same for more sophisticated scene management.

Make filesystem code more clever

Namely, make it detect when you're running from cargo (CARGO_MANIFEST_DIR) and look in the right location then as well. That would solve the problem that people have with the required resources location sneakily moving about; it could always look in the cargo root dir and people could just look there.

Make sure it looks it up at runtime with std::env::vars() instead of at compile-time with env!(). That way someone building a game don't bake their build paths into something running on someone else's system.

It also starts getting to the point where it might make life easier to have a full abstract VFS tree instead of the sort of simple-and-stupid "look in place A, then look in place B, then look in place C..." system that we have now. Or at least generalizing that system.

Make a better website

Since love2d is our role model, why not make design our site to look a little bit like them? Certainly we can do better than the default Github generated site.

Do we want a default font embedded in ggez?

It wouldn't be hard, but it might be extra bloat that nobody really uses. LOVE has a default font embedded, but LOVE also is a bit more of a runtime than ggez is, and has more sneaky global state than Rust usually likes. However, having a default font that's always available is often very nice for in-game debuggers...

The graphics::print() and graphics::printf() functions in LOVE just use the default font; right now we have those functions but they're marked as unimplemented.

SDL_mixer music is broken

It plays for half a second, then sits around a while doing something ugly to out-of-bounds memory, then eventually crashes. Usually within 10-20 seconds, sometimes up to 150 on my laptop.

Ugh. Ugh ugh ugh. Kill it with fire and replace it with something else.

It might be nice to have full example projects for each platform

Basically something that someone can just clone and get going with, which includes DLL's, a working Cargo.toml with whatever flags need to be given to the compiler, etc.

The Great Issue #29 might solve this, but also might not if there's still resource-location BS that needs doing...

The attempt to be clever on missed frames can backfire

If we drop a frame we will attempt to play catch-up and get the simulation back to the state it should be in. This works great for occasional hiccups. But if we drop frames during the catch-up process it is possible that it will never end, and this hangs the event loop pretty hard.

Perhaps we impose a maximum number of frames to play catch-up on, and reduce it every time we hit it?

IRC or Gitter link?

I'd like to chat with other people making and using this. Do you guys have any chat room links you could add to the readme or website?

Need to handle non-pow2 textures

Especially for font rendering.

Now, the obvious way is to check the image size in Image::make_raw() and if necessary create a larger buffer and blit the image into it, leaving the rest of it zero. That will work fine, BUT, now we suddenly need a UV in every image and make that work with the current UV'ing code.

ugh.

But the alternative is to make this a special case for Text types, which will do exactly the same thing, which is not really any better. So, screw it, it should go in the Image code, and each Image will just acquire a default UV that is not necessarily {0, 0, 1, 1}

Warning resources.zip file not found

Got the following warning:

WARNING: Encountered error: ResourceNotFound("\'resources.zip\' file not found!)

when running:

cargo run --example astroblasto

Fixed by zipping and moved to target/debug/ folder

Text color is always white

Hi, I tried to set text color using graphics::set_color but it doesn't seem to work -- the text foreground is always white.

Offering proper line breaking might be nice.

See the xi-unicode crate for an implementation of this we might be able to use. Otherwise you can investigate harfbuzz or a simple hand-written thing based off glyph metrics.

Testing on Mac?

Looks like Travis doesn't really do this, but it'd be really nice to be able to make sure ggez at least compiles and runs minimal tests on those platforms...

It would be nice if everything was pure rust.

Deploying DLL's on Windows is a pain in the butt. Pure Rust is much easier to work with. This would mean essentially ditching SDL and using a collection of crates that provide the same functionalities.

Ditching SDL will make life harder on iOS and Android. Hmmm.

The things that we would need to replace:

  • Windowing, events and input (winapi/glutin, joystick and game controller input is a concern)
  • Graphics (gfx?)
  • Sound playing (ears, alto, ???) This is hard 'cause I believe the best crates depend on OpenAL anyway. Oh, cpal does not! Does it work well enough? rodio is built atop it, zang.
  • Sound decoding (lewton, probably others). Need wav and ogg at the least, mp3 would be great. An opus decoder would be neat, as would midi and mod synthesizers
  • Cross-platform file location handling (I know they're out there but don't remember what)

The main concerns with this is that a) we don't want to depend on something that subsequently never gets updated, and b) we don't want to take any steps backwards in functionality.

confusing ResourceNotFound error

Hi, I tried to get started with ggez by putting the hello_world example into a new project, and I get this error:

$ RUST_BACKTRACE=1 cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
     Running `target/debug/ggez_test`
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ResourceNotFound("DejaVuSerif.ttf")', /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libcore/result.rs:870
stack backtrace:
   1:     0x55984fe3d5cc - std::sys::imp::backtrace::tracing::imp::write::h9c41d2f69e5caabf
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:42
   2:     0x55984fe3fd3e - std::panicking::default_hook::{{closure}}::hcc803c8663cda123
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/panicking.rs:351
   3:     0x55984fe3f944 - std::panicking::default_hook::hd5bda4e453dfb4be
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/panicking.rs:367
   4:     0x55984fe4011b - std::panicking::rust_panic_with_hook::hffbc74969c7b5d87
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/panicking.rs:555
   5:     0x55984fe3ffb4 - std::panicking::begin_panic::hc4c5d184a1e3fb7c
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/panicking.rs:517
   6:     0x55984fe3fed9 - std::panicking::begin_panic_fmt::h34f5b320b0f94559
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/panicking.rs:501
   7:     0x55984fe3fe67 - rust_begin_unwind
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/panicking.rs:477
   8:     0x55984fe67a8d - core::panicking::panic_fmt::h1016b85b51d1931f
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libcore/panicking.rs:69
   9:     0x55984fd2b935 - core::result::unwrap_failed::h32d58e2d95a73da2
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libcore/macros.rs:29
  10:     0x55984fd26ee6 - <core::result::Result<T, E>>::unwrap::h3d9e6ceea8190f28
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libcore/result.rs:745
  11:     0x55984fd36509 - <ggez_test::MainState as ggez::game::GameState>::load::h61298cceab611496
                        at /home/aaron/dev/rust/conway/ggez_test/src/main.rs:23
  12:     0x55984fd281c8 - <ggez::game::Game<'a, S>>::new::ha71647cbf4697e3a
                        at /home/aaron/.cargo/registry/src/github.com-1ecc6299db9ec823/ggez-0.2.1/src/game.rs:123
  13:     0x55984fd36a3d - ggez_test::main::h0bd4c5cea99ba3c8
                        at /home/aaron/dev/rust/conway/ggez_test/src/main.rs:53
  14:     0x55984fe46faa - __rust_maybe_catch_panic
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libpanic_unwind/lib.rs:98
  15:     0x55984fe40886 - std::rt::lang_start::ha0568cc91d8c5b09
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/panicking.rs:436
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/panic.rs:361
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/rt.rs:57
  16:     0x55984fd36d72 - main
  17:     0x7f2ad825d400 - __libc_start_main
  18:     0x55984fd1eb49 - _start
  19:                0x0 - <unknown>

I don't understand why I am getting this error, because I have the required resource in the right location:

$ ls target/debug/resources/
DejaVuSerif.ttf

I am running the latest rust nightly, if that makes a difference:

$ rustc --version
rustc 1.16.0-nightly (ff591b6dc 2017-01-15)

Support different gfx backends

Right now OpenGL is hardwired in, it would be nice to be able to support others, even if only through feature flags.

Also might be nice to offer different OpenGL versions the same way.

Notes on experimenting with ggez+gfx

I did some experimentation and want to write down the results somewhere:

It's possible to use gfx from ggez but it requires enough re-architecting of things to be a significant headache. Creating SDL2's Renderer type consumes a Window, and creating creating a gfx window context also consumes the Window, and ggez is currently designed to require a Renderer. So you can't have both on the same window.

Getting them to interoperate would basically mean making a pluggable rendering backend for ggez, and between piston and gfx I feel like the Rust ecosystem has enough pluggable rendering backends.

The Drawable::draw() function needs to take &mut self

But this makes life horribly inconvenient sometimes so I don't want to do it just now.

Also it really shouldn't, but calling draw() might require calling Image::set_color_mode() or Image::set_blend_mode() on something, which take mutable references. Another example of SDL being annoyingly stateful. Maybe we can abstract those out into parameters that get given to draw()?

Drawing is *horribly* slow on Windows

Like, what on Linux or Mac runs at 130 fps instead runs at 6 fps.

Good example program: https://github.com/icefoxen/ggj2017 at least as of commit 851f83782d0e4dd05cb6633fd4a4e1ea9f2d1376

I blame SDL2. Still! Should get to the bottom of it one way or another.

Tested on:

  • Intel core i5 laptop with NVidia 5100M GPU running Windows 10
  • Intel core i5 laptop with NVidia 425M GPU running Windows 7

Installing on Windows needs DLL's

Apparently my system (and some others) already had it installed somewhere, but SDL2 mixer won't function without it.

We should provide a nice zip file of .dll's. Or just make everything pure Rust.

Add SDL OSX setup docs

Hi, I tried running

cargo build --example astroblasto

And got the following error:

note: ld: library not found for -lSDL2_mixer
error: Could not compile `ggez`.

Tried running:

brew install sdl2
brew install sdl2_mixer --with-libvorbis
brew install sdl2_image
export LIBRARY_PATH="$LIBRARY_PATH:/usr/local/lib"

And got the example to work

Sometimes switching screens in Linux will cause a panic

Seems to happen about 1/4 of the time on my laptop, very unreliable. Doesn't seem to happen when the window is not selected.

It's something weird happening in the timing code, but it's sort of weird.

Backtrace:

thread 'main' panicked at 'overflow when subtracting durations', ../src/libcore/option.rs:700
stack backtrace:
   1:     0x55810edb0519 - std::sys::backtrace::tracing::imp::write::h00e948915d1e4c72
   2:     0x55810edb3ebc - std::panicking::default_hook::_{{closure}}::h7b8a142818383fb8
   3:     0x55810edb31b9 - std::panicking::default_hook::h41cf296f654245d7
   4:     0x55810edb37f8 - std::panicking::rust_panic_with_hook::h4cbd7ca63ce1aee9
   5:     0x55810edb3652 - std::panicking::begin_panic::h93672d0313d5e8e9
   6:     0x55810edb35c0 - std::panicking::begin_panic_fmt::hd0daa02942245d81
   7:     0x55810edb3541 - rust_begin_unwind
   8:     0x55810edebc2f - core::panicking::panic_fmt::hbfc935564d134c1b
   9:     0x55810edebca5 - core::option::expect_failed::h1d846c7a667396f7
  10:     0x55810edae8bc - _<std..time..duration..Duration as core..ops..Sub>::sub::hedf4f5a7d9502bd0
  11:     0x55810ed3ba9f - ggez::timer::sleep_until_next_frame::h0c06a01155e5f08e
                        at /home/icefox/src/ggez/src/timer.rs:177
  12:     0x55810ecf5ea1 - _<astroblasto..MainState as ggez..game..GameState>::draw::h83e9d098d8960d6a
                        at /home/icefox/src/ggez/examples/astroblasto.rs:205
  13:     0x55810eceff1e - _<ggez..game..Game<'a, S>>::run::hd5b398ab82fbc6f6
                        at /home/icefox/src/ggez/src/game.rs:188
  14:     0x55810ecf6243 - astroblasto::main::h4882452e174ab6c4
                        at /home/icefox/src/ggez/examples/astroblasto.rs:247
  15:     0x55810edbb9a6 - __rust_maybe_catch_panic
  16:     0x55810edb2932 - std::rt::lang_start::h53bf99b0829cc03c
  17:     0x55810ecf69b3 - main
  18:     0x7fbe3d9f42b0 - __libc_start_main
  19:     0x55810eced119 - _start
  20:                0x0 - <unknown>

Add docs/explanation for Drawable::draw() src and dst parameters.

Coming from other frameworks, the methods for drawing stuff to the window might accept a graphic, position (x, y), and potentially some extended transform data (rotation, scale).

This time we have src, and dst (a pair of Option<Rect>) and it's not immediately obvious to me what the intent is. Fumbling around, I managed to get a graphic in the center of the window by supplying None as the src and dst by creating a Rect with the appropriate x/y and width/height to match the image, effectively setting the bounding box for where the image should be drawn.

Really not sure how src would be used, or if I'm even doing what would be expected for this simple case.

Travis CI failure tracking issue

Basically the Travis build is failing because rust-sdl2 now depends on SDL2 2.0.4, while Travis only has 2.0.0 available. Can we find a backport or some such? Or just build it from scratch if necessary, though that sounds like a pain.

Distributions that include SDL2 2.0.4 include (see http://packages.ubuntu.com/search?keywords=libsdl2):

  • Ubuntu Xenial
  • Debian Stretch

There IS an issue request for a source for SDL2 specifically to be added: travis-ci/apt-source-safelist#307

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.