median[1..4] + action_set_gravity + action_move_contact

[YellowAfterlife]

Code: [Select]

// Median functions @ mathhnc.cpp ; mathhnc.h
double median(double x)           { return x; }
double median(double x,double y)  { return fmin(x,y); }
double median(double x,double y,double z) { return x > y ? x > z ? y > z ? y : z : x : y > z ? x > z ? x : z : y; }
double median(double w,double x,double y,double z) { return w > x ? w > y ? w > z ? median(x,y,z) : median(w,x,y) : y > z ? median(w,x,z) : median(w,x,y) : x > y ? x > z ? median(w,y,z) : median(w,x,y) : y > z ? median(w,x,z) : median(w,x,y) }
// { D&D functions @ actions.h
#define itype enigma::object_planar* const
#define ithis ((enigma::object_planar*)enigma::instance_event_iterator->inst)
// Gravity action. Tested; works
inline void action_set_gravity(double d, double g) {
itype me = ithis;
if (argument_relative) {
me->gravity += g;
me->gravity_direction += d;
} else {
me->gravity = g;
me->gravity_direction = d;
}
}
// Move Contact Solid action. Concept, might not work as intended for <1 values
inline void action_move_contact(double d, double m, int o) {
itype me = ithis;
double pr = 1; // precision
double dx = lengthdir_x(pr, d);
double dy = lengthdir_y(pr, d);
for (int i = m; i > 0; i -= (m != -1 ? 1 : 0))
{
if (!(o > 0 ? place_free(me->x+dx, me->y+dy) : place_empty(me->x+dx, me->y+dy))) return;
me->x += dx;
me->y += dy;
}
}
// }
As mentioned, action_move_contact might not work exactly like in GM, but its clearly better than nothing.

[RetroX]

action_move_contact with your method is extremely inefficient for what could be done with it (however, identical to GM's), considering how it's faster to iteratively check distances between the object and the rectangles around it.  Much fewer calculations with that method, and fewer calculations means faster games.

I tried doing this once and failed, but you can try it out if you like:
http://enigma-dev.org/forums/index.php?topic=721.0

(read further into the topic for the latest attempts)

[YellowAfterlife]

While that method is more efficient and fast, it already causes troubles with implementation, and will cause a lot more problems once the 'pixel-perfect' collisions will be implemented (if they ever will be).