Next topic

[Josh @ Dreamland]

I can see your point, forthevin, but I think we should examine the typical use case. For a binary search to fail where brute force would succeed,  the colliding pixels would have to be fewer in breadth than 2**(n-1), where n is the distance from the bounding box edge to the pixel. So for a one-pixel collision to miss, it has to be at least three pixels from the bbox edge. Otherwise, the check with d = 1 or d = 2 would catch it. The check with d = 4 would potentially miss it.

So, that circumstance *could* arise, but I'd argue that it wouldn't. If we want to build it for every case, then we can't use the bounding box as a hint, either—the bounding box can be placed away from the actual collidable area.

I'm not that worried about it, though, as the function dogged it in GM so people learned to avoid it. Besides, no offense to you or anyone else, but I intend for ENIGMA to default to polygon based collisions if I (or anyone else) ever have a chance to work on them.

[polygone]

I don't think a binary search should be used either, it doesn't make sense to me to use it for this. However you make a good point about the bounding box, does manually changing the bounding box in GM affect move_contact?

[polygone]

Thanks forthwin for sorting the depth draw bug, that's been in enigma a while - it was suggested using a pre-calculated list for the depth but nobody got round to it. And I can see that it has resolved that bug I was having with the alpha glow and whatnot, I was thinking about the depth as well I don't know why I didn't consider it being related to changing the depth in the draw event; it didn't cross my mind for some reason.

[forthevin]

IsmAvatar:
In regards to the binary search, using binary search for finding the contact position should work correctly when used for a point along a line. The basic idea is to check half the distance for collisions, for instance using collision_line. If the check turns up nothing, there are no collisions in the first half, and so only the second half needs to be searched. If the check does turn up something, there are collisions in the first half, the first collision point will therefore be in the first half, and the second half does not need to be searched. In both cases, the search space is halved. The procedure is then repeatedly applied on the new remaining distances to be searched, until the remaining distance becomes 1 or less. It isn't exactly binary search as understood for sorted sequences, but the name still fits somewhat well. EricDB's collision_line_first is implemented somewhat similar to that way.
In regards to commits, I will avoid flooding git with many small commits in the future.

Josh:
I do believe that circumstance could occur quite often in certain games. In games that have medium or big sprites with long, thin structures, move_contact from certain points and angles would be very likely to encounter that circumstance. With subtraction implemented in move_contact, the behaviour for move_contact should be the same in ENIGMA and GameMaker, and the performance should be equal in the worst case, and considerably better in most cases.

I don't understand the part about the bounding box not being usable as a hint. Doesn't the bounding box always cover everything in the sprite, even under rotation and scaling? Manually changing the bounding box in GameMaker and using precise makes only the area inside the bounding box to be checked precisely, the rest of the sprite is ignored.

polygone:
Np, I first realized it was a depth problem after I commented out the assignment to depth and the bug was suddenly gone. I knew that the cause had something to do with the candle being drawn twice, because of the z-fighting and the increased color from the blend mode bm_add being used, but I didn't quite understand why it was being drawn twice until I commented out the depth. That also explained why the bug only occurred when walking towards the candle, not away from it: the depth for a candle becomes more negative when walking towards it, and so the draw event for the candle was executed twice.

[IsmAvatar]

Ah, I didn't think of the data being a collision line, rather than a collision point. Excellent, that'll work great, then, because the data is sorted (strange way to think of sorting, but again, the data is either 1 for collision or 0 for no collision, so as long as all data is contiguous except for the turnover point, it's sorted).

[TheExDeus]

Does the precise collision detection uses bbox check the first time and only if collision is detected it checks masks? Too lazy to check code right now to see.

[forthevin]

Yes, it first checks to ensure that the bounding boxes do overlap before going on to checking masks.

[polygone]

Hmm by the sounds of thing you use the GMC forums forthevin, I'm trying to figure out who you are?

I'm guessing you don't want people to know though and you leave no clues

[forthevin]

I do read the GMC forums occasionally, but I don't really post there, so I don't have any need for a user account. So I am not surprised that you have trouble finding my user account .

[polygone]

hmm, that or you're trying to throw me off the scent? :p

[forthevin]

How can I throw you off the scent if there is no scent to follow?

In other news, I have looked a bit into particle systems, and am slowly beginning to implement the basics. My current plan is to do the implementation in my own fork, and once the system stabilizes, I will merge it into the main repository.

[IsmAvatar]

If you would like, we can make a branch for your changes so you don't need to fork the whole project. It's up to you.

[forthevin]

I still have the old fork that I can use, so it is not so bad.