Best way of wrapping starfield?

This forum is currently in read-only mode.
From the Asset Store
Best car suspension with spring effect and very cool terrain generation.
  • Hi guys.

    Whats the best way to make my stars wrap around the play area (when they go offscreen, to appear on the screen and the opposite side again).

    I'm using paralax scrolling. I've done this by changing the scroll rate on the layer. However, when the stars move, construct thinks their X,Y position is the same (fair enough).

    I mean, i could just screw the scroll rate idea and make them use the ball movement or similar and compare it to my ship's speed to make the stars appear to be paralax. But is there a good way to do this with construct's inbuilt scroll rate thingy?

    Thanks,

    Al

  • I just reset the XY when it leaves the play area. If the layout is 800 x 600 for example, just subtract/add the XY it leaves at based on which side it left.

    As for the other issue, that may be something that can be added. An option to have the XY update based on actual position rather than where it would have been.

  • Why not make individual star sprites and have them always move in one direction and apply a wrap behaviour? Although it sounds like a resource hog, unless you are putting a huge amount of shaders and more than 200 stars on screen at one time then you shouldnt see much fps drop.

  • Why not make individual star sprites and have them always move in one direction and apply a wrap behaviour? Although it sounds like a resource hog, unless you are putting a huge amount of shaders and more than 200 stars on screen at one time then you shouldnt see much fps drop.

    That's exactly what I would do... you could still use paralaxed layers with that method... though I would probably make it so the stars moved on the angle the ship is moving, minus 180� so it gave a feeling of proper direction.

    ~Sol

  • But if you're moving the stars, then actually, you want them to have a scroll rate of 0%...

    Maybe I'll start doing it like that. However, I want to avoid using CPU abusive things at all costs, i mean, this game is going to have alot more stuff going on that is currently happening..

    I'll look into these though, thanks guys.

  • Well, you could still use a scroll rate for each layer, that way you can have all the stars move with a single event instead of one event per layer. The event could move them all at the same speed, but using the layer scroll rate would give the layers in the "background" a slower natural movement.

    I guess the other thing being, is it wouldn't use much CPU if the objects were using simple ball movement, and were looping/wrapping on a per screen basis and not covering the entire "level".

    ~Sol

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Umm... Does it currently take a lot of resources? Optimisation is futile if there is any need to optimise. And I think layer scrolling takes less resources from CPU, IF it's relying on some DirectDraw things. Does it, Ashley / Dave / Rich? Using ball/bullet/whatever movement takes more resources from CPU, 'cause it needs to calculate every object's position... But currently, if it isn't slow already, I wouldn't try to fix it.

  • I think it's too early to worry about CPU usage. Try both ways running uncapped. I doubt the FPS will be much different.

  • I suppose my question is more "How do you check when a star has left the screen when using scroll rates, as scroll rates affect X,Y positions (2 objects may be overlapping, but if they are on different layers with different scroll rates their X,Y positions may be completely different)"?

    And also, which side of the screen the star just left.

    Any Ideas? Not entirely sure how this works in construct.

  • I can't check right now (ISP still being incompetent; at the library), but I think the ScrollXLeft, ScrollYTop, ScrollXRight, ScrollYBottom expressions give the current viewport, and if you add a layer parameter, it should give the appropriate values for that layer. Eg. on a parallaxed layer "Stars", ScrollXLeft("Stars") should give the X co-ordinate of the left visible edge. If this isn't implemented, then I'll try get it in to the next build. You could then use these values to determine if the stars have left the viewport of the parallaxed layer.

  • I did a test of this, I did when

    smallstar.X is less than ScrollXLeft("stars_far") 
     = Set smallstar.x to "smallstar.x + 50
    [/code:2ss23ef4]
    
    This results in you moving to the right, then the stars just fly off the screen to the right. So it appears that the ScrollXLeft("Stars") bit is moving to the right.
    
    I couldn't find how to manually do ScrollXLeft("Stars"), i just typed it in and it didn't complain...
  • Ash, can you verify that this isn't in this build? Or am I just doing it wrong?

  • ScrollXLeft etc. are definitely coded to accept a layer parameter - are you sure it's not working correctly? If you set ScrollXLeft to one text object, and ScrollXLeft("Stars") to another, how do they differ?

  • Ok ash I've uploaded an example. Having the same issues in the example as in my main program.

    Basically, the code is meant to move the star 50 pixels to the right when it hits the left edge of the viewport. (of course in the game i would not do 50 pixels, i would just set it to the rightside of the viewport).

    Maybe i'm just using it wrong... Can you take a look at it Ash?

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