Sprite bathching with Thor::Bigsprite

[SupanovaHSR]

Hey guys,

A little background first.

We have been using SFML for a small live project of a remake of an old loved game once called HostileSpace,

We remade the client using SFML, and have had no issues thus far.

We built a sprite batcher, which is used for quite a few elements.

The issue we have is the texture size limits and sprite batching.

We would like to avoid splitting our atlases manually, and were wondering is using thor::BigSprite may com in handy.

From what I've read, I can't see a quick fix to use both batching and BigSprite.

Anyone got any pointers, about the logic side of working out where to find our texture, for the vertex being drawn, inside a BigSprite?

[zsbzsb]

Well thor::BigSprite draws multiple different textures by using multiple sf::Sprites offset at different positions. There is no way for you to get access to the internal details of the positioning information. If you want to batch it, what I suggest you do is implement your own big texture/sprite to get access to that information.

You will also need a separate vertex array for each texture. So just do it as before, except make multiple vertex arrays and each array will map to one of the internal sprites.

[Nexus]

Yes, thor::BigSprite can't do this. Sprites are convenience classes to draw simple objects, for more sophisticated needs like batching you'll need vertex arrays.

Do you really need the batching performance-wise? Because having big sprites and batching will require a complicated implementation (find out which sprite parts are used multiple times and render them together) and may lead to surprises (overlapping objects). Don't make your life harder than necessary.

[SupanovaHSR]

Hmm, having read your comments guys, I think I can visualize it a lot better now.

I had just pulled an all nighter coding so was a little fuzzy up top.

Because of the nature of the game (being tile based) and it has a custom font (which is based on an atlas) we felt it wouldn't harm to reduce our 2000+ draw calls to 200+.  Performance wise it probably wasn't that much on our developmental machines, but some of our players do have quite old kit.

We have to keep as many players, playing.  The remake of the game is live and has been for 3 years.  However the SFML client has only been in closed alpha testing the past 3 months....

Having anything from 2 too say 7 draw calls extra. per texture dependent on texture size and maximum supported size, isn't a bad trade off, considering the amount we were pushing.

Cheers guys, have actually been a great help.

[Nexus]

Because of the nature of the game (being tile based) [...] we felt it wouldn't harm to reduce our 2000+ draw calls to 200+.

And each tile is bigger than the hardware texture limit?

If not, just have as much different tiles per texture as possible, and render them as vertex arrays. You may need more than 1 draw call if not all tile types fit into a single texture, but it will be significantly fewer than with sprites.