Note that with precise that the instance could collide with the bbox of an object but then not actually collide with the object in precise when moving forward. You could keep checking to see if the instance moves past the object without colliding then do a further bbox check beyond that; however it's probably not common enough a scenario for that to be efficient.

Looking at your code I'm also confused what this part is doing in there:

Code Select Expand

    double current_dist = DMIN;
    {
        double next_x = x + mid_dist*cos_angle;
        double next_y = y - mid_dist*sin_angle;
        if (collide_inst_inst(object, solid_only, true, next_x, next_y) == NULL) {
            inst1->x = next_x;
            inst1->y = next_y;
            current_dist = mid_dist;
        }
    }
I don't think it should be there at all.

That segfault has been sorted, and it looks like the lighting works yay! I shall now come to you with all my problems
Ok I'll give you a break so you can get on with your particles. I do have another problem with a collision engine but I'll try and debug that a little myself first as I doubt it's specific to what you committed.

And nice one forthevin for sorting out the lighting! Been an annoying problem. I see it's handy having somebody who's actually used opengl lighting before as opposed to me trying to get it to work when I've never worked with opengl before.

I would love to test it right now but it appears that something is going horribly wrong, most like due to one of the recent commits by josh.
- to the irc I fly

You can macro it and add an option for it if you want it to be sorted.

The normals haven't been added to the basic shapes at all, but that is a different story. If you run this 3d example in ENIGMA and GM you will see the difference:
http://enigma-dev.org/edc/games.php?game=31

Here's a screenshot comparing (ENIGMA on the left, GM on the right):
http://i.imgur.com/HkpzC.png

You will see it with other examples as well on the EDC, it's like the normals aren't being used at all; even though the normals are being set manually in the d3d_model_vertex_normal functions used in the model drawing. I know the normal values in the games are right because they are working fine with GM and the model function calls are fine since everything is in the right position in ENIGMA.

OK I still can't test anything but it sounds like you have tested and sorted it out correctly. Don't be surprised though if in a weeks time you find something else wrong with it It seems to be the way with these functions.

By the way are you familiar with opengl much at all? I'm still looking for someone to try and sort the lighting out, I can't work out what's wrong with the normals and it's troublesome.

Hmm I'm not sure: I seem to remember if you check the x,y coordinates in the collision event with a solid in GM they will show that it has moved back before the event code happens? I can't check that myself right now.

Maybe GM calls a check before and after would this still make things work correctly?

I see in the function you used:

Code Select Expand

    inst1->x = inst1->xprevious;
    inst1->y = inst1->yprevious;
I wouldn't rely on those values, also I think you need to do a place meeting check before hand because have you tested using move_bounce in the step event as well as the collision event? I used instead at the start:

Code Select Expand

    if (place_meeting(inst1->x, inst1->y, object))
    {
        inst1->x -= inst1->hspeed;
        inst1->y -= inst1->vspeed;
    }
    else if (!place_meeting(inst1->x+inst1->hspeed, inst1->y+inst1->vspeed, object))
        return false;
I think you should be using the same.

OK, I tested out the generally collisions though and they seem to be working very splendidly

For anyone that wants working proof you can try this basic collision engine I used for testing:
http://enigma-dev.org/edc/games.php?game=36

Ok I deciding to try a few files out myself so this is unfortunately the part where I start to do your nut in forthevin

I did a quick test of move_bounce and it's not behaving exactly right. If you download this example game you will see:
http://enigma-dev.org/edc/games.php?game=35

Basically when you run into a wall it should just bounce you off which you will see happens using bbox or in GM but it stops you when using precise. Anyways don't ask me to try and debug it; writing that move_bounce function for bbox system did my head enough for one lifetime

How much testing have you done with the precise collisions? Have you tried running some game maker examples (like a plat-former with slopes) to see if it works the same in enigma as GM? Just to mention in the API settings it still says (Not Implemented) alongside precise.

Good luck with the particles they have been a long time unimplemented because everyone is too lazy to bother with them

[object]

forthevin: to note; the move_* functions etc should use the object parameter when checking collision_inst_inst not all. Also in the for loops you should increment by DMIN instead of 1.

ps are you ever possibly planning on using the enigma irc channel? It would be nice to know your future plans etc with regards to what you're going to be working on in enigma. Great to see someone actually doing precise collisions again though.

You have to be super stupid to do that. I've never seen a report of anybody doing that in GM and that's a pretty stupid user base.

I personally prefer the GM way of just putting the source directory as the working directory.

This.

It does useful on Windows, just need macro it for other platforms.

The implement works fine on Windows, obviously it needs to be catered to other operating systems but whatever that can be sorted but not being on other operating systems I'm not going to be doing that.