Is there any advantage in having one Sprite to rule them all?

[C with a C]

If you take a Sprite and draw it, then change its position and draw it again (in the same loop), you can draw it as many times as you want on the screen. Obviously you can change the position of its texture rectangle as well, if you need it to draw different tiles from a tileset.

I'm curious as to whether this could have any kind of benefit/advantage over having multiple Sprites, or if there's any real practical application for it (I used it in a few prototypes, like Conway's Game of Life and some sort of roguelike-like-ish thing I did).

[DarkRoku12]

Only in impractical demos, you could reduce memory usage, but you will mess up your draw cycle and events processing.

Example:

window.clear()

window.draw( sprite )

/* change sprite position, textures, rotation , color
    bla bla bla bla time spent.
*/

window.draw( sprite )

/* change sprite position, textures, rotation , color
    bla bla bla bla time spent. Again....
*/

window.draw( sprite )
// Repeat....


window.display()

 

Probably you can end messing up your framerate and end having a lot of bugs on your game that might be very difficult to track.

[C with a C]

I think I can see what you mean.

The thing with both of those games in which I used this was that they used a sort of a rendering delegate, that stored everything in a tilemap, and then made all of the game's draw() calls in one single loop. I did this "trick" more out of convenience and lazyness than anything else. Didn't even think to ask around first.

In these cases I wouldn't think I was running a great risk of anything, but then I'm no expert. I didn't make any tests for performance or anything else (I don't really know how to test that stuff anyway, besides observing frame rates...), and I wouldn't be able to tell if the problems I had could've been caused by this.

[eXpl0it3r]

If you start to draw a lot of sprites, it might be better to start using a vertex array. Otherwise there isn't really anything wrong with adjusting one sprite. However if change every sprite to some "static" values, you'd be better of defining all these "static" sprites and not do x redundant function calls.

[C with a C]

Wouldn't the number of calls be the same? As they'll have to make a draw call each anyway. Unless what you're thinking is about gathering them in some way and thus making less calls?

I'm probably missing something. There are still many things I don't know about or have only barely heard of (such as sprite batching).

[eXpl0it3r]

I meant if you have x sprites that never change, it would be redundant to keep setting the properties ever frame.
In the end it doesn't really matter how you do it. Just pick a way and implement it.

[C with a C]

I meant if you have x sprites that never change, it would be redundant to keep setting the properties ever frame.

Ah yes. Wasn't thinking of that.

Now that I think about it, having to be changing the properties during the drawing seems like mixing logic with rendering...