To be honest with you I wouldn't even begin to look at how I'd tile a background until I really got into it, which I'm not prepared to do at the moment. In large, I'd leave the background as just that, background. Using Mario by way of explanation the background would be nothing more than clouds, mountains or buildings that offer no interaction with the play. But it would need to scroll to some extent , a bit slower than the foreground to enhance the feeling of distance.
The foreground would be everything that interacts with Mario, including the Oopahs (or whatever,) turtles, etc. It would also include the pipes, bricks, flowers, mushrooms, etc. anything that's on the same plane as Mario. Each one of these objects (I'm assuming they're all sprites) would, IMO, have to be not only a sprite but class objects that encapsulate sprites. It can also be done by encapsulating the descriptive elements of the objects in structs. At this point my inclination to be instructive stops at going into explaining classes and structs. That's where you need to start studying. It's entirely possible to do this without class objects but you'd need to have a tracking system based on parallel data storage in a number of different arrays.
AAR, back to what I was saying before, assuming you have an array containing the objects, if you have the array sorted by the horizontal (X) position in the world you only need to determine which ones are on the screen at the moment. Since they're sorted they'd have to be between a certain minimum and a certain maximum index and that would be the range you need to check until the left most object moves off screen and any new ones move in from the right. At this point you move the index points for minimum and maximum checking up to encompass what's now on the screen.
Lilith, Night Butterfly
I'm not a programmer but I play one in the office
