I guess a sprite batcher would be pretty nice for Atomic Just Code and would make people coming from XNA/MG feel more at home and also allow them to easily do stuff the way they’re used to.
I think screen space auto-batched (with manual start and end) drawing functions are a good start, in the future maybe we could have some options to allow pixel-perfect drawing so one could use a virtual buffer and draw it on screen (scaled with no ipo) for low-pixel style of games, and also maybe a quadbatcher that culls quads out of some area (maybe even a frustum so you could use for perspective too), but possibly most importantly: provide high performance overloads, for example, if the quad is axis-aligned then pipe it through some native stack that doesn’t calculate the rotation trig stuff, what besides processing would also help minimize unnecessary marshalling from the scripts, so maybe for pixel perfect drawing you could pass just the XY coords and scale is calculated automatically, if you want the sprite center somewhere else, you pass the XY pos and XY offset, and for rotation it’s the same plus a float.
The sprite batcher could work exactly like in XNA, which by default doesn’t use the zbuffer at all, so sprites are always drawn in the order the tris/quads are indexed (for single call) or if there are multiple calls, they’re drawn in the order of the calls, what allows you to sort stuff better without caring about z at all.
There is a public domain sprite batcher for Urho made by IvanK but I’m not sure to what extent it would be useful and it could perform better too.
Should we have a sprite batcher?
- Yes - and I’d benefit from it immediately
- Yes - I could benefit from it occasionally
- No - I won’t benefit from it
Should we make the API similar to the XNA one?
- Yes, I like the XNA API
- No, let’s come up with something better
Should we prioritize ease of use or performance?
- Ease of use: make it as easy and automated as possible
- Performance: make it as fast at the cost of some manual requirements