Pixel - Enhancement Wishlist

[dusk125]

All of the following is up for discussion.

Reworks

• Colors Color refactor #93
• Abstract the backend away (pixel.Window interface)
  • A user can still drop into the backend if they need/want (pixelui), but for normal operations they don't
  • opengl.Run should be replaced with pixel.Run
• Lighten Sprite
• Cleanup the mess that is interface.go; these interfaces should make sense/be understandable
• Change things like pixel.R to be generic so the user doesn't have to be cast happy
  ex)

func R[U,V,W,X constraints.Float|constraints.Integer](minX U, minY V, maxX W, maxY X) Rect {
    return Rect{
        Min: Vec[U, V]{minX, minY},
        Max: Vec[W, X]{maxX, maxY},
    }
}

func V[U, V constraints.Float|constraints.Integer](x U, y V) Vec {
    return Vec{float64(x), float64(y)}
}

• Use standard library pieces where possible (image.Image (image.RGBA) instead of pixel.PictureData
• Try to limit heap allocations (hard due to the use of interfaces)
• Rework batching to be more predictable
• Add an option for flipping the y-axis Should the origin (x=0, y=0) remain in lower-left hand corner? #8
  • I think something funky is going on here with the model-view-projection matrices, I've done opengl stuff and haven't had to flip images when displaying them like Pixel does.
• WASM support / validation

Features

• Instancing (will need support in glhf)
• Bring an texture atlas implementation into pixel.core? Adding a texture atlas extension #103
• Setting targetFPS and allow Pixel to handle the update and sleep
• Expose view matrix for easier camera implementation
• Text interface to abstract TTF and bitmap fonts
• Mouse cursor change support Adding support for manipulating cursors #114

[duysqubix]

Are these a collection of thoughts an ideas for enhancements or are they all related?

[dusk125]

Collection of thoughts, originally meant for v3, but some/most of them will likely be able to be done with the need for a major release.
Could think of this as an Epic if you want :D

[bhperry]

Make Anchor more intuitive

The current rationale is that pixel.BottomLeft will anchor text/whatever such that it appears to the bottom-left of the anchor. Or in other words... it is anchored to the top right.

The original design from the PR that introduced anchoring was the opposite, but they switched it before the final merge. This seems far more intuitive to me though. The anchor should describe the point at which the text is anchored, not the direction in which the text will flow.

Original PR faiface/pixel#252