Add support for Texture Atlases (spritesheets)

[otraore]

• Add TextureAtlas loader to the File Loader based on xml exports from TexturePacker
• Make it the default loader for xml files
• Use a singular ImageLoader object for engo.Files to save memory allocations
• Add Viewport to TextureResource and use it if defined in LoadedSprite(..)
  • Allows the use of the singular sprite sheet texture because singular sprites will be retrieved from the viewport of it

I tried to make it so that users can continue using common.LoadedSprite regardless of if they're using a TextureAtlas or not. This means that the texture is added to the image loader manually and is referenced using the file url for it.

For example: <SubTexture name="enemyGreen1.png" x="425" y="552" width="93" height="84"/>

That sprite can be retrieved using

texture, err := common.LoadedSprite("enemyGreen1.png") even though it wasn't loaded from that location in the file-system but loaded from the singular sprite sheet image defined in the xml file.

Tested using: these files I am open to suggestions

In progress: needs review, tests Closes #707

[github-actions[bot]]

Coverage increased (+1.3%) to 39.202% when pulling 7f6dcd366cc8a23f2c47872989ea36bed1fcd28e on texture-atlas into c76f7316599b705e8a3655640db2c0cb4b71c1b2 on master.

[Noofbiz]

Looks great to me. I think integration with texture packer is awesome. Thanks for the awesome features! Down the road I'm thinking we could add an internal Atlas that spends individual sprites to it, so end users can just have a bunch of pngs and not have to worry about texture packer themselves unless they want to, but that's a lot of work and planning that can be done down the road, if it's even necessary at all lol

[otraore]

You mean like caching all loaded images into a singular Texture internally for performance improvements? If so I don't think that'd work well because the point of the packers are to reduce the size as well. Loading full pngs/jpegs etc will still be at full size. If we were to do the job of packer we'd also try to reduce the size of the images and compress them but at that point there will be image quality loss. I think it's better if we present them both options and let them choose whatever works for them. Let me know what you think.

I made it a goal to keep the same API for loading in singular sprites and entire sprite atlases so that if they decide to use one or the other down the line they only have to change the Load function.

Thank you for the review though, I think I want to add tests for the loader either in this PR or in a separate one (because writing tests is not fun). Hopefully I'll get to it this week and just do it in this one.

[otraore]

Another option for what you want to do would be to use something like this library and have a flag like PackAssets: true in engo.RunOptions which will pack assets for them.

It even support exporting to TexturePacker file format like here

[otraore]

I removed it, I'll see if I can add tests and maybe a demo in another PR.

Thank's for the review.