
This implements the following: * **Sprite Batching**: Collects sprites in a vertex buffer to draw many sprites with a single draw call. Sprites are batched by their `Handle<Image>` within a specific z-level. When possible, sprites are opportunistically batched _across_ z-levels (when no sprites with a different texture exist between two sprites with the same texture on different z levels). With these changes, I can now get ~130,000 sprites at 60fps on the `bevymark_pipelined` example. * **Sprite Color Tints**: The `Sprite` type now has a `color` field. Non-white color tints result in a specialized render pipeline that passes the color in as a vertex attribute. I chose to specialize this because passing vertex colors has a measurable price (without colors I get ~130,000 sprites on bevymark, with colors I get ~100,000 sprites). "Colored" sprites cannot be batched with "uncolored" sprites, but I think this is fine because the chance of a "colored" sprite needing to batch with other "colored" sprites is generally probably way higher than an "uncolored" sprite needing to batch with a "colored" sprite. * **Sprite Flipping**: Sprites can be flipped on their x or y axis using `Sprite::flip_x` and `Sprite::flip_y`. This is also true for `TextureAtlasSprite`. * **Simpler BufferVec/UniformVec/DynamicUniformVec Clearing**: improved the clearing interface by removing the need to know the size of the final buffer at the initial clear.  Note that this moves sprites away from entity-driven rendering and back to extracted lists. We _could_ use entities here, but it necessitates that an intermediate list is allocated / populated to collect and sort extracted sprites. This redundant copy, combined with the normal overhead of spawning extracted sprite entities, brings bevymark down to ~80,000 sprites at 60fps. I think making sprites a bit more fixed (by default) is worth it. I view this as acceptable because batching makes normal entity-driven rendering pretty useless anyway (and we would want to batch most custom materials too). We can still support custom shaders with custom bindings, we'll just need to define a specific interface for it.
19 lines
573 B
Rust
19 lines
573 B
Rust
use bevy_math::Vec2;
|
|
use bevy_reflect::{Reflect, TypeUuid};
|
|
use bevy_render2::color::Color;
|
|
|
|
#[derive(Debug, Default, Clone, TypeUuid, Reflect)]
|
|
#[uuid = "7233c597-ccfa-411f-bd59-9af349432ada"]
|
|
#[repr(C)]
|
|
pub struct Sprite {
|
|
/// The sprite's color tint
|
|
pub color: Color,
|
|
/// Flip the sprite along the X axis
|
|
pub flip_x: bool,
|
|
/// Flip the sprite along the Y axis
|
|
pub flip_y: bool,
|
|
/// An optional custom size for the sprite that will be used when rendering, instead of the size
|
|
/// of the sprite's image
|
|
pub custom_size: Option<Vec2>,
|
|
}
|