/vr/ - Retro Games

>>2546874
Np. I'll fully comment it when I'm done.

>>2545038
So fast collision for moving mobs is hard guys, but I think I'm zeroing in on a solution that is very general.

My original approach involved moving the player against all crates, modifying the resulting dx and dy but retaining the initial position, and then moving player against the level. For fast calculation, the movement is first calculated in X or Y, then Y or X, depending on the relative magnitude of the displacements.

This introduced a subtle bug where the player could be sliding down a wall and end up standing on a crate embedded flush (image). This is caused if the X velocity exceeds the Y. If the player is immediately above the crate in Y then he will be moved in X unimpeded, and stopped in Y when moved down by gravity and intersects the crate. This zeros dy. Then starting back at the initial position, the player is moved against the background, stopped in the X direction, and dx is zeroed. Thus the player's velocity is zeroed, and they don't fall. Another problem is the current code also doesn't generalize to more than the player and crates.

One reason I started this project was to try to solve serious collision quickly for a larger scale game, so I'm trying to design a good solution.

Here's what I'm thinking so far. When moving a mob (including the player), it is moved first in the direction that has the greatest displacement, then the other (like before). The mob is moved against both the background and other mobs in the first direction before going on to the second (unlike before). When the moving mob intersects other mobs, those mobs return a pointer to their data. The moving mob then has it's own program to decide how to interact with the intersecting mob based on identifying the mob pointed to and modifying both mobs' states if needed. Movement priority is governed by where in the list a mob is processed (unfortunately).

I hate introducing priority, but need to be fast.