Add ggez example

[PieKing1215]

Adds a rendering demo for ggez. Supports multiple layers, multiple tilesets, and parallax. Also draws basic shape objects.

You can middle mouse + drag to pan around and scroll to zoom. Right click also toggles a demo animation that makes the tiles move around.

It has pretty good performance because it uses ggez's SpriteBatches for tile rendering. It could be better by caching and reusing the batches but I figured I'd leave that out to simplify a bit.

I made a nicer example map for testing locally but I'll make a separate PR for that I think. Since the current example map is large and mostly empty, and this centers it in the window at the start, you need to zoom out or pan in order to see it (the other nicer map has a more reasonable size).

(this does not properly hook into ggez's filesystem for loading external tilesets/images as that would still require something like #100 I believe)

This could probably still use a bit more clean up and commenting

related: #134

[bjorn]

It did not compile for me:

error: there is no argument named `fps`
  --> examples/ggez/main.rs:83:49
   |
83 |         let text = graphics::Text::new(format!("{fps:.0} fps"));
   |                                                 ^^^^^^^^

error: could not compile `tiled` due to previous error

Also, seems like we need to add libasound2-dev and libudev-dev to the apt install command.

[PieKing1215]

error: there is no argument named fps

I just changed it so it should compile on older rust versions (that feature was only just added in rust 1.58)

[PieKing1215]

Cleaned up some of the easy stuff, still some organization and structural things left to do, and I still need to merge master into here again

[bjorn]

I've merged master and fixed the compile, and also adjusted main.rs to use the new Loader class. However, for me this example is currently just displaying a magic pink window. Any idea why I'm no longer seeing the map?

@PieKing1215 Do you think you could find some time to finalize this example? I think it'd be really nice to have this merged, and it would eventually also be able to demonstrate the VFS support that has been merged for 0.11 (#199).

[bjorn]

@aleokdev It appears the clippy check needs also the dependencies installed. Maybe it would make sense to merge it with the build check?

[aleokdev]

The CI deps can be added in this PR as they're needed by this example. Is that what you're referring to? I'm not sure if I understood you.

[bjorn]

The CI deps can be added in this PR as they're needed by this example. Is that what you're referring to? I'm not sure if I understood you.

I just mean that it's somewhat annoying if we need to install the dependencies in two places in the workflow, just because the build and clippy checks happen on separate virtual machines. It might be better to just perform those checks at two separate steps on the same machine.

[aleokdev]

Oh, sure, that makes sense. However, I'd like for them to be treated as separate checks so that we can see at a glance what's wrong. Is that possible?

[bjorn]

Oh, sure, that makes sense. However, I'd like for them to be treated as separate checks so that we can see at a glance what's wrong. Is that possible?

I agree that would be nice, but I have no idea whether this is possible. Maybe it can be done with this github-checks action.

[PieKing1215]

@PieKing1215 Do you think you could find some time to finalize this example? I think it'd be really nice to have this merged, and it would eventually also be able to demonstrate the VFS support that has been merged for 0.11 (#199).

Yeah sorry about the lack of progress on this, I've been particularly busy recently but I should be able to dedicate some time to adding the rest of the suggested things. (Thanks for merging master btw)

However, for me this example is currently just displaying a magic pink window. Any idea why I'm no longer seeing the map?

Did you try zooming out? It centers the map at the start but the test map's size is way too big and mostly empty so you can't see anything without zooming/panning (should probably fix this)

[bjorn]

Did you try zooming out? It centers the map at the start but the test map's size is way too big and mostly empty so you can't see anything without zooming/panning (should probably fix this)

Heh, it had been a while since I had run this example, and I had just forgotten about the need to zoom out, whoops! But yes, that should definitely be fixed.

[PieKing1215]

The main things I can think of that are unsupported in this right now are:

• Tile objects
• Infinite maps
• ImageLayer
• GroupLayer

I plan on doing tile objects already, but I'm not sure about the other stuff. Idk how all-encompassing we want this example to be. Also should I do VFS in this PR (and change base branch to 0.11) or leave that for the future?

[bjorn]

I plan on doing tile objects already, but I'm not sure about the other stuff. Idk how all-encompassing we want this example to be.

I think tile objects would be good to cover, but the other stuff is not so important.

Also should I do VFS in this PR (and change base branch to 0.11) or leave that for the future?

I would suggest to target 0.10 first and update the example after merging it to 0.11, unless the lack of using VFS is really setting a bad example and we'd rather want to wait till 0.11 to show how to use this crate with ggez at all.

[aleokdev]

I'd target 0.11 to be honest, VFS is a huge deal with ggez (Plus 0.11's interface is basically finished at this point)

[aleokdev]

Should we base this on 0.11 then?

[bjorn]

@aleokdev It's fine with me too.

[aleokdev]

@PieKing1215 I'm basing this onto 0.11 then; You'll be able to use custom loaders now. My platformer template repo has an example of their usage:

// Need to do newtype to implement ResourceReader for ggez's filesystem
// FIXME: This would greatly improve with separated subcontexts (ggez 0.8.0)
pub struct FsContext<'ctx>(pub &'ctx mut ggez::Context);

impl tiled::ResourceReader for FsContext<'_> {
    type Resource = filesystem::File;

    type Error = GameError;

    fn read_from(
        &mut self,
        path: &std::path::Path,
    ) -> std::result::Result<Self::Resource, Self::Error> {
        filesystem::open(&self.0, path)
    }
}

Then you can simply

let mut loader = tiled::Loader::with_cache_and_reader(
     tiled::DefaultResourceCache::new(),
     FsContext(ctx),
);

And not worry about paths anymore. When tiled needs to load any supplementary data, it'll use ggez's filesystem to do so.

[PieKing1215]

Cool, I'll take a look later then.