Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Speeding up rendering  (Read 4802 times)

0 Members and 1 Guest are viewing this topic.

luiscubal

  • Jr. Member
  • **
  • Posts: 58
    • View Profile
Speeding up rendering
« on: September 05, 2011, 09:31:42 pm »
I'm using SFML 2(.NET) and my game is in some cases a bit too slow. In some admittedly not very realistic - although certainly possible -situations, the framerate actually goes below 20FPS and I would like to speed things up.

So I decided to do some profiling and I got to the conclusion that most of the elapsed time is spent on RenderWindow.Draw and RenderWindow.Display.
My profiler is suggesting that 37% of the time on my main thread is spent on RenderWindow.Display alone. And at least 29% of the total time(probably more since I didn't finish counting and I rounded the number down on a few calculations) is spent on RenderWindow.Draw.
The system monitor shows one of my CPU cores is very busy, so I guess my bottleneck is more specifically the software side of these functions, but to be honest I'm on an Intel system with OpenGL<2.0 so I'm not even sure my OpenGL is hardware accelerated. But even considering my hardware situation, I still think this is kind of slow.

So I was wondering, is there anything I can do aside from reducing the number of drawing calls to speed things up?

Richy19

  • Full Member
  • ***
  • Posts: 190
    • View Profile
Speeding up rendering
« Reply #1 on: September 05, 2011, 09:40:57 pm »
Once the new drawing API is finished for SFML2 then it should all go much faster, not sure ow much more laurent has untill its finished, hopefuly he can give us a hint?

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Speeding up rendering
« Reply #2 on: September 05, 2011, 10:19:58 pm »
It should be ready soon.

Can you tell me more about your "unrealistic situation"? I like collecting unusual use cases, to make sure that the new API is flexible enough.
Laurent Gomila - SFML developer

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10801
    • View Profile
    • development blog
    • Email
Speeding up rendering
« Reply #3 on: September 06, 2011, 12:24:53 am »
Quote from: "Laurent"
It should be ready soon.


Great to hear!  :D
...or not, since we'll have to change a lot. :wink:
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

luiscubal

  • Jr. Member
  • **
  • Posts: 58
    • View Profile
Speeding up rendering
« Reply #4 on: September 06, 2011, 05:01:27 am »
Quote
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.

Quote
It should be ready soon.

Quote
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.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Speeding up rendering
« Reply #5 on: September 06, 2011, 07:56:56 am »
So your game is slow because you're drawing 100 cards? How do you draw a card? If it's just a single sprite, then it's really slow :?
Laurent Gomila - SFML developer

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10801
    • View Profile
    • development blog
    • Email
Speeding up rendering
« Reply #6 on: September 06, 2011, 10:04:42 am »
It's probably a stupid question, but just in case:
Do you have VSync disabled? Since it will limit the whole main-loop to about ~60FPS, so every logical thing that you do will eat up from those FPS. So your PC will wait a long time and then try to fit everything into those few milliseconds.  :wink:
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Speeding up rendering
« Reply #7 on: September 06, 2011, 10:31:39 am »
Another stupid question: make sure that you run in release mode.

Quote
Do you have VSync disabled? Since it will limit the whole main-loop to about ~60FPS, so every logical thing that you do will eat up from those FPS

This is not true, the window will wait only if your logic took less than 1/60 ms to execute, and it will wait only for the remaining time. If your logic takes more time to execute, v-sync will wait less milliseconds.
Laurent Gomila - SFML developer

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10801
    • View Profile
    • development blog
    • Email
Speeding up rendering
« Reply #8 on: September 06, 2011, 10:42:59 am »
Ah okay, sounds logical.  :lol:
Does SetFramerateLimit() act the same way?
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Speeding up rendering
« Reply #9 on: September 06, 2011, 10:47:23 am »
Quote
Does SetFramerateLimit() act the same way?

Yes.
Laurent Gomila - SFML developer

luiscubal

  • Jr. Member
  • **
  • Posts: 58
    • View Profile
Speeding up rendering
« Reply #10 on: September 06, 2011, 03:57:12 pm »
No VSync, no framerate limit. Eventually, I might enable those if I see the need, but not for now.

Quote

If it's just a single sprite, then it's really slow


No. Each card has several draws associated.
Typically, a card will have at least 4 sprite draws, sometimes as many as 10, plus a few text draws(usually at least 6 text draws per card)

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Speeding up rendering
« Reply #11 on: September 06, 2011, 04:21:28 pm »
If the contents are static, you could generate one single sprite from all these sub-components and then have one simple draw per card.

The new API should allow you to merge all the sprites into a single graphical entity (so it would be as cheap as one sprite), but not the texts. But this is the "geometry-based" solution, the "texture-based" one (drawing everything to a texture) would still work anyway.
Laurent Gomila - SFML developer

luiscubal

  • Jr. Member
  • **
  • Posts: 58
    • View Profile
Speeding up rendering
« Reply #12 on: September 06, 2011, 04:34:29 pm »
I don't think my lame Intel GPU supports RenderTexture.

Also, I thought text drawing was essentially a combination of multiple sprite drawings in SFML. So how come that wouldn't work with text?

Even so, I suppose about half of my rendering time is spent on sprites, and another half on text. If the framerate doubled, I guess I would be pretty satisfied. So either way, it is a significant improvement.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Speeding up rendering
« Reply #13 on: September 06, 2011, 04:52:43 pm »
Quote
I don't think my lame Intel GPU supports RenderTexture.

Everything supports RenderTexture. But yeah, Intel GPUs usually have several bugs with them.

Quote
Also, I thought text drawing was essentially a combination of multiple sprite drawings in SFML. So how come that wouldn't work with text?

It's more a design issue than a technical one, in fact.
Laurent Gomila - SFML developer

luiscubal

  • Jr. Member
  • **
  • Posts: 58
    • View Profile
Speeding up rendering
« Reply #14 on: September 06, 2011, 09:45:02 pm »
You're right. I just checked and it does work. I was under the impression that it required FBO to work but it seems that's just not the case.

I'll see if I can accelerate the game with RenderTextures.

EDIT:
Ok, so RenderTextures work but the results are kind of buggy. While I can have my cards appear on screen and due to heavily caching achieve good framerates(at very least comparable to the ones I had, possibly better), the game becomes much less stable.
My idea is to generate card textures as new cards show up. This works fine, ensuring each card texture is only generated when needed, no redundant copies, etc.
However, every time I generate a new card texture, there's a chance the rendering will stop working. In that case, sometimes resizing the window helps restoring the game to its working state(and the cards appear correcty rendered), other times the game just ends up a completely black window.

In addition, if even one single card has been generated(therefore one RenderTexture has been created), when the game closes, it crashes.

Am I doing something wrong or is this one of those Intel bugs?
One thing that may perhaps be worth noting is that I'm having is RenderWindow.Draw calls, then RenderTexture.Draw, and then RenderWindow.Draw back again. Not sure if that makes a difference.

Here's my code:
Code: [Select]

        public void GenerateCardTexture(GameContext info, CardType card)
        {
            RenderTexture t = new RenderTexture(256, 384);

            t.Clear(new Color(0, 0, 0, 0));

            //Some rendering instructions come here.

            t.Display();

            cardRendering[card] = new Texture(t.Texture);
            t.Dispose();
        }

 

anything