infinite scrolling

Hello,

I have a concept for a driving game that requires a neverending landscape, that wraps around seamlessly as the player drives.

I thought you might be able to do this by adding something like, car.x > layout width, then set car.x to 0. And as the camera scrolls to the player location it would cut straight back with him hopefully without the player noticing as the backgrounds meet up. Also I set the layout to unbounded scrolling.

This seems to create a pop, when the player transports 0.

I've also got a camera zoom effect, where the faster the player goes the furthur back the camera zooms. Works great, but with the infinite scrolling on, this makes the pop even worse, and also adds some completely mental things in the middle. Like the car suddenly driving upside down.

Any ideas of how to pull this off?

The file is here: http://www.mukpuddy.com/timtests/mukbuggy2.cap

I've tried to comment it as much as possible so it's clear.

Thanks a million

try checking on unbounded scrolling.

I think the easiest way would be to enable unbounded scrolling to allow the camera to scroll outside the layout, then add a copy of a little bit of the part of the track that you're looping back to outside the layout in the appropriate position. Here's what I mean in a CAP: Infinite scrolling

I hope that helps, and I hope it's fairly easy to understand.

Honestly I'm not sure if you can pull off seamless infinite scrolling with your physics game in that manner... there are so many complex things going on at once what with the physics and the motion blur that it seems to me you'd always have at least a little bit of a jolt when resetting it. I'm not saying it's impossible, just that... well I know I wouldn't even try except on something much less complex like linkman's example.

The zooming would definitely cause problems, but I think it would work fine otherwise. Also, I checked with my own example and motion blur actually isn't affected by the jump back to the other side of the screen. Physics would probably be fine as well.

Maybe I'm just thinking it would be harder than it actually would be.

I thought you might be able to do this by adding something like, car.x > layout width, then set car.x to 0

You should use unbounded scrolling, but you should still have some kind of wrapping system like this: the further you get away from the 0,0 origin, the less accurate the floating point values that hold the coordinates become. Still, you can be fairly generous and have say 10-50k pixels before you wrap. You'll need it to be a multiple of the width of any tiled background images you use for it to be seamless.

Setting the X to 0 is going to stutter, because it makes no provision for how much further beyond the layout width you've gone (it still goes to X=0 even if you've gone 1 or 100 pixels over the edge). To fix this, subtract the layout width from the X co-ordinate instead, eg. Car.X > LayoutWidth, set Car X to .X - LayoutWidth.

Thanks so much for all your help.

I'll have a play around later today and see if I can get it going.

I'm in the process of finishing off the actual art for the background, so I might rebuild this once thats done, maybe in a few days. Then I'll revisit the problem.

Thanks for all the help so far though guys, much appreciated.

I've uploaded a new version, with new graphics, and simplified code.

http://www.mukpuddy.com/timtests/mukbuggy_level1_test.cap

The scrolling issue is still there, but it's not as bad. It's a little smoother now that I moved the wheels aswell, as opposed to letting them reset to the right position automatically.

It seems like the physics interferes with the move, is it possible to disable the physics when you hit the edge, then enable them again?

Strange thing is, it worked great when it was just a ball. As soon as switched to the car it went bung.

Huh, that's strange. I didn't think that the physics would have any adverse reaction to that.

Unfortunately there's no way to disable the physics(I don't know why, considering all the other behaviors have that option. Probably something to do with Box2D), but I managed to fix it by saving the X velocity, Y velocity, angular velocity, angle, X and Y positions of the car, and the angular velocities of the wheels everytime it goes off the side, then it will destroy those, create new ones, reestablish the hinges, set the angle, the Y position, the new X position, and then finally restoring all of the motion. Here's the modified CAP in case that wasn't explained very well: Modified driving CAP

By the way, nice graphics you have there.

Wow, nice work. Thanks a bunch!

I've adjusted the background bits so it's not flicking.

http://www.mukpuddy.com/timtests/mukbuggy_level1_test.cap

Seems to work sweet. Just the tiniest little flicker on the bg, not sure what's causing that, just the sudden camera move i guess. I don't think it's a problem though. Especially if the background is bigger so it doesn't happen as often.

Thanks for the kind words on the graphics, I've still got a few tweaks to do before I'm totally happy, that highlight on the wheel looks retarded, plus there will be a driver.

the torque is a lot of fun to play with

The torque is a lot fun to play with. Especially when you add a huge ramp.

Btw, I've never seen the custom collision mask used. That's pretty cool.

[quote:11531wfo]The torque is a lot fun to play with

I thought so too. I'll have to make a proper track, that's bigger.

A big part of the concept is the vertical scale, which is in no way captured here. I need to do this on my next run through.

The collision thing is the best way I could come up with to put one collision mask on multiple background tiles. Seems to work. It did a couple of strange things at first, like wierd areas where you suddenly dropped. But I just redrew the mask a few times until it came right.

Now onto making it an actual game, instead of just a car going back and forth.