ENIGMA Development Environment

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 .

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.

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.

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.

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.

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.

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.