3

All the examples I've seen for getting access to a texture object is to do something like the following:

let img = Texture::from_path(...)

This gives the impression that in order to have an array of textures it should be something like let mut images: Vec<Texture>;, but from_path returns a Result<Texture<R>, String>.

And its the Texture<R> that is really getting in the way. In order to be able make a Texture<R>, an awful lot of crates and use ... are needed and it feels completely wrong.

Is the right thing:

let loaded_textures:Vec<Option<T>> = Texture::from_path(...)

Or pull in almost everything that Piston has? Or something else?

My goal is to have

struct Drawables {
    obj_name: &'static str,
    image: Texture<gfx_device_gl::Resources>, // or something else
}

let mut my_objects: Vec<Drawable>;

fn LoadDrawables(window: &mut PistonWindow) -> Vec<Drawable> {
    let assets = find_folder::Search::ParentsThenKids(3, 3)
        .for_folder("assets")
        .unwrap();
    let img1 = assets.join("some_img0.png");
    let img1 = Texture::from_path(
        &mut window.factory,
        &img1,
        Flip::None,
        &TextureSettings::new(),
    ).unwrap();
    let img2 = assets.join("some_img1.png");
    let img2 = Texture::from_path(
        &mut window.factory,
        &img2,
        Flip::None,
        &TextureSettings::new(),
    ).unwrap();
    vec![
        Drawable {
            obj_name: "orc",
            image: rogue,
        },
        Drawable {
            obj_name: "bat",
            image: floor,
        },
    ]
}

The crate I'm trying to avoid pulling in is gfx_device_gl. This create feels wrong to include, its seems a little to low level if I'm already including a game engine such as Piston.

Shepmaster
  • 388,571
  • 95
  • 1,107
  • 1,366
tamato
  • 838
  • 7
  • 15
  • 2
    I have *no idea* what you are really trying to ask. Yes, a `Vec` is a great way of storing a collection of things. A `HashMap` is also a great way of storing a collection of things; there are lots of available collections (in the standard library and outside). You then mention `Result` and the fact that you have to use crates and use statements but not why any of those present problems for you. Why do you think you have to "pull in almost everything that Piston has"? – Shepmaster Sep 28 '17 at 16:12
  • Do you want to create a vec (or a hashmap) of textures from a vec of paths? – Boiethios Sep 28 '17 at 16:16
  • What are all the imports? From what I can tell, you can obtain the `Factory` impl from the `PistonWindow`, which you must already have. Then there are two new imports: `TextureSettings` and `Flip`, which both can be constructed with no other dependencies. – Peter Hall Sep 28 '17 at 16:22

1 Answers1

2

You probably want to map over a collection of paths and create a texture for each. When collecting on an iterator of Results you can have them unwrapped and move the result to the outside of the final collection:

let images: Result<Vec<Texture<_>>, String> = paths.iter()
    .map(|path| Texture::from_path(
            &mut *window.factory.borrow_mut(),
            &path,
            Flip::None,
            &TextureSettings::new())
    )
    .collect();

You shouldn't need the R parameter for Texture<R> because it can be inferred from the Factory<R> instance that you get from PistonWindow, which is why I just put a _. In fact, you can reduce the type of images to just Result<Vec<_>> if you wanted to, as even that can be inferred.

Disclaimer: I wasn't able to actually run this code where I am. But it should only need small changes if it doesn't work.

Peter Hall
  • 53,120
  • 14
  • 139
  • 204