Tiled Background Collision events

Something I've wondered for a while now. What is the reasoning for Tiled backgrounds not having the option to add collision events? By that I mean

you can do

     sprite on Collision with TiledBackground.

but not

     TiledBackground on collision with sprite.

or

     TiledBackground on collision with TiledBackground2

Same thing goes for all the "Collision" events

is overlapping another object.

is overlapping at offset

Collisions enabled.

TiledBackgrounds must support these as you can check them vs sprites. And of course they function just fine as a solid or Jump-thru. Not to mention you can give TiledBackground behaviors like "8 direction" "bullet" and "platform". Not to say TiledBackgrounds are best suited for them, Just that you can.

I've found myself wanting to use those events on a Tiledbackground more than a few times, and ending up confused for a moment trying to find the event. Any info on this is useful.

Thanks

Guess it's just me who finds this peculiar.

Hey man. I suppose it's not a common occurance for people to want something that I guess usually stays idle and is used for looping tiles to boost performance.

Through personal experience, I've never really came across this sort of scenario of needing collisions laid out like that.

If I ever use a Tiled background, It's usually for something that I need looping for quite some distance. Also, say for example I made a long ground, I wouldn't have much power over it's collision polygon since it's disabled, therefor I couldn't make it so the character is walking on it as I want it to.

I do think though, that animated tiled backgrounds could be really useful for backgrounds and stuff, but maybe all this stuff (including specific hotspots)are disabled to boost performance or something.

Overall though, I just don't have the need for needing a tiled background to collide with something- I'm usually colliding things with the tiled background, or not at all lol

I agree. When you need to deal with a surface that's more dynamic then just a Box with a tiled texture. TiledBackGround is not the answer. What I love about TiledBackGrounds is the "tiled texture" and performance over large areas. Kind of the reasons we have then.

An example as of late where I wanted to use a TiledBackground on collision with TiledBackground event, was my Ludum Dare 26 entry. I wanted to create varying sizes of a moving platforms. Ones that I could alter the width at runtime without stretching the image, simply tile it. The estetic of the platform was a 16x16 tiled image. So using a Solid TiledBackground. was perfect. That is until I could not compose events allowing it to alter it's motion on collision with the surrounding TiledBackgrounds. Ones that I was using for the majority of the level.

It's easy to work around. I would use a sprite that simply contains a frame for each possible size I wanted.   I could pin the TiledBackground to a dummy sprite and use it for events. One could use a bullet behavior on the TiledBackGround and bounce it off solids and constrain it's angle of motion. This one I tried but found it unpredictable in certain situations. Or position checking events with a few variables and ignore collisions all together. Or a dozen more possible answers I'm sure.

I guess in the end what I find myself wanting is either. The collision event functionality enjoyed by sprites, no need for anything beyond using it's Bounding box .

Or for Sprites to have a Tiled image functionality.

I don't know what's more feasible. Or if anyone else would make use of it.

I agree it does seem odd, when in effect your two examples at the top have the same result.

I'd guess its an form of optimisation built into the engine to keep a ceiling on the collision checks, but, as a large tiled background could potentially have a vector the size of the layout, but I'm not sure...

It would be useful to have an overlapping condition for Tiled backgrounds. Why cant we have it? Whyyyyyyyyy?! ;____;

I would suspect it's because everything possible was cut out of them to get them to be as efficient as possible. Sort of like the particle argument, if you add features, you lose the reason to have them at all, because using sprites instead would be equal. Making having them nothing more than added complexity.