Paste Into Background counts towards the frame's object limit?

[Del_Duio]

This is weird but I'm pretty sure that's what's happening. I'm trying to call back info from an array that will be used to tile a frame that's 3200 x 1800 in size (the tiles are 20 x 20 each).
Anyhow it works great up to a point and then it just stopped doing the tiles. I tried everything and nothing changed until I upped the frame's object limit from 1000 to 5000 and it tiled MORE of the frame- but not all of it

I'm not creating new active objects or anything, I just wanted to paste the active's image into the background so I don't see how this should be happening.

I usually make all my levels "by hand" i.e. just do one giant png file and import the thing but I wanted to try the way most people seem to do it now. So if you've ever made a game with a level editor using paste into background, is this normal?

Thanks

[schrodinger]

It does so, unfortunately
If you can "afford" standard mode, I seem to remember you can bypass this limitation
(I guess stuff is "blitted" in standard mode, while in D3D everything is dealt as an object)

Or you could consider not pasting the entire level but just portions of it, as you scroll by (if applicable)

[amiman99]

When you paste in the background, you should destroy the object , so it will not count towards the final object count.

Am I right?

[nivram]

Yes you are correct amiman.

Marv

[Del_Duio]

Well what I mean is I'm moving the same active object that holds all the pictures and etc. using fastloops like this-

Start of Frame -> Start Loop "X_Loop" 160 times

On Loop "X_Loop" -> Start Loop "Y_Loop" 90 times

On Loop "Y_Loop"
-> Set X position of Active TilePlacer to LoopIndex ("X_Loop") * 20
-> Set Y position of Active TilePlacer to LoopIndex ("Y_Loop") * 20
-> Force Animation Frame of Active TilePlacer to (different things go here, grass, a tree and etc)
-> Add Backdrop

--

So see if I destroy the object after pasting the image / adding the backdrop then it won't be able to continue placing the tiles since it's only a single object that gets moved around in the first place. I really have almost zero experience with making levels like this it should be noted

I should also say that I did some research after posting this and saw a post Marv had made a while ago saying that Add Backdrop was the more preferred method over Paste Into Background, though the object limit still stands.

So I wouldn't be able to destroy the object and still get this to work, right?

Thanks for your responses so far!

[Del_Duio]

It does so, unfortunately
If you can "afford" standard mode, I seem to remember you can bypass this limitation
(I guess stuff is "blitted" in standard mode, while in D3D everything is dealt as an object)

Or you could consider not pasting the entire level but just portions of it, as you scroll by (if applicable)

The only reason I wouldn't want to do standard mode is it seems it doesn't jive with the Steam overlay, which this I would eventually like to have up there. HWA 3D9 does work with it, and it's what I've been using for the past couple projects.

[schrodinger]

Yeah that makes perfect sense.
Be sure to check out this thread also, I remember struggling along that line not too long ago:
https://community.clickteam.com/threads/97790-Paste-to-background-add-to-backdrop-some-questions

There might be some answers (or more questions)

Is the "create on the fly" option viable?
Or even directly using a fixed set of active objects as tiles you would update while the player moves
(scroll out last column - enter in from opposite side with fresh tiles)
I tried the latter with 20x12 tiles running fine on Android at 50FPS,
so I guess could be used without too struggle if the game is PC and level not too large
but perhaps could require some important modifications to your project

[EE]

Is the "create on the fly" option viable?
Or even directly using a fixed set of active objects as tiles you would update while the player moves
(scroll out last column - enter in from opposite side with fresh tiles)
I tried the latter with 20x12 tiles running fine on Android at 50FPS,
so I guess could be used without too struggle if the game is PC and level not too large
but perhaps could require some important modifications to your project

I've personally wanted to try this route for several reasons.
The complicated part imo would be collision handling outside the visible frame area.
Since npcs often remain active (chasing, patrolling, etc) all collisions would have to be checked
against a tilemap. I'm tempted at trying it out in some simple manner though.

[schrodinger]

The complicated part imo would be collision handling outside the visible frame area.

Definitely a good point!
You'd have to manage it differently, like turning "off" not visible enemies/items/npcs and ignoring their existence,
or i.e. having your map obstacles for collision checks not directly among frame objects but into an array,
whose "map" would be always available (and rereading your post, it's what you were saying!)

some "load/unload" routine for things going too far from screen is generally needed with this approach,
but could be (or could not be!) simple to setup, depending on the project

though yes, I think there would be some "loss of activity" for npcs etc., if you don't want to go crazy

[EE]

(Sorry for de-railing!)
When loading a map you could first add all enemies/npcs to a list or array as a pool, and if said mob is close to the currently active area shift it over to another list/array in which candidates AI is active, no? Sounds complicated but doable!