Problem with creating backdrop obsticles

[Retriever2]

I'm working on a map loader that creates a bunch of obstacles from an active picture object at the start of the level. This worked out fine for a couple small test levels, say 480x480. But on a larger level, I'm running into a situation where after a certain width, the objects are still created, but they don't retain their obstacle property.



The darkened tiles have obstacle background objects pasted in behind them. The red arrow indicates where the obstacles cut off, even though it's clear the objects go on much further. My object limit is set to 20,000 and I'm only dealing with ~250 obstacle tiles.

I did some further testing with the mouse to detect obstacles and create additional obstacles, and there appears to be a precise cutoff starting at 704px into the frame where obstacles are no longer detected. If a single object crosses that boundary, the left side can be detected as an obstacle, but the right side cannot. Regardless of how many tiles I add either in the loader, or with the mouse, this cutoff position does not change.

Can anyone think of something I may be overlooking that's causing this annoying problem?

Thanks.

[xyzzy]

i can't reproduce this with a really fast test app i made... that's weird, though

EDIT: is this with a newer version of TL? because i can probably see if TL does this to me if it's still an older version

EDIT 2: yeah i get this when using TL... are you sure zones aren't acting up or something? (i kinda doubt it given the behavior of the backdrops)

[Werbad]

It could be a problem with something inactivating when it is outside the visible screen... But I don't think so since you say even backdrops added afterwards lose their collision. Try checking "Handle background collision outside the frame" or whatever it is called in frame properties and see if it makes any difference...

[Retriever2]

I've managed to boil this down to a very simple test case, and the obstacles still cut off at 704px into the frame.


Example MFA

The screen is resized at runtime to 3300px (approximately, but not exactly the width of my original test app). Arrow keys move the diamond around, right-click lays an obstacle tile, left-click tests for an obstacle.

This appears to be a problem with dynamic resizing. If I specify the width of the frame to be say, 1000px before runtime, then I don't encounter an obstacle barrier. If it's left at its default 640px, then both width/virtual width changed to 1000px, I hit a barrier at 704px.

[Werbad]

It is indeed a problem with resizing the frame. It only detects collision within the original frame bounds.

[Yves]

Yes, stupid bug in the Set Frame Width / Height functions, sorry, it will be fixed in the next update of the build 248.