Can you tell me more about your "unrealistic situation"
My game is essentially a card game(like a TCG in some ways) with a board and dices. So each player has a deck and a hand.
Now, the decks on my game are unusually big. They can go over 100 cards. And, because of how the game works, the player will typically end up having different paradigms over the game. This of course means the deck has to offer a wide variety of cards, very useful in some cases and completely worthless in others.
As a consequence, the "hand" of a player will tend to get very big. How big? I don't know. I probably will only find out on near-final versions of the game.
The framerate problem seems to be more serious the more cards I have in my hand and the more "filled" the board is. Also, the zooming level of the board also seems to have some effect. Probably because I try to avoid drawing tiles that aren't visible.
At around 10 cards in hand, the framerate is between 30-50FPS, which is perfectly fine.
At around 50 cards, the framerate is between 15-25 FPS.
As the number of cards nears the 100, the framerate is having trouble going above 15FPS.
I say unrealistic because I understand that the player will rarely have that many cards on his/her hands, but I suppose it's possible.
Also, this is on *my* computer, maybe slower systems will perform worse. And this is a WIP, so the final game may have a few more stuff that will slow the game further(you know, eye candy and stuff)
One thing I admit is that these cards in the hand are partially hidden,(by the other cards) and I could do a much better job at not drawing the parts that won't be visible, though that certainly would prevent me from doing translucent cards(which I probably won't do anyway).
I certainly would like to go lazy and have SFML detect and handle this automatically
Also, not sure how much this matters, but my game textures have pretty good resolutions. The smallest textures have 64x64 and some ones go up to 256x384. While in some cases I admit I didn't really need so much resolution, the fact is this game looks really neat compared to my previous "pixelated" projects because of that. In the final version, I guess I could reduce the resolution in some cases(such as 64x64 images that always get rendered as 24x24), if that would significantly improve the framerates.
It should be ready soon.
I like collecting unusual use cases, to make sure that the new API is flexible enough.
Good to hear. Great fan of SFML and I recently had to tell someone I know to stick with SDL+SDL additions because of something the SFML 2D drawing API doesn't seem to support(at least not that I know of). Having a more flexible API would pretty mean I'd never have to do that again.
That project was a pseudo-3D game that relied on stuff like stretching textures at runtime, which AFAIK SFML doesn't currently support in its Sprite API.
