Possible Bug in Collision exit

func CollideObject() does not work for me if you check for exiting the collision whilst the exit poiint is 8 pixels from the right edge of the screen.

I am using scrolling (but it is the same for static screens). When using scrolling you can still see what you collided with on the previous screen. But it is not detected at 8 pixels from the screen edge. 4 and 12 pixels both work fine so I assume when a screen is changed CollideObject() is not getting called.

an example can be downloaded here.

Look at the map and code to see what I mean.

I've just investigated if there is a problem with entering a collision near a screen edge as well. And there is.

If a colliding area spans the divide between 2 screens then the entering a collision is run twice. Once on entering the collision and again on the screen change.

In games with static screens you would not normally make a colliding area overlapping 2 screens. But in a scrolling game it is perfectly possible which is why I am having problems with it for the first time.

I have made some minor adjustments to my map so I can continue working on my game.

I too had this problem with colliders that crossed over rooms.

I checked it out and it's like this:

The engine keeps a list with collider objects to quickly test collision in a room.
Then each object has the O_COLLISION property that says if it's colliding or not with the player. The collision handler is called for "exiting collision" if the player doesn't collide with an object but the object had the O_COLLISION set.

The problem is that when room changes (also the case of scroll games) the collider list is reset and when new objects are added in it (during the object gather function) they have the O_COLLISION property reseted.

So when you enter in the next room, the object 1002 is still added as a collider but it looses it's O_COLLISION info (which was 1 because the player was inside).

I'm not sure if the collision property should be kept when changing rooms because it may cause problems with teleporting or other cases.

I think there is an workaround possible if you store this state of collision for objects present in the room (enumerate them with ObjPresentCount and ObjPresentIdx) when changing rooms and if you restore it after.

But probably it's easier to avoid having these colliders near rooms' edges.

so basically create a new object property to work alongside the O_COLLISION property, that doesn't get reset on room entry?

i'm trying to come up with a simple workaround in the handlers file, but my brain isn't really working properly.

Yeah, some property to store the value of o_collision, when exiting a room and then restoring from there when reentering. However in some cases this may be not convenient - for example when you hit a collider, exit the room and then come back, and the collider still has the collision set, even if it's position may be reset somewhere else in the room.

Other idea is to keep a list with the indexes (or ids) of the objects that were in collision when exited a room and when entering the next one check which of these objects are still present and set their collision prop, then clear the list. The list can be a global script variable (a table).

Some particular cases may expect the player to eventually exit from a collision and the callback to be called for this (like to reset something that was set when entered) - take care in these cases: if the object will not be present in the next room or if the player would be teleoprted out of collision into another room, the callback will not be called (not without additional codding).

And don't forget that by default the collision callback function (not the collision handler function) is called as latent if no other latent function is running. When entering a room, there may be such a function executed and it may block the collision callback.