Yeah, mostly CPU. Memory's cheap, they say, and the GCC uses a shitload compared to the sleekest around (Clang, however incomplete). But yes, I notice a huge jump from single core to even just dual core. I don't notice much difference between dual and quad, though, so. I think there's an option for number of CPUs to use in the GCC, but I don't make use of it.

Then do it already.

Anyway, downloaded r618, extracted, ran ENIGMA, got told that it found MinGW, so I clicked Yes, but it failed to do anything. So I uninstalled, removed the MinGW folder, and ran ENIGMA again, this time clicking No. A bunch of text appeared in the console, and then I thought it got stuck, but in actually, it was just taking forever to download MinGW.

This is what the console wrote during installation. Sorry for the wrapping. It's cmd.exe's fault. It probably took 15 minutes for ENIGMA to download MinGW. Maybe you should host MinGW in your Dropbox public folder, hehe.

Some specs (school computer, using that right now):
- OS: Windows 7 Professional 64-bit
- Processor: Intel(R) Xeon(R) CPU W3520 @ 2.67GHz
- RAM: 4 GB

This happened to me to, exactly the same. However I made sure all traces of Enigma and MinGW was completely removed the next time, rebooted and ran r618 again and it worked. Don't worry it installs rather fast, it's the errors which are slowing the instillation down.

[you]

Actually, I have no idea why the fuck Ism's implementation works. direction.rval.d is in degrees. Or at least it's supposed to be. There is the possibility that it is only in degrees when it is the last variable set.

Funny you said that to me when I mentioned it. But then Ism quite rightly pointed out that you were actually the one who used that code first:

I'm actually too tired and lazy right now to do the trivial amount of text insertion required to put that to code. >.<

-sigh-

Code (C++) Select Expand

const double dir = ((enigma::object_planar*)enigma::instance_event_iterator->inst)->direction.dval = chosendirs[choices];
((enigma::object_planar*)enigma::instance_event_iterator->inst)->speed.dval = chosendirs[choices] == -1 ? 0 : argspeed;
hspeed.dval = speed.dval * cos(dir), vspeed.dval = speed.dval * sin(dir);


Assuming all the rest of your code is right, and that I'm remembering the name of my own class member correctly.

She doesn't know why the fuck it works either

Quoting Ism:

There have been some concerns over radians vs. degrees, and I haven't looked into them fully, but oddly enough action_move seemed to work...

Because of the way rval.d works, the code is correct without degtorad. This got me too.

Suppose f1 and f2 return 0, and obj2.array[0,0] = 0.

The statement would be equivalent to the following:
obj1.a = 0;

As you can see, I'm totally lost, which is why someone needs to explain this one to me.

As RetroX has just said, because what if there are multiple instances of obj1 and obj2? You can't run things so straight then. f1 and f2 might return different values depending on the instance it was executed with.

RetroX has stated as a solution:

in the end, the last one executed would actually be stored

But to me this is really not nice and I don't think it is a viable solution. Which is why I mentioned previously:

Code (EDL) Select Expand

obj.a = obj.f1();
People would naturally expect this to work like:

Code (EDL) Select Expand

with (obj)
{
  a = f1();
}
But it would instead work like:

Code (EDL) Select Expand

global var ______ENIGMATEMP;
with (obj)
{
  ______ENIGMATEMP = f1();
}
with (obj)
{
  a = ______ENIGMATEMP;
}

How would that be interpreted?

Then, add a configuration option to make both variables and functions operate on all objects.

It's not reasonable to let them to be changed to loop through all instances otherwise you can start doing all sorts of crazy shit. Like this:

Code (EDL) Select Expand

obj1.a = obj2.array[obj1.f1(), obj2.f2()];

Yeah, that would make sense.  Still think that it would be a good idea to have an option for all objects, though.

Given that you would want to change the object_index.variable = value interpretation to every instance at the same time. Otherwise this code would be counter-intuitive:

Code (EDL) Select Expand

obj.a = obj.f1();
As it would only assign a to the first instance of obj whereas it would loop f1() with all instances of obj. It is not possible though to change them to loop through all instances of objects because it will be too much work for the interpreter to do.

Which is why I originally suggested it should just syntax error, but given that only the first instance of obj is used than I believe it is doable, it would just be like replacing obj.f1() to the return value of f1() executed in the scope of the first instance of obj.

[with]

Using with seems counter-intuitive to me given how gml works. Because when an object_index is given in gml in variable assignment it only assigns to the first instance of the object, unlike with which assigns to all the instances.

Code Select Expand

obj.a = value;  //assigns to just the first instance of obj

with (obj)
{
  a = value;  //assign to all instances of obj
}
Thus if the dot syntax was used for executing functions it seems better to me if it does not use with, but rather only executes to the first instance of obj in order to keep the notation consistent.

What?

Anyway never-mind it would clearly have to syntax error. This couldn't be used for anything other than straight executing functions.

Given this suggestion, how would this be interpreted?

Code (EDL) Select Expand

a = obj.f1();

Assuming you calculated the normal and took (distance-used_distance)*sin(dirdif(normal,dir)), then performed the second iteration perpendicular to that normal, it' work fine.

That's what I was thinking. It's highly easy with bbox checks.

Until, of course, you want us to check a third corner and so on. Then our algorithm becomes O(ND) as we have to keep iterating so long as there is yet any distance left to be iterated.

Yes, but then I don't think you are likely to hit that many instances when moving. The problem I envisaged though is doing this against concave slopes..

Polygons and 3D meshes will not make this task quite so easy, and though it's well within the realm of possibility, my fear is, as always, efficiency.

The thing is I advise making a function for this (or some other movement function) because then you can make it efficient and accurate. This will hopefully prevent most users making all sorts of bad collision systems and give them something easy to work with. The collision systems used in GM games are perhaps the most common area done badly.

I haven't actually thought much on how to go about it yet.

No it doesn't do it in Game Maker. I don't think the move_contact function should do that either, the definition is to move the instance until it comes into contact with another object. What you're describing would be a whole other function, though probably a good one to implement. It shouldn't be hard to do, I believe you can just do another move_contact using the remaining momentum. What would be interesting (and highly useful) is doing a non-precise version of that function.

Note that we're going to need the GM method of move_contact as well anyway since it uses precise collisions and this one is only bbox. GM's method even works inside hollow objects, clearly the bbox method does nothing.

[EDIT:]

First, there's two ways your statement "yet dx, dy are exactly the same" could be interpreted:

I didn't mean to suggest they were equal to each other (perhaps bad English), I was trying to say that dx and dy were constant, independent of the direction that the object travelled in. Thus they cannot be used to determine which side the object collides with.

But Josh said on IRC that his image was covering this case in the 3rd picture and was suggesting to use 'double collision' to resolve it, I don't wtf he means but regardless now anyway Josh has realised that the method I am using is the same as the one he was suggesting (which he didn't see before due to lack of sleep, he thought I was rewriting Retro's method) and since my code is working (I hope) it's fine to use (once written in C++).

EDIT:
Wait after actually reading what you put properly (I should really start doing that more), I think you have misinterpreted what I was referring to as dx, dy (since dx2 and dy2 don't exist  ). I was not using them to represent displacement of the object, I was referring to the dx, dy variables Josh used in his code:

Code (C++) Select Expand

const int dx = inst2->bbox_left - inst->bbox_right, dy = inst2->bbox_bottom - inst->bbox_top

[EDIT:]

I don't exactly get what you're doing, I'll wait till I see it finished...

EDIT: OK I see that with this code:

Code (C++) Select Expand

const int dx = inst2->bbox_left - inst->bbox_right, dy = inst2->bbox_bottom - inst->bbox_top
const int tdt = (dx > dy)?  dx/cos(dir) : dy*sin(dir);
  if (tdt < td)
    td = tdt;
You are trying to do the exact same thing as I did with this code:

Code (EDL) Select Expand

        if (angle_difference(point_direction(other.bbox_right, other.bbox_top, bbox_left, bbox_bottom), angle) > 0)
        {
          dist = min(dist, (other.bbox_top - bbox_bottom - 1)/sin(degtorad(angle)));
        }
        else
        {
          dist = min(dist, (bbox_left - other.bbox_right - 1)/cos(degtorad(angle)));
        }
I do not think what you used works though, I believe you have to check the angle against the dir in order to determine the correct colliding side with the instance.

I think the method I have used is actually the same method as the one in your head, but I don't see how you can work it without checking the angles.

EDIT 2: Let me make an image, it might be easier to explain:
http://img403.imageshack.us/img403/5790/bboxmovement.png

The red arrows represent two different directions the object could move in from the same position, each direction will result in a different side being collided yet dx, dy are exactly the same. Can you see why I decided to check the angle then instead?

You can't easily check for 'solid objects that collide with box from the two furthest points' when only using one reference point on the bbox. I have wrote it instead using two reference points on the bbox (at opposite ends) then you can easily check objects that will collide via the angles. Here is working code in gml:

Code (EDL) Select Expand

//move_contact_bbox(angle, distance, object)
var angle, dist;
angle = argument0;  dist = argument1;

with (argument2)
{
  if (bbox_right >= other.bbox_left && bbox_bottom >= other.bbox_top && bbox_left <= other.bbox_right && bbox_top <= other.bbox_bottom)
  {
    dist = 0;
    break;
  }

  switch (wrap(angle, 360) div 90)
  {
    case 0:
      if ((bbox_left > other.bbox_right || other.bbox_top > bbox_bottom) &&
      angle_difference(point_direction(other.bbox_right, other.bbox_bottom, bbox_left, bbox_top), angle) >= 0  &&
      angle_difference(point_direction(other.bbox_left, other.bbox_top, bbox_right, bbox_bottom), angle) <= 0)
      {
        if (angle_difference(point_direction(other.bbox_right, other.bbox_top, bbox_left, bbox_bottom), angle) > 0)
        {
          dist = min(dist, (other.bbox_top - bbox_bottom - 1)/sin(degtorad(angle)));
        }
        else
        {
          dist = min(dist, (bbox_left - other.bbox_right - 1)/cos(degtorad(angle)));
        }
      }
    break;

    case 1:
      if ((other.bbox_left > bbox_right || other.bbox_top > bbox_bottom) &&
      angle_difference(point_direction(other.bbox_left, other.bbox_bottom, bbox_right, bbox_top), angle) <= 0  &&
      angle_difference(point_direction(other.bbox_right, other.bbox_top, bbox_left, bbox_bottom), angle) >= 0)
      {
        if (angle_difference(point_direction(other.bbox_left, other.bbox_top, bbox_right, bbox_bottom), angle) > 0)
        {
          dist = min(dist, (bbox_right - other.bbox_left + 1)/cos(degtorad(angle)));
        }
        else
        {
          dist = min(dist, (other.bbox_top - bbox_bottom - 1)/sin(degtorad(angle)));
        }
      }
    break;

    case 2:
      if ((other.bbox_left > bbox_right || bbox_top > other.bbox_bottom) &&
      angle_difference(point_direction(other.bbox_right, other.bbox_bottom, bbox_left, bbox_top), angle) <= 0  &&
      angle_difference(point_direction(other.bbox_left, other.bbox_top, bbox_right, bbox_bottom), angle) >= 0)
      {
        if (angle_difference(point_direction(other.bbox_left, other.bbox_bottom, bbox_right, bbox_top), angle) > 0)
        {
          dist = min(dist, (other.bbox_bottom - bbox_top + 1)/sin(degtorad(angle)));
        }
        else
        {
          dist = min(dist, (bbox_right - other.bbox_left + 1)/cos(degtorad(angle)));
        }
      }
    break;

    case 3:
      if ((bbox_left > other.bbox_right || bbox_top > other.bbox_bottom) &&
      angle_difference(point_direction(other.bbox_right, other.bbox_top, bbox_left, bbox_bottom), angle) <= 0  &&
      angle_difference(point_direction(other.bbox_left, other.bbox_bottom, bbox_right, bbox_top), angle) >= 0)
      {
        if (angle_difference(point_direction(other.bbox_right, other.bbox_bottom, bbox_left, bbox_top), angle) > 0)
        {
          dist = min(dist, (bbox_left - other.bbox_right - 1)/cos(degtorad(angle)));
        }
        else
        {
          dist = min(dist, (other.bbox_bottom - bbox_top + 1)/sin(degtorad(angle)));
        }
      }
    break;
  }
}

x += cos(degtorad(angle))*dist;  y -= sin(degtorad(angle))*dist;
Here is the example file I was working with if anyone wants to check that it works:
http://www.box.net/shared/popdzld7rp (GM8 gmk)

Press M to move_contact, press Space to change the movement direction, Press R to move the instance back to it's starting position.

I will attempt a write of it in C++ at some point.