does it makes sense to have a lot sprites of the same image?

[thoniel]

hi
im trying to do a tilemap right now and i have a lot sprites of the same image to cover the floor.
im used to draw the same image over and over again on different positions.

does it make sense to have for each groundtile one sprite, or should i make one sprite and then draw it. change position, draw it again etc.

i guess visually it would come out the same but in termes of memory the first one may be inefficient.

what do you say?

cheers

Code: [Select]

void MapLayer::Draw(const sf::RenderWindow &window)
{
for(int y=0; y<5; y++) {
for(int x=0; x<4; x++) {
if (grid.at(y).at(x) == 0) {
pSprite->SetPosition(x*32,y*32);
window.Draw(*pSprite);
}
}
}
}

[MrQuizzles]

Sprites are pretty small, and doing things with them is a light operation. You don't much have to worry about it.

The test run for my current project has about 1800 sprites all with the same image, just in different positions, rotations, colors, alpha, etc. moving about the screen, and I can maintain 60FPS easily. It uses, at most, 25% of my CPU (18 of those 25% are spent drawing, the creation of the sprites and all the other handling I'm doing takes up the remaining 7%).


Oh, and I'm also creating and destroying those 1800 sprites each frame. It may seem inefficient, but I wanted to keep any direct references to any of the SFML objects away from my simulation and kept squarely in the graphics bit.

[quasius]

For just messing around, you're not going to run into issues with tons of sprites.
But if you have a large, scrollable map, this could become a problem.  Even with off-screen culling, you could still end up way too many sprites.  In that case, just have one sprite per image and have some loop where you change the position then draw for each on-screen tile of that image.
Another (possibly more efficient) method is to make your own class that directly uses OpenGL to draw the same image over and over at different positions.

[heishe]

having only one sprite that represents all the "tiles" you see on the screen won't increase the performance of your program one bit. you still have to write the same amount of if()'s . ok, it decreases memory usage a bit, but that doesn't matter anyways since sprites themselfs are not big at all. calling methods from different objects doesn't make a single performance difference, look up wikipedia or something how c++ is translated into machine code.

also only having one sprite completely messes up the most design patterns. you should keep the idea of object oriented design (you know, you try to program stuff like you think about it in real life). when you see 20 balls on the ground, do you see 20 different balls or just the same ball that is rendered 20 times?

zoning is better. split up your map into different zones. every zone knows which objects are currently in it. in addition, every zone knows which zone is next to it. it makes sure that objects are correctly translatet between zones.

you just have to make sure that only the zone which the player can currently see is calculated.

of course thats just the standard idea. if you try to program a more complex game or something you'll end up having to adapt this whole idea a lot.

[quasius]

having only one sprite that represents all the "tiles" you see on the screen won't increase the performance of your program one bit. you still have to write the same amount of if()'s . ok, it decreases memory usage a bit, but that doesn't matter anyways since sprites themselfs are not big at all. calling methods from different objects doesn't make a single performance difference, look up wikipedia or something how c++ is translated into machine code.

also only having one sprite completely messes up the most design patterns. you should keep the idea of object oriented design (you know, you try to program stuff like you think about it in real life). when you see 20 balls on the ground, do you see 20 different balls or just the same ball that is rendered 20 times?

zoning is better. split up your map into different zones. every zone knows which objects are currently in it. in addition, every zone knows which zone is next to it. it makes sure that objects are correctly translatet between zones.

you just have to make sure that only the zone which the player can currently see is calculated.

of course thats just the standard idea. if you try to program a more complex game or something you'll end up having to adapt this whole idea a lot.

This is all correct, but that doesn't change the fact that there are certainly cases when you don't want a million sprites of the same image.
There's always a trade-off between CPU and memory.  Usually several sprites is not a problem, but there is certainly an extreme case where the size of a sprite will become significant.
And as for "correct OOP," good game programmers know when OOP paradigms are good for code maintainability and when it's time to throw them out the window because the performance trade-off is too much.  If games were all about making the most beautiful code possible, we wouldn't even be using C++.  Sometimes you optimize the hell out of a critical loop to the point where the code is nearly incomprehensible without an essay in comments, but sometimes that's what you need to do.  Sometimes you declare and calculate on variables in weird orders to optimize for a console's pipelining.  Sometimes it's really, really ugly code.  But it's fast, and ultimately that's what matters.  Also, you can always (and should) comment stuff like this.