How do I efficiently get more granular control over parallax

0 favourites
  • 8 posts
From the Asset Store
Have you tried to create realistic and at the same time casual tank movements? You found the perfect solution!
  • So I'm making a little test project, in the hopes that it might be a small game some day. In this game, I want to have an asteroid field in the background, stretching off into the distance.

    These objects will need varying parallax values of course, and will need to be layered appropriately.

    So my first idea was to use multiple layers each with successively lower parallax values. My problem with this approach, is that spawning a few thousand asteroids randomly among all the right background layers is awkward. I need at least 15 layers to make things look right too and would prefer much more really.

    Obviously, I needed more control over the parallax values. So I thought, I will just make my own parallax system.

    So (roughly speaking) I take the motion of the camera, and multiply it by an object's parallax value, and then move the object in the opposite direction of the camera motion.

    Once I got it working, this looked great. But... this means that very often, I'm moving potentially thousands of objects around. In my tests already, this seems to use an uncomfortable amount of resources for such an early stage in the game.

    Does anyone have any ideas for how I can get more granular control over object parallax values without resorting to many layers each with separate parallax values.

  • Was it efficient to have 15 different layers? I imagine it was more efficient than individual asteroids, and 15 layers is the method I would try. For each asteroid, you want to generate an x, a y and a z from 1 to 15. You can give the layers numbered names so that you can pick them easily. It seems you are up against the limits of the engine and your hardware. I would suggest taking a step back, and looking at other ways to create the same impression for the player. It is only the background after all.

  • Hmm, you might be right. To be honest I wasn't totally satisfied with how even as many as 15 layers looked though. Unsurprisingly, the asteroids felt like they were in well... layers, hehe.

    Does anyone know how other engines handle this kind of thing, even 3D engines? I know I've seen this kind of thing done before in other engines. I'll admit that it may have been optimized in ways I don't necessarily have access too.

    I remember in CC objects had a neat "depth" value I think. I did something similar to what I'm trying now in C2 a few years ago using randomly generated "depth" for each asteroid object and it produced a nice effect. I'm trying to replicate what I did in CC now to some extent.

    I should add that the asteroids that I'm placing in the background won't be interacting with the rest of the game objects much at all. Largely they are there for scenic effect.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • I haven't tested this, it's just off the top of my head. I love parallax layers, but what you're trying to do doesn't seem suited to them (maybe a few only). I think you should have a private variable ("multiplier") for your asteroids that defaults to 1. At runtime, spawn them off-screen and assign each "multiplier" variable with a random value between 0.5 and 2. Then, based on movement of the camera, move them in the opposite direction and multiply it by that the "multiplier" variable. It would likely need some tweaks, but essentially this would give them a range of movement of half through double their base speed. So assigning them to three or four parallax layers + doing the movement multiplication may work nicely.

  • I've made a star field of 500 to 1000 instances placed randomly on 10 layers with parallax set at 10% ascending.

    Decent frame rates, but an asteroid field might need to be managed differently, depending on their size.

    I might suggest a room based approach if they are fairly large.

    A lot of big textures handles worse than alot of small textures.

  • Here's one way of doing it. It's a capx of basically what I explained in my last post. It doesn't look layer-y to me, though I did use a few layers just to enhance things a little. I don't see any performance issues with it, either. The movement is based on a global asteroid speed and is inversely relative to the camera movement.

    [attachment=0:1f5dbnol][/attachment:1f5dbnol]

    I hope that helps.

  • An artistic suggestion rather than a technical one: Give the individual asteroids on a layer a small proper motion relative to the layer, that way it makes it harder for the human visual cortex to see the individual layer moving as a unit.

    Have you tried turning off collisions?

  • These look like some good suggestions that I will try to consider.

    Turning off collisions doesn't seem to affect anything. These background asteroids aren't going to be expected to interact with much in the game at all though.

    I'm still hesitant to resort to multiple background layers though. With the way parallax layers work, I have to offset the asteroids in each layer in order to compensate visually. If I don't do this, layers with lower parallax values will appear in the wrong position.

    Though one fix for this would be to have my camera start at 0,0, and use unbounded scrolling, instead of starting the camera in the center of the layout. Using this method, I would make my layout centered on 0,0. But this brings its own complications too.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)