Flatten tiles to vec u32

[satrix321]

Hi,
This change flattens the tiles from a layer into a structure containing Vec (instead of Vec<Vec>) for performance concerns. There's also a method provided for easy conversion to Vec<Vec> if there would be need for it.

As of now this is a breaking change, but with some minor adjustments users would still be able to iterate over this collection by rows (by using tiles_per_row and number_of_rows). I'm open to any suggestions how we could smooth this out a bit more.

[mattyhall]

Sorry for the delay, I'll try and look at this at the weekend!

[mattyhall]

Sorry for the delay again. Life got in the way I'm afraid :(

It looks good. I'm not too bothered about the breaking version as we're still <1.0 (and I doubt anyone is seriously using the library) but maybe we could add a conversion from TilesContainer to Vec<Vec<_>>

[satrix321]

Hey, I've tried looking into this conversion, and it seems to me that we could add a generic one for Vec<Vec>, but it will require a wrapper struct to work properly. Something along those lines:

struct TilesContainerWrapper<T>(Vec<Vec<T>>);
impl<T> From<&TilesContainer> for TilesContainerWrapper<T> where T: std::convert::TryFrom<u32> {
    fn from(item: &TilesContainer) -> TilesContainerWrapper<T> {
        let mut data: Vec<Vec<T>> = Vec::new();
        let tiles_per_row = item.tiles_per_row as usize;
        let number_of_rows = item.number_of_rows as usize;
        for x in 0..number_of_rows {
            let start_index = x * tiles_per_row;
            let end_index = start_index + tiles_per_row;
            let row: Vec<T> = (&item.data[start_index..end_index])
                .iter()
                .cloned()
                .map(|e| T::try_from(e).ok().unwrap())
                .collect();
            data.push(row);
        }
        TilesContainerWrapper(data)
    }
}

I'm not exactly sure if this is something desirable in this case. We could just go with implementing the conversion manually for all built in numeric types, but it would produce a lot of boilerplate code. I'm open to any suggestions on how we could improve this solution.

[bjorn]

@satrix321 This seems like a good change to make. Would you still be able to rebase this change to resolve the conflicts? I've also left some comments.

[bjorn]

Maybe just width and height would do as property names?

[bjorn]

I don't think we need this converter. What use would people have for converting to this sub-optimal data structure? Maybe instead it could be useful to provide a getter to retrieve a tile given x and y coordinates?

[aleokdev]

Could this be initialized with correct data from the start? I feel like this could lead to invalid states where the tiles member never got initialized.

[aleokdev]

I think trim after split would work here.

[bjorn]

Superseded by #128.