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

Author Topic: Render targets  (Read 3876 times)

0 Members and 1 Guest are viewing this topic.

slotdev

  • Sr. Member
  • ****
  • Posts: 385
    • View Profile
Render targets
« on: May 20, 2011, 10:51:42 pm »
Hi

I've been looking at render targets: I need to draw a load of stuff to one "target" or surface, call it what you like, and then just scale that to fit the actual window size.

When I google this, I see the general reply is "use SFML 2".

I have just started using SFML anyway, so my question is simply, am I better just using 2.0 right now? How difficult is moving from 1.6 to 2 ?

Thanks
SFML 2.1

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Render targets
« Reply #1 on: May 20, 2011, 11:30:16 pm »
Why do you need to render first to an offscreen surface? Because if you only need to scale the result, you can do it directly by using a view, no need to render to a separate buffer.
Laurent Gomila - SFML developer

slotdev

  • Sr. Member
  • ****
  • Posts: 385
    • View Profile
Render targets
« Reply #2 on: May 20, 2011, 11:52:41 pm »
Laurent

It's just what I am used to (embedded systems is my background, really) - but I am happy to learn a different way.

Can you point me to some documents to explain how this concept works in SFML?

Thanks
Ed
SFML 2.1

slotdev

  • Sr. Member
  • ****
  • Posts: 385
    • View Profile
Render targets
« Reply #3 on: May 21, 2011, 12:07:37 am »
I should look before I type - found it in the documentation.

Reading it, I am not so sure it's what I need. I have a window which is 1680x1050, for example, but all my graphics are made for 1024x768. So I will be drawing things at 1024x768 but the "view" will be 1680x1050?

The default view is always the size of the window!? Some help is gratefully appreciated :-)

Ed
SFML 2.1

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
Render targets
« Reply #4 on: May 21, 2011, 12:27:53 am »
If you change the view to 1024x768 but don't change the window size, everything will be sized up accordingly, I think. Haven't used view's for scaling.
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

slotdev

  • Sr. Member
  • ****
  • Posts: 385
    • View Profile
Render targets
« Reply #5 on: May 21, 2011, 12:31:55 am »
........and therefore if my window is < 1024x768 it'll scale it down, right?
SFML 2.1

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
Render targets
« Reply #6 on: May 21, 2011, 12:42:25 am »
Think so, I'm not 100% sure, might get the reverse result. Like I've said, haven't used it for that myself.
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Render targets
« Reply #7 on: May 21, 2011, 10:56:31 am »
Yes and yes. Basically the view defines what will be shown in the window. So if the view is 1024x768, you'll see 1024x768 pixels (well, it's more "units of the 2D scene" than pixels) stretched to the size of the window, no matter if it's smaller or bigger.
Laurent Gomila - SFML developer

slotdev

  • Sr. Member
  • ****
  • Posts: 385
    • View Profile
Render targets
« Reply #8 on: May 21, 2011, 10:26:32 pm »
OK, so I have views working. I can zoom stuff up and down, no problem.

Is there a way to change the aspect ratio of the view, if that's the right thing to do? My 1024x768 graphic, when zoomed, is naturally still in 4:3 format!

Doh!

Thanks
Ed
SFML 2.1

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Render targets
« Reply #9 on: May 21, 2011, 10:35:12 pm »
Use SetSize instead of Zoom, this way you have full control on what's displayed.
Laurent Gomila - SFML developer

slotdev

  • Sr. Member
  • ****
  • Posts: 385
    • View Profile
Render targets
« Reply #10 on: May 21, 2011, 10:55:50 pm »
Erm, OK, this is a concept totally new to me, so forgive the stupid questions.

My window is 1600x900, but my graphics are 1024x768, so what is wrong with this approach:

sf::Vector2f Center(512,384);
sf::Vector2f scaledSize(1600,900);
window1View = new View(Center,scaledSize);
window1View->SetHalfSize(512.0f,384.0f);

(excuse the use of "new"...)

This works fine, but I noticed CPU use was quite high (20%) vs 3% on a normal 1024x768 window'd app. My guess is using the SetHalfSize is just doing a ton more calculations every frame...?

Thanks
Ed
SFML 2.1

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Render targets
« Reply #11 on: May 22, 2011, 10:19:38 am »
Quote
Erm, OK, this is a concept totally new to me, so forgive the stupid questions

I don't know why people think it's so complicated. A sf::View is a 2D camera, it defines what you see in the window. Just like in real life ;)

Quote
Code: [Select]
sf::Vector2f Center(512,384);
sf::Vector2f scaledSize(1600,900);
window1View = new View(Center,scaledSize);
window1View->SetHalfSize(512.0f,384.0f);

The second argument of the constructor is the half-size, so basically you just need this:
Code: [Select]
sf::Vector2f Center(512,384);
sf::Vector2f scaledSize(512,384);
window1View = new View(Center,scaledSize);


Quote
(excuse the use of "new"...)

No, and it's even worse because you already know it's wrong ;)

Quote
My guess is using the SetHalfSize is just doing a ton more calculations every frame...?

Not really. But don't care much about CPU, one problem at a time ;)
Laurent Gomila - SFML developer

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
Render targets
« Reply #12 on: May 22, 2011, 05:10:03 pm »
Well the CPU usage depends on the computer you are using. For instance if a game is lagging on a computer you usually take a smaller resolution. I'm not sure but since you are using a such large resolution is probably why the the CPU usage goes up. Though I might be totally wrong as I feel like the scaling should be done at the GPU and should not show an effect on the CPU?

Anyway your question was quite unclear, do you understand the concept? Anyway I'll give my go at explaining it. When we define a Window with the size 1024x768 it is initially created with a view of the same size placed at the coordinates 0,0. The view defines what is being currently viewed on the render target. If we move the view to position -100,-100 a sprite drawn on the position 1000x700 is not viewable any more as it's outside our view(The view is still 1024x768 pixels big). Now let's say we set the size of the view to the double which would be: 2048x1536
This means that the sprite placed at position 1000x700 is viewable again as it's inside the view again. Now how are we going to render this? The view is the double size of the window. Everything can't fit into there. All graphics are scaled down to fit the size of 1024x768 so it fits. The same applies in the opposite way(making the size smaller) except that it will make everything look larger as it's scaled up to fit the size of the window.

I hope that explained the concept without confusing you :)
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

slotdev

  • Sr. Member
  • ****
  • Posts: 385
    • View Profile
Render targets
« Reply #13 on: May 22, 2011, 05:49:16 pm »
Guys, thanks for your help and patience! I think I understand the concept now (coming from an embedded systems background where you have no graphics other than a couple of LEDs :-)) it's all new to me.

The CPU usage is just my system, that was 20% doing 2x 1600x900 @ 30fps but I can fix this myself. I only really need 30fps during some certain times, otherwise 10fps will be more than sufficient.

Anyway, SFML is MUCH better than SDL which I used for many years.

Cheers
Ed
SFML 2.1

 

anything