Giter VIP home page Giter VIP logo

rust-sdl2's Introduction

Rust-SDL2 Build Status crates.io badge

Bindings for SDL2 in Rust

Overview

Rust-SDL2 is a library for talking to the new SDL2.0 libraries from Rust. Low-level C components are wrapped in Rust code to make them more idiomatic and abstract away inappropriate manual memory management.

Rust-SDL2 uses the MIT license, but SDL2 itself is under the zlib license.

Available rust features

  • gfx to link against SDL2_gfx and have access to gfx features
  • image to link against SDL2_image and have access to image reading and writing features
  • mixer to link against SDL2_mixer and have access to sound mixing features
  • ttf to link against SDL2_ttf and have access to various font features
  • raw-window-handle to enable the crate raw-window-handle, which is useful to interop with various other backends.
  • unsafe-textures to not have a lifetime in Texture structs. Texture are only freed when the program exits, or can be done manually through unsafe.
  • use-bindgen to customize bindings instead of using pre-generated sdl_bindings which were created from a Linux environment. It generates your own custom SDL2 bindings, tailored to your distro. Useful for specific window-related scenarios.
  • use-vcpkg to pull SDL2 from vcpkg instead of looking in your system.
  • use-pkgconfig use pkg-config to detect where your library is located on your system. Mostly useful on unix systems for static linking.
  • static-link to link to SDL2 statically instead of dynamically.
  • use_mac_framework to use SDL2 from a Framework, on macOS only
  • use_ios_framework to use SDL2 from a Framework, on iOS only
  • bundled, which pulls the SDL repository and compiles it from source. More information below.

Documentation

Read the documentation here.

Requirements

Rust

We currently target the latest stable release of Rust.

SDL2.0 development libraries

SDL2 >= 2.0.26 is recommended to use these bindings; below 2.0.26, you may experience link-time errors as some functions are used here but are not defined in SDL2. If you experience this issue because you are on a LTS machine (for instance, Ubuntu), we definitely recommend you to use the feature "bundled" which will compile the lastest stable version of SDL2 for your project.

"Bundled" Feature

Since 0.31, this crate supports a feature named "bundled" which compiles SDL2 from source and links it automatically. While this should work for any architecture, you will need a C compiler (like gcc, clang, or MS's own compiler) to use this feature properly.

By default, macOS and Linux only load libraries from system directories like /usr/lib. If you wish to distribute the newly built libSDL2.so/libSDL2.dylib alongside your executable, you will need to add rpath to your executable. Add the following lines to build.rs script:

#[cfg(target_os="macos")]
println!("cargo:rustc-link-arg=-Wl,-rpath,@loader_path");

#[cfg(target_os="linux")]
println!("cargo:rustc-link-arg=-Wl,-rpath,$ORIGIN");

**This ONLY works with SDL2, NOT SDL2_image, SDL2_mixer, SDL2_ttf, SDL2_gfx`

Linux

Install these through your favourite package management tool, or via http://www.libsdl.org/

Ubuntu example:

sudo apt-get install libsdl2-dev

Fedora example:

sudo dnf install SDL2-devel

Arch example:
(Arch doesn't have separate regular and development packages, everything goes together.)

sudo pacman -S sdl2

You might also need a C compiler (gcc).

Static linking in Linux

You can choose to link SDL2 statically instead of dynamically with the static-link feature. On Linux, you will need to additionally do one of the following:

  • use the bundled feature
  • use the feature use-pkgconfig so that rustc knows where to look for your SDL2 libraries and its dependencies for static linking. This is required because there is no built-in way to find the resources needed to link statically SDL2 from your system
  • install development libraries with vcpkg. Instructions to generate a static binary on Linux and other operating systems using vcpkg are here

macOS

Homebrew

On macOS, it's a good idea to install these via homebrew.

brew install sdl2

In recent versions of Homebrew, the installed libraries are usually linked into $(brew --prefix)/lib. If you are running an older version, the symlink for SDL might reside in /usr/local/lib.

To make linking libraries installed by Homebrew easier, do the following for your respective shell.

Add this line to your ~/.zshenv or ~/.bash_profile depending on whether you use ZSH or Bash.

export LIBRARY_PATH="$LIBRARY_PATH:$(brew --prefix)/lib"

MacPorts

You can also get sdl2 via macports.

sudo port install libsdl2

Then add the following to your ~/.bash_profile if not already present.

export LIBRARY_PATH="$LIBRARY_PATH:/opt/local/lib/"

If you're having issues with either Homebrew or MacPorts, see here.

If you are using the SDL2 framework

You can download and install the SDL2 Mac OS X framework from: https://www.libsdl.org/download-2.0.php

To make the sdl2 crate link with the SDL2 framework, you will need to enable the use_mac_framework feature. To build and test the sdl2 crate with this feature, use:

cargo test --features use_mac_framework

To depend on the sdl2 crate with this feature enabled, put the following in your project's Cargo.toml file:

[dependencies.sdl2]
features = ["use_mac_framework"]
version = ...  # Whichever version you are using

Alternatively, you can re-export the feature in your package by putting the following in your Cargo.toml file:

[features]
default = []
use_sdl2_mac_framework = ["sdl2/use_mac_framework"]

Similarly for iOS you can follow the same process using the use_ios_framework feature. However official builds of the iOS framework are not available so you must compile your own SDL2.framework.

Using the iOS framework also requires adding the 'Frameworks' directory to your rpath so that the dynamic linker can find SDL2.framework inside your app bundle. This is done by adding this to your build.rs:

#[cfg(target_os="ios")]
println!("cargo:rustc-link-arg=-Wl,-rpath,@loader_path/Frameworks");

Static linking on macOS using vcpkg

Instructions to generate a static binary on macOS and other operating systems using vcpkg are here.

Windows (MSVC)

  1. Download MSVC development libraries from http://www.libsdl.org/ (SDL2-devel-2.0.x-VC.zip).

  2. Unpack SDL2-devel-2.0.x-VC.zip to a folder of your choosing (You can delete it afterwards).

  3. Copy all lib files from

    SDL2-devel-2.0.x-VC\SDL2-2.0.x\lib\x64\

    to (for Rust 1.6 and above)

    C:\Program Files\Rust\lib\rustlib\x86_64-pc-windows-msvc\lib

    or to (for Rust versions 1.5 and below)

    C:\Program Files\Rust\bin\rustlib\x86_64-pc-windows-msvc\lib

    or to your library folder of choice, and ensure you have a system environment variable of

    LIB = C:\your\rust\library\folder

    For Rustup users, this folder will be in

    C:\Users\{Your Username}\.rustup\toolchains\{current toolchain}\lib\rustlib\{current toolchain}\lib

Where current toolchain is likely stable-x86_64-pc-windows-msvc.

  1. Copy SDL2.dll from

    SDL2-devel-2.0.x-VC\SDL2-2.0.x\lib\x64\

    into your cargo project, right next to your Cargo.toml.

  2. When you're shipping your game make sure to copy SDL2.dll to the same directory that your compiled exe is in, otherwise the game won't launch.

Static linking with MSVC

The MSVC development libraries provided by http://libsdl.org/ don't include a static library. This means that if you want to use the static-link feature with the windows-msvc toolchain, you have to do one of

  • build an SDL2 static library yourself and copy it to your toolchain's lib directory; or
  • also enable the bundled feature, which will build a static library for you; or
  • use a static SDL2 library from vcpkg as described below.

Windows (MinGW)

  1. Download mingw development libraries from http://www.libsdl.org/ (SDL2-devel-2.0.x-mingw.tar.gz).

  2. Unpack to a folder of your choosing (You can delete it afterwards).

  3. Copy all lib files from

    SDL2-devel-2.0.x-mingw\SDL2-2.0.x\x86_64-w64-mingw32\lib

    to (for Rust 1.6 and above)

    C:\Program Files\Rust\lib\rustlib\x86_64-pc-windows-gnu\lib

    or to (for Rust versions 1.5 and below)

    C:\Program Files\Rust\bin\rustlib\x86_64-pc-windows-gnu\lib

    or to your library folder of choice, and ensure you have a system environment variable of

    LIBRARY_PATH = C:\your\rust\library\folder

    For Rustup users, this folder will be in

    C:\Users\{Your Username}\.rustup\toolchains\{current toolchain}\lib\rustlib\{current toolchain}\lib

Where current toolchain is likely stable-x86_64-pc-windows-gnu.

  1. Copy SDL2.dll from

    SDL2-devel-2.0.x-mingw\SDL2-2.0.x\x86_64-w64-mingw32\bin

    into your cargo project, right next to your Cargo.toml.

  2. When you're shipping your game make sure to copy SDL2.dll to the same directory that your compiled exe is in, otherwise the game won't launch.

Static linking with MinGW

If you want to use the static-link feature with the windows-gnu toolchain, then you will also need the following libraries:

libimm32.a
libversion.a
libdinput8.a
libdxguid.a

These files are not currently included with the windows-gnu toolchain, but can be downloaded here. For the x86_64 toolchain, you want the x86_64-win32-seh package, and for i686 you want the i686-win32-dwarf one.

You will find the aforementioned libraries under mingw64/x86_64-w64-mingw32/lib/ (for x86_64) or mingw32/i686-w64-mingw32/lib/ (for i686). Copy them to your toolchain's lib directory (the same one you copied the SDL .a files to).

Windows with build script

  1. Download mingw and msvc development libraries from http://www.libsdl.org/ (SDL2-devel-2.0.x-mingw.tar.gz & SDL2-devel-2.0.x-VC.zip).
  2. Unpack to folders of your choosing (You can delete it afterwards).
  3. Create the following folder structure in the same folder as your Cargo.toml:
gnu-mingw\dll\32
gnu-mingw\dll\64
gnu-mingw\lib\32
gnu-mingw\lib\64
msvc\dll\32
msvc\dll\64
msvc\lib\32
msvc\lib\64
  1. Copy the lib and dll files from the source archive to the directories we created in step 3 like so:
SDL2-devel-2.0.x-mingw.tar.gz\SDL2-2.0.x\i686-w64-mingw32\bin 		-> 	gnu-mingw\dll\32
SDL2-devel-2.0.x-mingw.tar.gz\SDL2-2.0.x\x86_64-w64-mingw32\bin 	-> 	gnu-mingw\dll\64
SDL2-devel-2.0.x-mingw.tar.gz\SDL2-2.0.x\i686-w64-mingw32\lib 		-> 	gnu-mingw\lib\32
SDL2-devel-2.0.x-mingw.tar.gz\SDL2-2.0.x\x86_64-w64-mingw32\lib 	-> 	gnu-mingw\lib\64
SDL2-devel-2.0.8-VC.zip\SDL2-2.0.x\lib\x86\*.dll	 		-> 	msvc\dll\32
SDL2-devel-2.0.8-VC.zip\SDL2-2.0.x\lib\x64\*.dll 			-> 	msvc\dll\64
SDL2-devel-2.0.8-VC.zip\SDL2-2.0.x\lib\x86\*.lib	 		-> 	msvc\lib\32
SDL2-devel-2.0.8-VC.zip\SDL2-2.0.x\lib\x64\*.lib	 		-> 	msvc\lib\64
  1. Create a build script, if you don't already have one put this in your Cargo.toml under [package]:

build = "build.rs"

  1. Create a file in the same directory as Cargo.toml called build.rs (if you didn't already have a build script) and paste this into it:
use std::env;
use std::path::PathBuf;

fn main() {
    let target = env::var("TARGET").unwrap();
    if target.contains("pc-windows") {
        let manifest_dir = PathBuf::from(env::var("CARGO_MANIFEST_DIR").unwrap());
        let mut lib_dir = manifest_dir.clone();
        let mut dll_dir = manifest_dir.clone();
        if target.contains("msvc") {
            lib_dir.push("msvc");
            dll_dir.push("msvc");
        }
        else {
            lib_dir.push("gnu-mingw");
            dll_dir.push("gnu-mingw");
        }
        lib_dir.push("lib");
        dll_dir.push("dll");
        if target.contains("x86_64") {
            lib_dir.push("64");
            dll_dir.push("64");
        }
        else {
            lib_dir.push("32");
            dll_dir.push("32");
        }
        println!("cargo:rustc-link-search=all={}", lib_dir.display());
        for entry in std::fs::read_dir(dll_dir).expect("Can't read DLL dir")  {
            let entry_path = entry.expect("Invalid fs entry").path();
            let file_name_result = entry_path.file_name();
            let mut new_file_path = manifest_dir.clone();
            if let Some(file_name) = file_name_result {
                let file_name = file_name.to_str().unwrap();
                if file_name.ends_with(".dll") {
                    new_file_path.push(file_name);
                    std::fs::copy(&entry_path, new_file_path.as_path()).expect("Can't copy from DLL dir");
                }
            }
        }
    }
}
  1. On build the build script will copy the needed DLLs into the same directory as your Cargo.toml, you probably don't want to commit these to any Git repositories though so add the following line to your .gitignore file

/*.dll

  1. When you're publish your game make sure to copy the corresponding SDL2.dll to the same directory that your compiled exe is in, otherwise the game won't launch.

And now your project should build and run on any Windows computer!

Windows (MSVC with vcpkg)

  1. Install MS build tools and vcpkg
  2. Install the needed SDL2 libs: vcpkg.exe install sdl2-ttf:x64-windows sdl2:x64-windows
  3. Open a x64 native tools prompt (x64 Native Tools Command Prompt for VS 2019)
  4. set env vars:
SET PATH=%PATH%;C:\Users\my_user\dev\vcpkg\installed\x64-windows\bin
SET INCLUDE=%INCLUDE%;C:\Users\my_user\dev\vcpkg\installed\x64-windows\include
SET LIB=%LIB%;C:\Users\my_user\dev\vcpkg\installed\x64-windows\lib
  1. cargo build

Windows, Linux and macOS with vcpkg

Another method of getting the development libraries is with vcpkg. To set up a project to build a static binary on Windows (MSVC), Linux or macOS that is buildable like this:

cargo install cargo-vcpkg
cargo vcpkg build
cargo build

add the following your Cargo.toml:

[dependencies.sdl2]
version = "0.37"
default-features = false
features = ["ttf","image","gfx","mixer","static-link","use-vcpkg"]

[package.metadata.vcpkg]
dependencies = ["sdl2", "sdl2-image[libjpeg-turbo,tiff,libwebp]", "sdl2-ttf", "sdl2-gfx", "sdl2-mixer"]
git = "https://github.com/microsoft/vcpkg"
rev = "2024.05.24" # release 2024.05.24 # to check for a new one, check https://github.com/microsoft/vcpkg/releases

[package.metadata.vcpkg.target]
x86_64-pc-windows-msvc = { triplet = "x64-windows-static-md" }

More information on the cargo vcpkg tool is here.

Installation

If you're using cargo to manage your project, you can download through Crates.io:

    [dependencies]
    sdl2 = "0.37"

Alternatively, pull it from GitHub to obtain the latest version from master

    [dependencies.sdl2]
    git = "https://github.com/rust-sdl2/rust-sdl2"

Otherwise, clone this repo and run cargo

cargo build

You can enable features such as ttf, image, gfx and mixer by adding this instead:

    [dependencies.sdl2]
    version = "0.37"
    default-features = false
    features = ["ttf","image","gfx","mixer"]

Those features need their respective libraries, which can be found at these locations : (the install process is the same as SDL2)

What about sdl2_net ?

As of now, sdl2_net is meaningless compared to what other crates such as serde and bincode can offer. We highly recommend using those to develop anything UDP or TCP related (along with futures or TCP/UDP from the standard library).

If you still want an implementation of sdl2_net, you can try to add it in this repo as a feature via a Pull Request. A somewhat outdated version of this binding can be found here

Demo

We have several simple example projects included:

cargo run --example demo

You can see the full list in the examples/ folder. Some examples require some features, you can enable them like so:

cargo run --example gfx-demo --features "gfx"

Replace "gfx" by the feature(s) needed for the example you want.

About the unsafe_textures feature

In the sdl2::render module, Texture has by default lifetimes to prevent it from out-living its parent TextureCreator. These lifetimes are sometimes too hard to deal with in Rust, and so you have the option to enable the unsafe_textures feature.

This removes the lifetimes on the Textures, at the cost of optional manual memory management. If you want to manually destroy the Textures you use, you can call the destroy method of your Textures, but beware that it should not be called if none of the parents (Canvas or TextureCreator) are alive. If you do not call this method, the memory will simply be freed when the last Canvas or the last TextureCreator will be freed.

There is no online documentation for this feature, however you can build it yourself in your project by enabling the feature in your Cargo.toml, running cargo doc and accessing target/doc/sdl2/index.html via a browser.

Generating sdl2-sys with bindgen

The sdl2-sys that was generated for this crate is very generic and can be used on a lot of platforms with very few limitations. However, you may sometimes face trouble when using platform-specific features of SDL2, for instance the WindowManager category.

The feature "use-bindgen" allows you to avoid this limitation by generating the proper bindings depending on your target. It will take the headers based on what pkg-config outputs (if you enabled the feature "use-pkg-config") and generate bindings based on them. If you don't have pkg-config or disabled the feature, it will try to get the headers in SDL-2.0.8/include of this crate instead.

If somehow you have your own headers that you want to use (use a beta version, an older version, ...), you can set the environment variable "SDL2_INCLUDE_PATH" and those headers will be used by bindgen instead.

Using sdl2-sys to provide SDL2 headers/library

If you are creating a *-sys crate for a library which requires SDL2, you can use sdl2-sys to provide both the compiled library and the headers for SDL2.

Follow the following process to get the header directory. In the Cargo.toml for your crate, add sdl2-sys as a dependency (not a build-dependency). Cargo will then provide your build script with an environment variable DEP_SDL2_INCLUDE which is populated with the include directory for SDL2. If there is more than one directory, they are combined with : as a separator. Pass these directories to whatever is building your C/C++.

Once everything is linked together, there will be a single copy of SDL2 (the one provided by sdl2-sys) for all C, C++, and Rust code.

For more discussion see the corresponding issue

OpenGL

There are two ways to use OpenGL:

  • As a backend for sdl2::render, where everything is done for you by sdl2. It is the default for linux devices.
  • Manually, using only sdl2 as a "shell" for your window (akin to glutin and winit crates), and still use sdl2's joystick, events, audio, text input, ect capabilities.

If you want to use OpenGL, you also need the gl-rs package. If you're using cargo, just add these lines to your Cargo.toml:

    [dependencies.gl]
    git = "https://github.com/bjz/gl-rs"

You have two options to use OpenGL with sdl2:

  • Use OpenGL with Canvas and use sdl2::render
  • Use OpenGL directly on the Window "shell" and use manual OpenGL calls to render something

Use sdl2::render

First, find the OpenGL driver from SDL:

fn find_sdl_gl_driver() -> Option<u32> {
    for (index, item) in sdl2::render::drivers().enumerate() {
        if item.name == "opengl" {
            return Some(index as u32);
        }
    }
    None
}

fn main() {
    let sdl_context = sdl2::init().unwrap();
    let video_subsystem = sdl_context.video().unwrap();
    let window = video_subsystem.window("Window", 800, 600)
        .opengl() // this line DOES NOT enable opengl, but allows you to create/get an OpenGL context from your window.
        .build()
        .unwrap();
    let canvas = window.into_canvas()
        .index(find_sdl_gl_driver().unwrap())
        .build()
        .unwrap();

    // ...
}

If you don't plan to use OpenGL calls via the gl-rs crate, you can stop here. SDL2 will automatically use the OpenGL backend

If you plan to have your own calls intertwined with the sdl2 calls, you need to use the context of your canvas first:

// initialization
gl::load_with(|name| video_subsystem.gl_get_proc_address(name) as *const _);

// sdl::render creates a context for you, if you use a Canvas you need to use it.
canvas.window().gl_set_context_to_current();

// ... in the main loop ...
unsafe {
    gl::ClearColor(0.6, 0.0, 0.8, 1.0);
    gl::Clear(gl::COLOR_BUFFER_BIT);
}
canvas.present();

Be wary though, sdl2 has its own internal state which you should avoid messing with. Avoid using manual OpenGL in the middle of SDL2 calls, or make sure to restore the previous state.

Use OpenGL calls manually

extern crate sdl2;
extern crate gl;

use sdl2::event::Event;
use sdl2::keyboard::Keycode;
use sdl2::video::GLProfile;

fn main() {
    let sdl_context = sdl2::init().unwrap();
    let video_subsystem = sdl_context.video().unwrap();
    
    let gl_attr = video_subsystem.gl_attr();
    gl_attr.set_context_profile(GLProfile::Core);
    gl_attr.set_context_version(3, 3);

    let window = video_subsystem.window("Window", 800, 600)
        .opengl()
        .build()
        .unwrap();

    // Unlike the other example above, nobody created a context for your window, so you need to create one.
    let ctx = window.gl_create_context().unwrap();
    gl::load_with(|name| video_subsystem.gl_get_proc_address(name) as *const _);
    
    debug_assert_eq!(gl_attr.context_profile(), GLProfile::Core);
    debug_assert_eq!(gl_attr.context_version(), (3, 3));

    let mut event_pump = sdl_context.event_pump().unwrap();

    'running: loop {
        unsafe {
            gl::ClearColor(0.6, 0.0, 0.8, 1.0);
            gl::Clear(gl::COLOR_BUFFER_BIT);
        }

        window.gl_swap_window();
        for event in event_pump.poll_iter() {
            match event {
                Event::Quit {..} | Event::KeyDown { keycode: Some(Keycode::Escape), .. } => {
                    break 'running
                },
                _ => {}
            }
        }
        ::std::thread::sleep(::std::time::Duration::new(0, 1_000_000_000u32 / 60));
    }
}

As mentionned above, this method is useful when you don't care about sdl2's render capabilities, but you do care about its audio, controller and other neat features that sdl2 has.

You don't have to worry about messing with the state intertwined with sdl2 or a version you don't like: SDL2 will never call any OpenGL function outside the render module.

Vulkan

To use Vulkan, you need a Vulkan library for Rust. This example uses the Vulkano library. Other libraries may use different data types for raw Vulkan object handles. The procedure to interface SDL2's Vulkan functions with these will be different for each one.

First, make sure you enable the raw-window-handle feature.

extern crate sdl2;
extern crate vulkano;

use sdl2::event::Event;
use sdl2::keyboard::Keycode;
use vulkano::instance::{Instance, InstanceCreateInfo, InstanceExtensions};
use vulkano::swapchain::Surface;
use vulkano::VulkanLibrary;

fn main() {
    let sdl_context = sdl2::init().unwrap();
    let video_subsystem = sdl_context.video().unwrap();

    let window = video_subsystem
        .window("Window Title - My Vulkano-SDL2 application", 1024, 768)
        .vulkan()
        .build()
        .unwrap();

    let instance_extensions =
        InstanceExtensions::from_iter(window.vulkan_instance_extensions().unwrap());

    let instance = Instance::new(
        VulkanLibrary::new().unwrap(),
        InstanceCreateInfo {
            enabled_extensions: instance_extensions,
            ..Default::default()
        },
    )
    .unwrap();

    // SAFETY: Be sure not to drop the `window` before the `Surface` or vulkan `Swapchain`!
    // (SIGSEGV otherwise)
    let surface = unsafe { Surface::from_window_ref(instance.clone(), &window) };

    let mut event_pump = sdl_context.event_pump().unwrap();

    'running: loop {
        for event in event_pump.poll_iter() {
            match event {
                Event::Quit { .. }
                | Event::KeyDown {
                    keycode: Some(Keycode::Escape),
                    ..
                } => {
                    break 'running;
                }
                _ => {}
            }
        }
        ::std::thread::sleep(::std::time::Duration::new(0, 1_000_000_000u32 / 60));
    }
}

Support for raw-window-handle

raw-window-handle can be enabled using the feature name:

[dependencies.sdl2]
version = "0.37"
features = ["raw-window-handle"]

An example working with wgpu is also available:

cargo run --example raw-window-handle-with-wgpu --features raw-window-handle

sdl2 with raw-window-handle on macOS:

On macOS the RawWindowHandle.ns_view field is returned null. Libraries consuming the RawWindowHandle (such as wgpu) should determine a sane default for ns_view. If they do not, please file an issue with the associated project.

raw-window-handle on Android

On some platforms, including Android, SDL2 tries to create the OpenGL context by itself even without creating a renderer. This can manifest in errors like VK_ERROR_NATIVE_WINDOW_IN_USE_KHR when initializing Vulkan or GLES. Add the following code before creating a window to fix the errors:

sdl2::hint::set("SDL_VIDEO_EXTERNAL_CONTEXT", "1")

When things go wrong

Rust, and Rust-SDL2, are both still heavily in development, and you may run into teething issues when using this. Before panicking, check that you're using the latest version of both Rust and Cargo, check that you've updated Rust-SDL2 to the latest version, and run cargo clean. If that fails, please let us know on the issue tracker.

Contributing

Any Pull Request is welcome, however small your contribution may be ! There are, however, conditions to contribute:

  • New features must be properly documented, be it via examples or inline documentation (via cargo doc). Documentation must be for the end user as well as your next fellow contributor.
  • Breaking changes must have a proper argumentation with it. While the pre-1.0 state of this crate allows us to be somewhat unstable, useless breaking changes will be denied.
  • Minor changes, breaking changes and new features added via Pull Request must be added in the changelog file. It is now mandatory to log your changes in the changelog. A short description with a link to your commit/pull request within GitHub is fine. Internal, documentation or meta-changes (travis build change, README instructions updates, ...) don't have to be added in the changelog.

rust-sdl2's People

Contributors

amaranth avatar andelf avatar angrylawyer avatar antonilol avatar bvssvni avatar cobrand avatar crumblingstatue avatar deadacute avatar drbawb avatar eagleflo avatar guillaumegomez avatar hectorgrey avatar icefoxen avatar jcmoyer avatar johnthagen avatar jonemil avatar moralrecordings avatar mvdnes avatar netvl avatar nukep avatar olegoandreev avatar pyrrho avatar reima avatar sbidin avatar seemk avatar ticky avatar ubsan avatar vadixidav avatar waych avatar xsleonard 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

rust-sdl2's Issues

multiple windows?

The SDL2 announcement claims

Support for multiple windows

However, with this somewhat trimmed down version of my graphing code, I get a segfault with this traceback / memory profile instead of a pair of windows like this when I try spawn a pair of windows and renderers in tasks separated across OS threads.

I haven't had a chance to source dive, but figured I'd post the issue and start discussion.

Implement SDL_RWclose()

SDL_RWclose is a macro for calling SDL_RWclose's close() function pointer.

Issues:

  • close() returns a c_int error status, so it may be a problem implementing it as a Drop trait, if the error is to be handled.
  • Dealing with C function pointers with the FFI

Without this, I think Surface::from_bmp and Surface::save_bmp leak.

Segfault when trying to run sprocketnes

In my quest to try to run sprocketnes, I came upon a segmentation fault. The issue occurs in the audio.rs file, here's a stack trace that I've gotten from

#0  0x00007ffff71706c4 in free () from /usr/lib/libc.so.6
#1  0x0000000000403972 in rt::global_heap::exchange_free::h8daf9fef83a0f1b243f::v0.0 ()
#2  0x000000000040392a in rt::global_heap::exchange_free_::h6f63fd71845373c6S3f::v0.0 ()
#3  0x0000000000405f2c in _$UP$i8::glue_drop.5646::h08eee8e7ab191bea ()
#4  0x000000000040b7a5 in _$LP$sdl2..audio..AudioDevice$C$$UP$sdl2..audio..AudioSpec$LT$$GT$$RP$::glue_drop.5742::h32638b13c613f8c0 ()
#5  0x000000000040b3b0 in nes::audio::open () at audio.rs:89
#6  0x000000000041170d in nes::main::start (argc=2, argv=0x7fffffffe938) at main.rs:109
#7  0x0000000000428758 in fn6333 () at nes.rs:38
#8  0x0000000000479503 in start::closure.7193 ()
#9  0x000000000048edb3 in rt::task::Task::run::closure.40321 ()
#10 0x000000000049e32c in rust_try ()
#11 0x000000000048ec12 in rt::task::Task::run::h8d4be746ef52ccf63W7::v0.11.pre ()
#12 0x0000000000479324 in start::h9cb6401b9f29e92exxd::v0.11.pre ()
#13 0x00000000004286ed in nes::main (argc=2, argv=0x7fffffffe938) at nes.rs:38
#14 0x0000000000428640 in main ()

In addition, gdb shows the following error twice when stepping through the program:

ALSA lib pcm.c:7843:(snd_pcm_recover) underrun occurred

Steps to reproduce:
Pulled the master branch of both rust-sdl2 and sprocketnes. Adjust two lines in sprocketnes that stopped it from compiling (in gfx.rs, renderer: Renderer becomes renderer: ~Renderer and the same for the texture line just below it). I'm using rust-nightly-bin-0.11_pre_2014.05.06-1 (the rust-nightly-bin package for Arch, from AUR)
make the rust-sdl2 project, then copy the resulting library to the sprocketnes folder and compile with rustc -L. -g nes.rs. I added -g to rust-sdl2's compile options in the Makefile to get a useful stacktrace as well.

Should all bool error flags be converted to Result<(), ~str> ?

There are places in the SDL2 api that return boolean to signal an error. See e.g.
Render::copy.

The only reasons I can imagine to continue doing so in the Rust API are:

  • "Efficiency" (under the hypothetical belief that returning a boolean and checking it in the caller is more efficient than returning Ok(()) and checking that result in the caller via the result API methods,
  • To ease conversion from sample SDL2 code into Rust client code using rust-sdl2

I don't find either argument particularly compelling.

The main reason to use Result<(), _> instead of bool is because the must_use lint will fire and force one to do some form of error checking (even if it is only calling the ok() method or using try!).

But before going through the exercise of converting the methods that return a boolean error flag to use Result<(), ~str> instead, I thought I should check and see whether there was another reason to use this protocol that I have overlooked.

Use Rust-Empty?

andelf/rust-sdl2_mixer#2 (comment)

The rust-sdl2_mixer library has no makefile. In the Piston project we use a fork https://github.com/PistonDevelopers/rust-sdl2_mixer with the Rust-Empty that makes it easier to integrate with our infrastructure. It is only rust-sdl2_mixer that is on a sidetrack at the moment and it is mostly because of the lack of a makefile.

I don't know what plans there are to emigrate the SDL2 libraries to Cargo. One possible way could be to use Rust-Empty, which uses the same compilation/linking structure as Cargo does. This requires a bit of planning, though. This is worth considering if you want to do changes to the project structure anyway.

Build fails with latest Rust

I'm seeing the following compilation error with the latest version of Rust:

$ make
rustc --out-dir './build/lib' src/sdl2/lib.rs  --cfg mac_dylib
src/sdl2/audio.rs:264:100: 264:109 error: wrong number of lifetime parameters: expected 1 but found 0 [E0107]
src/sdl2/audio.rs:264     pub fn open(device: Option<&str>, iscapture: int, spec: &AudioSpec) -> SdlResult<(AudioDevice, AudioSpec)> {
                                                                                                                         ^~~~~~~~~
error: aborting due to previous error
make: *** [build/tmp/libsdl2.dummy] Error 101

Intersect_line fails on Travis

Until I've got my broadband plugged in, I can only run the tests on my workplace OSX machine, which all pass.

However, on the Travis linux box, we get the following error:

task 'rect::test::test_intersect_line' failed at 'assertion failed: `(left == right) && (right == left)` (left: `Some((Point { x: 0, y: 0 }, Point { x: 5, y: 5 }))`, right: `Some((Point { x: 1, y: 1 }, Point { x: 5, y: 5 }))`)', src/sdl2/rect.rs:177

rustpkg?

I'm going through a bunch of my little rust library one-offs and making the directory / repo match the latest rustpkg spec - is this something we should consider for sdl2?

A better way to handle C enum like flags

Currently, we use a &[Flag] type to represent it. I think it is better to use std::ops::BitOr trait to support c-style flag compostion instead of using list. btw, this will also make it type-safe.

A sample in my rust-sdl_mixer lib:

use std::default;
use std::ops::BitOr;

#[deriving(Clone, Eq, Hash, Show)]
pub enum InitFlag {
    InitFlac,
    InitMod,
    InitModPlug,
    InitMp3,
    InitOgg,
    InitFluidSynth,
    InitRaw(int),
}

impl InitFlag {
    #[inline]
    pub fn to_ll(self) -> c_int {
        match self {
            InitFlac       => ffi::MIX_INIT_FLAC as c_int,
            InitMod        => ffi::MIX_INIT_MOD as c_int,
            InitModPlug    => ffi::MIX_INIT_MODPLUG as c_int,
            InitMp3        => ffi::MIX_INIT_MP3 as c_int,
            InitOgg        => ffi::MIX_INIT_OGG as c_int,
            InitFluidSynth => ffi::MIX_INIT_FLUIDSYNTH as c_int,
            InitRaw(n)     => n as c_int,
        }
    }

    pub fn from_ll(n: c_int) -> InitFlag {
        InitRaw(n as int)
    }

    pub fn mask(self, flag: InitFlag) -> bool {
        self.to_ll() & flag.to_ll() == flag.to_ll()
    }
}

impl BitOr<InitFlag, InitFlag> for InitFlag {
    fn bitor(&self, rhs: &InitFlag) -> InitFlag {
        InitRaw(self.to_ll() as int | rhs.to_ll() as int)
    }
}

impl default::Default for InitFlag {
    fn default() -> InitFlag {
        InitFlag::from_ll(0xFFFFFF as c_int)
    }
}

Enum size changes could cause mishaps in foreign function magic

"found enum type without foreign-function-safe representation annotation in foreign module, #[warn(ctypes)] on by default"

This is due to the recent changes to enums which collapse them as small as possible - I've yet to find the correct representation that we're supposed to pass.

Loading OpenGL functions with gl-rs does not work

gl::load_with(|s| sdl2::video::gl_get_proc_address(s));

This line fails with

error: mismatched types: expected `*libc::types::common::c95::c_void` but found `core::option::Option<extern "system" fn()>` (expected *-ptr but found enum core::option::Option)

I'm not around to merge things between 9th Jul - 24th Jul

As I've got no real way of contacting everyone who contributes:

I'm going into the wilderness for two weeks, where Internet access will be very limited. As I'm the only maintainer on this project at the moment, things probably won't get merged between these two dates.

Add instructions of how to install SDL2 through package manager to README

I have seen this question come up a couple of times.

If you try to install SDL2 by downloading the developer libraries and copy to /Library/Frameworks, then it won't work when building with Cargo because it does not detect this version.

As most new users will try to use Cargo, it would be nice to add instructions of how to install SDL2 through brew and where to get brew if they don't already have it.

Unused result warnings

Since the removal of io_error there are a bunch of warnings where the IoResults from io functions aren't being used:
warning: unused result which must be used, #[warn(unused_must_use)] on by default

All of these warnings are confined to src/codegen/*.rs.

The worst offender is branchify.rs, but all the writeing is confined to a macro. It wouldn't be hard to string the Results:

let r = writer.write(indentstr.as_bytes())
              .and(writer.write(s.as_bytes()))
              .and(writer.write(bytes!("\n")));
match r {
    // not sure if there's a cleaner way to do this
    Err(e) => fail!("write error: ", e.desc),
    Ok(_) => {}
}

keycode.rs and scancode.rs have formatted writes scattered throughout the files. Perhaps a modified version of wf could be shared between files.

main.rs can be fixed simply by checking the result of mkdir_recursive.

Thoughts?

KeyDown and KeyUp events incorrectly returned as NoEvents

KeyDown and KeyUp event's are returned as NoEvents if Window::from_id(event.windowID) returns an error, this is the wrong behavior because these events aren't necessarily associated with a window (The documentation says windowID the window with keyboard focus, if any).

Here is a small test case that triggers the behavior (Should exit on a keypress, instead turns into an infinite loop):

extern crate sdl2;
use sdl2::video;
use sdl2::event;

fn main() {
    sdl2::init( sdl2::InitVideo );
    let window = video::Window::new("testcase", 
                                    video::PosUndefined, 
                                    video::PosUndefined,
                                    400, 480, 
                                    video::Shown).unwrap();
    window.get_surface(); // If I remove this then the KeyDown event
                          // is given the windowID, I don't know why
    loop {
        match event::poll_event() {
            event::KeyDownEvent(..) => break,
            _ => ()
        }
    }
}

building w/ rustpkg on OSX 10.8 Mountain Lion

I have installed the standard OSX distro of SDL2 (you put it in /Library/Frameworks). Prior to migrating to rustpkg, I was able to build rust-sdl2 (It's been a while since I last did, so I don't recall if it was by passing a -L flag or something else..). Anyways, I was excited to check out rust-sdl2 today and see that it's been updated to support rustpkg. So I pulled the latest and tried to run a test build, before updating the deps in my downstream project.

This is what I'm getting:

bash-3.2$ rustpkg build sdl2
WARNING: The Rust package manager is experimental and may be unstable
error: linking with `cc` failed: exit code: 1
note: cc arguments: '-m64' '-L/Users/jeff/lib/rustc/x86_64-apple-darwin/lib' '-o' '/Users/jeff/src/rust-sdl2/build/x86_64-apple-darwin/sdl2/libsdl2-39ba6e81-0.0.dylib' '/Users/jeff/src/rust-sdl2/build/x86_64-apple-darwin/sdl2/sdl2.o' '/Users/jeff/src/rust-sdl2/build/x86_64-apple-darwin/sdl2/sdl2.metadata.o' '-L/Users/jeff/src/rust-sdl2/.rust' '-L/Users/jeff/src/rust-sdl2' '-L/Users/jeff/src/.rust' '-lSDL2' '-L/Users/jeff/lib/rustc/x86_64-apple-darwin/lib' '-lstd-04ff901e-0.9-pre' '-lpthread' '-lstdc++' '-dynamiclib' '-Wl,-dylib' '-Wl,-install_name,@rpath/libsdl2-39ba6e81-0.0.dylib' '-lmorestack' '-Wl,-rpath,@loader_path/../../../../../lib/rustc/x86_64-apple-darwin/lib' '-Wl,-rpath,/Users/jeff/lib/rustc/x86_64-apple-darwin/lib'
note: ld: library not found for -lSDL2
clang: error: linker command failed with exit code 1 (use -v to see invocation)

error: aborting due to previous error
task '<unnamed>' failed at 'explicit failure', /Users/jeff/src/rust/src/libsyntax/diagnostic.rs:102
task '<unnamed>' failed at 'receiving on a closed channel', /Users/jeff/src/rust/src/libstd/comm/mod.rs:745
bash-3.2$

If there's some secret incantation, passed via --link-args, for rustpkg to make this work, I haven't figured out what it is, yet. Any help would be greatly appreciated.

`*X` and `*mut X` pointers

I think we need to correctly use * and *mut pointers in FFI definitions, that is, we have to look through the C API and use *X where it uses const X* and *mut X where it uses *X.

Current situation (using *X for all pointers) is bad because of things like these:

    pub fn get_draw_color(&self) -> Result<pixels::Color, ~str> {
        let r: u8 = 0;
        let g: u8 = 0;
        let b: u8 = 0;
        let a: u8 = 0;
        let result = unsafe { ll::SDL_GetRenderDrawColor(self.raw, &r, &g, &b, &a) == 0 };
        if result {
            Ok(pixels::RGBA(r, g, b, a))
        } else {
            Err(get_error())
        }
    }

Note that local variables are not mutable, but they still are modified by the foreign call, but if we make them mutable, then the compiler will show a warning about unnecessary mutability. If SDL_GetRenderDrawColor() took *mut pointers, this warning wouldn't appear.

In fact, I believe we should use bindgen instead of manual bindings. It seems that it becomes a primary mean to link with C libraries, provided that bindgen! macro can become a part of Rust distribution itself.

A lot of unnecessary boxing

I've noticed that there is a lot of boxing present in the library, for example:

pub fn from_window(window: ~video::Window, index: RenderDriverIndex, renderer_flags: RendererFlags) -> Result<~Renderer, ~str> { ... }
pub fn new(title: &str, x: WindowPos, y: WindowPos, width: int, height: int, window_flags: WindowFlags) -> Result<~Window, ~str> { ... }

Return types are Result<~Window, ~str> and Result<~Renderer, ~str> have Window and Renderer boxed.

That is, a lot of functions return and accept owned pointers to structures, but these structures are very small:

pub struct Window {
    pub raw: *ll::SDL_Window,
    pub owned: bool
}

This is unidiomatic: according to Rust manual pointers should only be used when absolutely necessary.

Is this boxing justified? If not, I think it should be fixed. I'd be willing to contribute.

RenderCopy undefined behaviour

It seems rendering a texture is broken with optimizations enabled. The following program should render a white square on a red background, but it only works with --opt-level=0. I'm sure it worked before 24th of July, something went awry when upgrading to the latest Rust.

https://gist.github.com/seemk/916f32172c8f81e29845

It looks like this is a miscompile, SDL_RenderCopy receives a wrong Rect object. I'm not sure why the %rect4.i is even created.

%rectct4.i = alloca %"struct.sdl2::rect::Rect<[]>[#11]", align 8
%dst_rect = alloca %"struct.sdl2::rect::Rect<[]>[#11]", align 8

%226 = bitcast %"struct.sdl2::rect::Rect<[]>[#11]"* %dst_rect to i8*
  call void @llvm.lifetime.start(i64 16, i8* %226)
  invoke void @_ZN4rect4Rect3new20h4f27fd3dae56a7a4lDnE(%"struct.sdl2::rect::Rect<[]>[#11]"* noalias nocapture sret dereferenceable(16) %dst_rect, i32 100, i32 100, i32 100, i32 100)
          to label %join8.i unwind label %unwind_ast_7_65

%238 = bitcast %"struct.sdl2::rect::Rect<[]>[#11]"* %rect4.i to i8*
call void @llvm.lifetime.start(i64 16, i8* %238)
call void @llvm.lifetime.end(i64 16, i8* %238)

%239 = invoke i32 @SDL_RenderCopy(%"struct.sdl2::render::ll::SDL_Renderer<[]>[#11]"* %235, %"struct.sdl2::render::ll::SDL_Texture<[]>[#11]"* %237, %"struct.sdl2::rect::Rect<[]>[#11]"* null, %"struct.sdl2::rect::Rect<[]>[#11]"* %rect4.i)
          to label %.noexc270 unwind label %unwind_ast_7_68.nonloopexit

"raw: *ll::SDL_Renderer" should be *mut?

I am writing a wrapper for SDL2_image and encountered a problem using struct Renderer with SDL_Texture* IMG_LoadTexture(SDL_Renderer *renderer, const char *file);. SDL_Renderer* is not declared as const in for this function, nor in SDL functions such as int SDL_RenderClear(SDL_Renderer* renderer), but the raw member in the struct wrapper is immutable.

https://github.com/AngryLawyer/rust-sdl2/blob/master/src/sdl2/render.rs#L217

I don't know enough about rust to know if this is really a problem as long as the C function call is wrapped in unsafe{}.

Doesn't compile with latest rust.

src/sdl2/event.rs:23:32: 23:39 error: unresolved import: there is no `c_schar` in `libc`
src/sdl2/event.rs:23     use libc::{c_float, c_int, c_schar, c_uint, c_void, int16_t,
...

I don't have time to fix ATM, but I might look into it later.

Dead code warnings on members

The dead code checker has been updated. It now checks that the struct members are used and not just written to. Because rust-sdl2 contains a lot members to track ownership and be dropped at the right time, it is required to go through all the warnings and mark each members with #[allow_dead_code].

Unnecessarily moved values

It would be nice if this would work like you'd expect it to:

let window = Window::new(...).unwrap();
let renderer = Renderer::from_window(window, ...);
window.set_title("hello world!"); // error: use of moved value (window)

from_window assumes ownership of the window you pass in currently. @dpx-infinity mentioned a few ways of dealing with this in #91:

  1. link the renderer and window lifetimes
  2. allow the renderer to own the window and provide an accessor function.

I'm personally in favor of No. 1 because it's closer to how the C API works - renderers don't own windows and vice versa. Are there any other safe ways to solve the problem?

Renderer.copy might not be correct

Been trying to get an image on screen, but when calling the copy() method of renderer like this:

let rect = rect::Rect::new(0, 0, 200, 200);
renderer.copy(texture, None, Some(&rect));

Nothing gets rendered. The image is loaded correctly, but SDL doesn't attempt to draw anything (confirmed by osx OpenGL profiler trace), and returns True from the call.

Changing the code for copy() to have this

pub fn copy(&self, texture: &Texture, src: Option<Rect>, dst: Option<Rect>) -> bool {
        unsafe {
            ll::SDL_RenderCopy(
                self.raw,
                texture.raw,
                match src {
                    Some(rect) => cast::transmute(&rect),
                    None => ptr::null() 
                },
                match dst {
                    Some(rect) => cast::transmute(&rect),
                    None => ptr::null() 
                }
            ) == 0
        }
    }

similar to the way Texture.update() is implemented works, and the image is displayed.

However, I am a very new to rust and don't know if this is a real issue or my own lack of experience, so I'm reluctant to just change it & open a PR

Top-level crate files are deprecated?

Hi!

I was told by dbaupp in #[email protected] that the .rc top-level crate file is deprecated, when I asked what the difference was between .rs and .rc. Should it still be used, that is for the demo.rc?

(I am new to Rust so I don't know the best practises at the moment)

Error codes

I think we should move from using ~str for errors to some kind of error structure, like IoError. I haven't had a chance yet to look into feasibility of this, but I guess it is worth trying.

Anyway, ~str will have to die eventually, and at least we have to move to StrBuf. I don't think it is necessary right now in order to avoid double work, because it seems that it will be renamed to String, but I believe we need an issue to track it.

Accessing raw pointers in structs

I noticed that many structs wrapping raw pointers to SDL objects (Renderer, Window etc.) publish their raw field. This is highly unsafe - anyone can change them; this is a violation of encapsulation.

As far as I can see, there is no need to modify these pointers after they are assigned to the field, however, they are queried, for example, in rust-sdl2_gfx. Hence I propose making them private and providing raw() accessor methods:

impl<S> Renderer<S> {
    #[inline]
    pub fn raw(&self) -> *ll::SDL_Renderer { self.raw }
}

If it turns out that setting these values after initialization is really needed, we can always introduce corresponding setter, probably marked as unsafe.

Similar thing should be done to owned field, which too is exposed in some structs.

[Windows] Error in cargo build: Could not execute process `make src/sdl2/generated/keycode.rs src/sdl2/generated /scancode.rs`

$ cargo build --verbose
     Running `rustc src\sdl2\lib.rs --crate-name sdl2 --crate-type lib -C metada
ta=sdl2:-:0.0.1:-:file:C:\Users\Austin\Documents\GitHub\rust-sdl2 -C extra-filen
ame=-9e66cf42d0a987a0 --out-dir C:\Users\Austin\Documents\GitHub\rust-sdl2\targe
t -L C:\Users\Austin\Documents\GitHub\rust-sdl2\target -L C:\Users\Austin\Docume
nts\GitHub\rust-sdl2\target\deps -L C:\Users\Austin\Documents\GitHub\rust-sdl2\t
arget\native\sdl2-9e66cf42d0a987a0`
     Running `rustc src\demo\main.rs --crate-name demo --crate-type bin --out-di
r C:\Users\Austin\Documents\GitHub\rust-sdl2\target -L C:\Users\Austin\Documents
\GitHub\rust-sdl2\target -L C:\Users\Austin\Documents\GitHub\rust-sdl2\target\de
ps -L C:\Users\Austin\Documents\GitHub\rust-sdl2\target\native\sdl2-9e66cf42d0a9
87a0`
   Compiling sdl2 v0.0.1 (file:C:\Users\Austin\Documents\GitHub\rust-sdl2)
Could not execute process `make src/sdl2/generated/keycode.rs src/sdl2/generated
/scancode.rs` (status=never executed)

Caused by:
  Could not execute process `make src/sdl2/generated/keycode.rs src/sdl2/generat
ed/scancode.rs` (status=never executed)

Caused by:
  file not found (OS Error 2 (FormatMessageW() returned error 317))

Add rust-empty.mk

By adding Rust-Empty as a separate 'rust-empty.mk', one can build to the same output directory as the other projects in the Piston infrastructure. This will not affect the existing way of building.

Uncapture cursor on drop

If the cursor is captured and you close the window, the cursor remains invisible on OSX until you select another window.

make fails with mingw32-compiled rustc on windows

$ rustc.exe --version
C:\Users\amey\Developer\MinGW\msys\1.0\local\bin\rustc.exe 0.9-pre (5751794 2013
-10-19 05:06:17 -0700)
host: i686-pc-mingw32

$ RUSTC=rustc.exe make
rustc.exe  src/codegen/codegen.rs
src\codegen\branchify.rs:59:0: 66:1 error: macro definitions are not stable enough for use and are subject to change
src\codegen\branchify.rs:59 macro_rules! branchify(
src\codegen\branchify.rs:60     (case sensitive, $($key:expr => $value:ident),*) => (
src\codegen\branchify.rs:61         ::branchify::branchify([$(($key, stringify!($value))),*], true)
src\codegen\branchify.rs:62     );
src\codegen\branchify.rs:63     (case insensitive, $($key:expr => $value:ident),*) => (
src\codegen\branchify.rs:64         branchify([$(($key, stringify!($value))),*],false)
                            ...
src\codegen\branchify.rs:59:0: 66:1 note: add #[feature(macro_rules)] to the crate attributes to enable
src\codegen\branchify.rs:59 macro_rules! branchify(
src\codegen\branchify.rs:60     (case sensitive, $($key:expr => $value:ident),*) => (
src\codegen\branchify.rs:61         ::branchify::branchify([$(($key, stringify!($value))),*], true)
src\codegen\branchify.rs:62     );
src\codegen\branchify.rs:63     (case insensitive, $($key:expr => $value:ident),*) => (
src\codegen\branchify.rs:64         branchify([$(($key, stringify!($value))),*],false)
                            ...
src\codegen\branchify.rs:90:4: 98:6 error: macro definitions are not stable enou gh for use and are subject to change
src\codegen\branchify.rs:90     macro_rules! wf(($($x:tt)*) => ({
src\codegen\branchify.rs:91         let indentstr = " ".repeat(indent * 4);
src\codegen\branchify.rs:92         let s = fmt!($($x)*);
src\codegen\branchify.rs:93         writer.write(indentstr.as_bytes());
src\codegen\branchify.rs:94         writer.write(s.as_bytes());
src\codegen\branchify.rs:95         writer.write(bytes!("\n"));
                            ...
src\codegen\branchify.rs:90:4: 98:6 note: add #[feature(macro_rules)] to the cra te attributes to enable
src\codegen\branchify.rs:90     macro_rules! wf(($($x:tt)*) => ({
src\codegen\branchify.rs:91         let indentstr = " ".repeat(indent * 4);
src\codegen\branchify.rs:92         let s = fmt!($($x)*);
src\codegen\branchify.rs:93         writer.write(indentstr.as_bytes());
src\codegen\branchify.rs:94         writer.write(s.as_bytes());
src\codegen\branchify.rs:95         writer.write(bytes!("\n"));

I added #[feature(macro_rules)] to sdl2.rc, but the error remained unchanged.

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.