I think the easiest way to do it would be to have one sprite with a bunch of frames. That way you create the same object, but change the frame based on the array. Otherwise, you'd have to put them all in a family and reference things that way (I believe).

Congratulations on your Steam release! Everybody go buy it!

I have multiple layouts over 12,000 pixels wide. The largest has 17,000 objects on it, though not on-screen at once. The only thing to really keep track of at that point is being vigilant about disabling off-screen or far-away objects from doing anything so you don't eat up cpu time with unnecessary things. So the swaying grass and leaves are obviously disabled off-screen

SmashKAB Here, this is a quick and crude example to show you what I'm talking about. I didn't bother creating unique objects for the layers--I just used a shader to speed things up. You can see the transparent pixels at the bottom of the images. I also used a solid-color tile to fill in the rest under that. I have snap to grid on in the capx to make positioning easier.

Anyways, here's a quick capx of what I'm talking about. (uses C2 218)

And here's a live version of it to run/test in your browser.

The entire image just needs to be moved up a pixel either in the C2 image editor or elsewhere. So don't resize or anything for your solution. Select the entire image and move it up so that the bottom pixel row is transparent.

But, more importantly, video cards can only store images in their memory ("vram" or video ram) in power-of-two sizes. This means 2x2, 4x4, 8x8, 16x16, 32x32, 64x64, 128x128, 256x256, 512x512, 1024x1024, 2048x2048 (this is the cutoff for iphone 4 and some low-end gpus), 4096x4096 (this is the cutoff for modern iphones and ipads to my knowledge as well as many gpus), 8192x8192 (absurd, but high-end gpu's can do it.) Any image you make that is above any of those numbers will be rounded up to the next size. So a 520x540 image will be padded out on the graphics card to a 1024x1024 image (with transparent/invisible pixels filling in the rest of the space. This is stored uncompressed like a bitmap on the card. So youre 7,000-something pixel wide image is being loaded as 8,192 pixels wide. If the gpu only can do square images, then 8192x8192. If it can do rectangular power-of-two textures, then you fare a little better.

But the real answer is that your artist needs to be producing art within the constraints of actual game performance. It should never be a 7000-pixel wide image. Your background images are already Tiled Backgrounds (which mean they would repeat their texture instead of stretching/resizing), so your art should be in something like 1024x1024 chunks that can be repeated/looped seamlessly horizontally. This way, you can load that one image and then tile it out across the map. If you want more variation, make a few of them that share a common edge and then you can butt them up side-by-side in addition to having them tile/loop horizontally.

I took a loot at it. The answer to your problem is it's a graphical problem common to tiled background objects. It's the bottom row of pixels wrapping around to the top. Either shrink the object in C2 by one pixel vertically or bump the entire source image up one or two pixels.

As a side note, though, you're going to run into all kinds of problems designing your backgrounds with such gigantic images. You're immediately cutting out a TON of low-mid tier machines (and nearly all mobile). You ought to find ways to make smaller chunks (images) and place them side-by-side. A stack of absurdly large images is just generally really bad practice. This is particularly true since they're not really all that filled with detail or anything to justify even large images. I'd stick to nothing larger than 2048x2048 (though I don't have a single image even remotely close to that size in my entire game) because anything past that will cause issues on some hardware.

You have a simple layout and already your video ram use is six times my full-sized game with thousands of objects. So I'm not saying you shouldn't do a high-res game (mine is kind of medium), but not like this.

So long as you aren't working on the SAME event sheet or layout at the same time, you should have no problems with this through source control using something like svn or github. I use bitbucket and manage it through sourcetree. It's all pretty painless and lets me keep a running backup and source control over previous versions.

What? No more positioned sound? That is just terrible...

They aren't the same thing. The Doppler effect is the pitch shift relative to something's position (sound gets lower further away and higher closer... Think of a car or ambulance driving by). Positioned sound is just stereo panning.

looks good C-7

Thanks a lot!

That link IS the manual.

It could also be errors from a third-party plugin. But if a blank project doesn't give the error and yours does, then there is something in your project causing it.

I use Rex's date plugin: here for this time of stuff. It works great!