Fix for SpriteSheetComponents + TextComponents Crash

[insrcd]

This PR was a result of me working around #134. I have been using it successfully since 0.1.0 and confirmed the issue still exists in 0.2.x.

The issue stems from the UI text using the same pipeline as the SpriteSheet and DrawableText setting the rendering pipeline specifics when the text is drawn instead of relying on a dynamic pipeline bindings.

A few caveats, I'm new to rust, and to rendering pipelines in general, so this may not be the best approach. I just wanted to get my game (/~https://github.com/insrcd/labyrinth-game) to be able to show text and sprites at the same time.

I'd love to hear feedback on how to improve this, or if my approach is just plain ol' wrong, I'd love to learn more about how to address it.

[ConnorBP]

This compiles for me, however the result displays the text properly and the sprite no longer renders at all. May just be me though. Anyone else tried this?
edit: I am on MaxOs. This may be related.

[ConnorBP]

Adding in the z depth on my spritesheet transform fixed (workaround) the sprite render issue on macOS machines. Once zdepth starts working by default, I personally think this patch is ready to merge and should be. Up to the repo owner though. For now I will keep developing on this branch until they do. Thanks very much for your work in resolving this issue! 😃

[ConnorBP]

You should fix the CI / clean check (clippy error)

error: unused import: `TextureAtlasSprite`
244
  --> crates/bevy_text/src/draw.rs:16:57
245
   |
246
16 | use bevy_sprite::{TextTextureAtlasSprite, TextureAtlas, TextureAtlasSprite};
247
   |                                                         ^^^^^^^^^^^^^^^^^^
248
   |
249

[cart]

I'm investigating the issue now. This is quite weird because we are already creating two "different" pipelines, one with dynamic bindings and one without. (by using bevy's "pipeline specialization" system).

This almost feels like a bug in wgpu where its getting confused about dynamic bindings.

In general creating full copies of all relevant assets shouldn't be necessary. The "pipeline specialization" code we have already should be solving this problem for us. I'll take some time to see if theres anything obvious. If not, I'll try getting a repro using a wgpu example.

We might need to hack around this in the short term, but I think we can do it in a way that doesnt explicitly create new assets.

[cart]

Found the root cause. Its a one line fix.

Closing in favor of #560

(this was definitely my fault 😄)