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

Author Topic: parallax scrolling and sf::View.Viewport  (Read 3175 times)

0 Members and 1 Guest are viewing this topic.

ChonDee

  • Jr. Member
  • **
  • Posts: 62
    • View Profile
parallax scrolling and sf::View.Viewport
« on: April 06, 2012, 07:36:51 am »
I am working on a 2d scrolling shooter, everything in the gameplay is happening in one "layer", and other decorative stuff, like stars in the background, or dust/debris in the foreground are in different layers, each object has a parallax multiplier, 1.0 as default, 0.+ for slowly moving background objects and 1.+ for in front of foreground ones.

Currently the way I have everything implemented is that everything has a default non-zero velocity (even static non-moving objects) accounted just for scrolling, which I would rather change, to take advantage of viewport, which in my understanding would be a better thing to serve as camera.

Using the viewport would be very straightforward if there is no fake depth added by parallax layers.
I am not sure how expensive it is to call  sf::View.SetViewport(), depending on that I am thinking about doing one of the following:

1. if not expensive at all: for every object with a non-default parallax multiplier, during the render I set the viewport according to the objects parallax multiplier and when done set it back to default (there around 500-800 objects with parallax multipliers that need to be drawn each frame)

2. if it is somewhat expensive instead of using any random float 1.f-3.f for parallax multiplier I would instead use a few 10-20 "layers", each with its own parallax multiplier, and objects on the same layer will be grouped together (at least as a bunch of pointers to each on the same layer to be used in the same loop when they are rendered) so the viewport is only set once for each layer.

3. should I not use viewport at all, and go with my own implementation? (doesn't seem like a good idea..) should I do it in some other way than what I thought of above?

Your assistance on this would be much appreciated,
Thanks in advance

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: parallax scrolling and sf::View.Viewport
« Reply #1 on: April 06, 2012, 09:42:04 am »
Sorry, I don't get it. I can't see how the viewport could help implementing parallax scrolling. The view itself could be useful, but not its viewport.

And if every object has a different velocity, it would definitely be overkill to setup a view for each one.

Or maybe I totally missed your point :)
Laurent Gomila - SFML developer

ChonDee

  • Jr. Member
  • **
  • Posts: 62
    • View Profile
Re: parallax scrolling and sf::View.Viewport
« Reply #2 on: April 06, 2012, 09:51:51 am »
You're right, it's the view I meant to change for each object, not the viewport.
So it just comes down to:
Is it expensive to change the view lots of times each frame?

Or would you have some suggestion on how else to implement parallax scrolling?
« Last Edit: April 06, 2012, 09:55:38 am by ChonDee »

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: parallax scrolling and sf::View.Viewport
« Reply #3 on: April 06, 2012, 12:45:02 pm »
Quote
Is it expensive to change the view lots of times each frame?
It depends, can be cheap or expensive depending on your hardware, and on the number of views that you use.

But what's the point of using views if each entity has its own scrolling factor? Can't you just move them accordingly, and that's it?
Laurent Gomila - SFML developer

ChonDee

  • Jr. Member
  • **
  • Posts: 62
    • View Profile
Re: parallax scrolling and sf::View.Viewport
« Reply #4 on: April 06, 2012, 08:03:28 pm »
I see.
I figured maybe I could have like 10 possible parallax layers, that way each object on the same layer would get rendered the same time, so the view would be changed only 10times per frame.

I just wanted to keep the object's actual position and velocity separate from the position and apparent velocity due to camera position/movement. So if a star is not actually moving it would have been nice to not have to change its position/velocity only because the camera is moving.

But yes, that is how I currently have them implemented that I actually move them according to their parallax factor.