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

Author Topic: Views, Viewports, and Endless Parallax Backgrounds  (Read 2282 times)

0 Members and 1 Guest are viewing this topic.

Prometheus

  • Newbie
  • *
  • Posts: 5
    • View Profile
Views, Viewports, and Endless Parallax Backgrounds
« on: May 09, 2014, 07:05:27 am »
Hey, guys.

I'm working on a 2D space-sim game. There are a bunch of background elements: stars made of vertices and allocated in a VertexArray, large images for nebulas, and so on.

I'm looking for a way to get the background to loop around on itself -- in other words, once you hit the edge of the game world, instead of flying off into uncharted territory, you continue along the other side none the wiser.

I thought of a few ways of implementing this, the seeming simplest of which incorporated sf::Views and viewports. Each parallax layer would have its own view so objects could be moved at varying speeds, and when the player approached an edge, the active view's viewport would shrink and a new view's viewport from the opposite side of the map would grow to fill in the blanks.

I had more or less finished this sort of implementation before I realized that I would have to draw all of my background elements multiple times (once for each view). I can't think of any way to limit the background objects to those within a given view, since there are just so many vertices in my VertexArrays: the game slowed to a crawl when I last tried.

I can post what I've got, but first I figured I would ask about my methodology before cluttering this post with code. Is what I'm trying to do feasible (and then not entirely illogical), or is there some better way that I haven't come up with yet?

Thanks for reading through my post. Let me know what you think!

Ixrec

  • Hero Member
  • *****
  • Posts: 1241
    • View Profile
    • Email
Re: Views, Viewports, and Endless Parallax Backgrounds
« Reply #1 on: May 09, 2014, 07:56:11 am »
It sounds perfectly sensible to me.  In fact I don't understand how this didn't work; why do you have to draw all your background elements multiple times?  Surely the background elements only need to be in the background view(s) and the foreground elements in the foreground view(s), right? (assuming a simple two-layer parallax)

Or are you asking about how to cull the background/foreground objects that aren't currently visible in *any* view, so you don't waste time trying to draw them in the first place?  If so I *think* the simplest way is to split up your universe into a grid so that you can simply check the current position and then draw at most four squares in the grid at any given time.


Seeing a minimal version of the code you have would probably help.

fallahn

  • Sr. Member
  • ****
  • Posts: 498
  • Buns.
    • View Profile
    • Trederia
Re: Views, Viewports, and Endless Parallax Backgrounds
« Reply #2 on: May 09, 2014, 10:54:52 am »
I made a star field with vertex arrays a while back. I used a single view for rendering the star field which effectively stayed where it is, and wrapped the stars by moving them to the other side of the view once they exited. Then I drew the game on top using separate views for each player. Here's a video:



and the source for the star field (actually taken from another project, but based on the same class).

Prometheus

  • Newbie
  • *
  • Posts: 5
    • View Profile
Re: Views, Viewports, and Endless Parallax Backgrounds
« Reply #3 on: May 09, 2014, 05:16:57 pm »
Thanks for the quick responses, guys.

I went with that sort of implementation a while ago fallahn, but it's no longer feasible with how everything has evolved. So, I took to a different method of rendering/moving things (and this one is much better overall). Thanks for your feedback, though!

Ixrec, you're right. I was originally trying to cull all non-visible objects on the fly with a quadtree implementation (and got understandably poor performance), but for some reason I disregarded the option of preallocating the background objects into a series of gridded containers. It's a simple solution that eluded me likely due to some goofy and deprecated self-imposed restrictions. Whoops.

I'll refactor my code and get back to you with the results.

 

anything