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.

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 .

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

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.

Subtraction is used in move_contact and move_bounce in bbox, and I have just added subtraction to move_contact in precise.

The current implementation of move_bounce in precise is similar in behaviour and speed to move_bounce in GameMaker. It only uses a constant number of collision checks, which is fast, but not very accurate. Subtraction would only be useful if move_bounce is made more accurate, but I think that making it more accurate would make it slower than the implementation in GameMaker.

I have thought about using binary search for move_contact as well, but I think it can only be used correctly if the collision mask is "stretched"/repeated along a line for each check. Else, the binary search might skip collisions. Since "stretching" a bit mask along a line is quite slow for medium and large bit masks, it would probably be slow in most cases to use binary search in move_contact in precise. Since a line can be "stretched" quickly, I think binary search could be used for something like collision_line_contact. Certain polygons may also be fast to "stretch".

I got the Kingspace engine demo running correctly with lights, the latest commit should fix it. I fixed the directional lights and the light position update (it was being updated in the wrong place). The screenshot you uploaded fits with what I get after the latest fixes.

I had some trouble getting the Kingspace engine demo up and running on Linux. I found out that the path was formatted wrongly in file_bin_open in fileio.cpp - amongst other things, the path returned from get_working_directory() didn't include a starting slash.

Hi polygone, I have committed a change that should fix the lighting for positional lights. Note that not all lights may be active, since in some cases, OpenGL only offers 8 lights. This seems consistent with GameMaker:Studio, since its manual says that at most 8 lights should be active at once. I have also fixed the normal for the walls, and the normal for the floor is correct if the floor is not slanted.

You are absolutely correct regarding the events. I had tested move_bounce extensively with non-solid objects, and gotten the same behaviour, so then solid failed, I assumed it was due to the collision events handling of solid, and when changing the events "fixed" things, I jumped to the wrong conclusion. It turns out that (as far as I can see) my original findings a couple of months ago regarding solid were correct. I didn't implement solid correctly back then, only partially, but one of the most recent commits should implement solid correctly in the collision event.

I have made a number of changes to move_bounce. I am convinced that the moving-back should not be based off the speed, but off the previous position. I tested this by putting a non-solid player in one side of a room, put a non-solid block at the other end, give the player a low speed, and then teleport the player directly into the block and use move_bounce_all in the collision event. This results in the instance ending up at its original position (with its direction changed). For that reason, I believe it should be the previous position and not the speed. The latest commit changes things, such that move_bounce only moves the instance to the previous position if there is a collision currently.

The funny thing about the above scenario is that, if you make the block solid, teleporting the player into the block has no effect at all on the player, neither in position or speed. This can be explained by the correction you make regarding return false if has_coll(x+hspeed, y+vspeed) gives null. So I have added and tested your correction and verified that it works.

There are also a couple of other changes; the House Effects Demo uncovered several other, smaller bugs.

I have also tested the recent changes with some platformers and other examples, so the recent changes should work somewhat well.

Well, it actually turns out move_bounce is not buggy. Instead, it is the collision event handling of solid I wrote that is to blame. Since the code I wrote worked according to the description of solid collisions in the GameMaker manual and the YoYoGames wiki, that means that those descriptions are wrong. I have experimented a bit with a different handling of solid, and the new handling of solid I just committed seems to work the same in both GameMaker and ENIGMA for the House Effects Demo, as well as some other examples using solid. The way it works now is that, after the collision event, if the other object is solid and there is still a collision with the other object, return the current object to its previous position. In regards to the manual, it should be noted that the description is wrong in both the old (GM6) and the new (Studio) version of the manual, even though the collision event section has been rewritten in the new version.

I think I will document my new understanding of solid in the ENIGMA wiki, once I have tested out a couple more examples with solid and verified they work the same in GM and ENIGMA.

Finally, I hope that my naïve and misguided trust in the documentation ability of YoYoGames will not prevent me from shifting the blame to them .

In case anyone is curious, I have finished the precise collision system. The collision functions have been implemented and tested, and BBox has also been debugged a bit in the process. The performance is generally on par with GameMaker, which I believe is good enough for now.

In regards to the behaviour of the functions, I have tried to mimic the behaviour of the corresponding GameMaker functions. Some of the details are not quite the same, for instance, [snip]move_bounce_all(true)[/snip] in GameMaker seems to always round the resulting angle to a multiple of ten, which [snip]move_bounce_all(true)[/snip] in ENIGMA does not. But the overall behaviour is generally the same for each function and its corresponding function.

In regards to my future plans, I have decided to work on a simple implementation of a system for particle systems. Since the overall structure and design of the system has not been created yet, I will develop the system in a fork until it is stable enough to be merged into the main branch.

[object]

Thanks for the notice, I have fixed object and all in the move_* functions. Why should DMIN be used instead of 1 to increment in the "for" loops?

I don't really have any future plans about what to work on in ENIGMA, apart from doing various small fixes. I do have a couple of ideas, but I haven't decided on any of them yet. Once the precise collisions are done, I will take some time to figure out what to work on, and then tell about my plans then.

Thanks for the commit access, I am ok with fixing anything I break.

In case anyone is curious, my current plan is to continue implementing the precise collision system, which is coming along well (the basic collisions work, including rotation and scaling, some collision types are not fully supported yet, such as diamond and ellipse, and there are a number of other functions that are still missing). If anyone wants to try it out, select Enigma->Settings->API->Collision->Precise in LateralGM.

I have just finished the patch, and it can be seen here: https://github.com/forthevin/enigma-dev/commit/de35331e431188f6ddb6767229cad064c87dc5e9. It has also been added to the existing pull request.

In regards to the interface change and the commit, I decided to change the interface from using [snip]char*[/snip] to using [snip]unsigned char*[/snip], since that turned out to fit better with the existing systems. Apart from that, there was no other changes to the new interface.

Unless anyone has any objections, I would like to go ahead and try to make a patch to implement the proposed changes. Since the changes regarding LateralGM and generic collision types are most useful once polygons or other collision types are supported in a collision system, I suggest that those changes are postponed until they are needed.

I can't think of anything more that [snip]get_collision_mask[/snip] should have, so I think it is good to go.

In regards to the mask system integration, I think it would be a good idea to support generic collision types in LateralGM, basically collision types that are identified only by their enum value and which has a generic representation (such as a byte array) for the collision data stored in each subimage. That would make it easier to support new collision types without making extensive modifications to LateralGM. It should still be possible to support a given collision type directly in LateralGM, for instance for the purpose of adding graphical editing for the collision type. Since adding graphical editing for generic collision types is not possible, LateralGM should support loading collision data for subimages from files, for instance by reading the contents of a file in as a byte array for a given subimage.