GMLscripts.com

Depends. If you're calculating a series of points on one curve, you can precalculate some important stuff and use a different equation to save time.

Pseudocode, off the top of my head:

a = P3 - 3(P2 - P1) - P0
b = 3(P2 - 2P1 + P0)
c = 3(P1 - P0)

And then for any t on the the cubic curve B:

B(t) = ((a*t + b)*t + c)*t + P0

You should be able to confirm a, b, and c by multiplying out the equation you have above and then regrouping by powers of t instead of by point #.

But I've got something even better. This script will work for an arbitrary number of points (just specify the right degree) and works on pure add/sub/mult/div. A cubic call takes 0.02 milliseconds.

Expand/*
scr_bezier_point();

0 degree
1 t
n point
*/

var a, i, n, t, t1;

a = argument2;
i = 1;
n = 1;
t = 1;
t1 = 1-argument1;

repeat argument0 {
    n *= (argument0-i+1) / i;
    t *= argument1;
    a *= t1;
    a += argument[i+2] * n * t;
    i += 1;
    }
    
return a;

Bezier curves are crazy stuff. I came up with some equations for bezier-to-circle collision detection in April, and then this semester I wrote a paper on them to get credit for a calculus class. Booyah.

I recently ran into the FlatRedBall and Ice Cream XNA engines. And then there's Aziel. I'm kinda tempted to just jump ship on GM and move to an XNA engine if I want to do anything more graphically intensive than a Mario clone. Or possibly Torque2D/TorqueX.

I noticed that "problem" too with triangles, but I think it's meant to do that, so that shapes will all mesh correctly. Otherwise, if you drew 2 triangles/rectangles that share a side and give them an alpha value, there would be one line between them that gets drawn over twice, which would look pretty wack. And then people would be even more confused.

Mmm, I disagree, but the effect is hard to pin down exactly. If a sprite has an alpha channel, and it gets drawn onto a surface that already has an image on it, the result should be a mix, right? But I've had problems in the past with the image underneath the sprite getting erased completely and replaced by the sprite, as if the blend mode was (bm_one,bm_zero) instead of bm_normal. Can't test the problem anymore, though, because everything's borked no matter what mode I use. I'd like to think it was my DX drivers, but in that case it should affect everything, unless GM uses an outdated blend mode method (GM6/7 is based on DX8, I recall) that no other programs use and has been corrupted in DX11, which I find unlikely.

My bad. I meant (bm_one,bm_one), and forgot that blend modes start at index 1, not 0.

That's correct. It's the idea from here: http://www.messy-mind.net/2007/2d-metaballs/

No, the alpha isn't changing . The colors themselves get multiplied by the alpha value (where alpha != 1), though, which is what makes the image I posted a funky mix of black and red.

Interesting. I've actually never encountered the problem in your Test 1 or, for that matter, ever had any problems with leftover data on my surfaces. Maybe Vista/Dx10 fixed the problem?

At any rate, I'm afraid the script doesn't help. It's a problem that appeared specifically when I moved from Vista to 7. But thanks for the attempt, xot - I think I have a better idea what the problem is now. You know how drawing to a surface with bm_normal sometimes overwrites the alpha channel of the area underneath? Now it's as if, when I use draw_set_blend_mode_ext(1,1), it fails just like bm_normal does. However, it seems like draw_set_blend_mode_ext(1,5) is working just fine, which makes me think it's something like the surface's alpha level is being overwritten regardless of what blend mode is used. [Edit:] I'm using (1,5) in a variation of GearGOD's metaball effect, which multiplies a surface by itself 3 or 4 times . . . now that I think about it, it seems the alpha channel is also being ignored for this mode too, but it's harder to tell because the surface's alpha channel is just getting replaced by the alpha of a copy of itself - in other words, the alpha isn't changed at all, which in itself supports the hypothesis below. If it were working properly, the new alpha would be A1*A1/255.

Essentially, the blend mode is applied as normal to the RGB of the surface but not the A, and the blend mode for the alpha channel is always (bm_one,bm_zero), or something close.

Probably the standard bm_normal+surface bug and my bug are related.

Ah, intriguing idea. I'll need to fiddle with this some more . . . seems like it should mesh with my AA engine pretty well.

Oi, sorry. I'd attempted to reformat the code to more closely match the standards; apparently I also borked some things in the process.

The whole with() section is an even worse drag on the script (30% to 40% slower) than I thought it would be, having edited it without retesting.  It either needs to be forced in the creation code for colliding objects or replaced with something better. The code you posted isn't very accurate if the origin isn't centered. However, it gave me the idea you see below - a *fraction* slower now closer to your code, and slightly faster now back to "slightly slower" (because I fail at variable referencing) than the point_distance(x0,y0,t.x,t.y)+t.sprite_radius by itself (surprisingly), but it doesn't require an instance variable and is much, much faster than the with() section.

And some things that don't seem to help speed things up at all, for reasons I can only attribute to GM's own idiosyncratic execution speeds:
- Setting precise collision checking to 0 for both collision_line()s
- Restricting the line to only collide with the last found target after a certain time - the if/else check countered any increase.

Expand{
    var x0, y0, lx, ly, d, t, t2, res;
    x0 = argument0;
    y0 = argument1;
    d = argument2;
    lx = lengthdir_x(1,argument3);
    ly = lengthdir_y(1,argument3);
    t2 = -4;

    res = argument7;
    if (res <= 0) res = 1;

    t = collision_line(x0,y0,x0+lx*d,y0+ly*d,argument4,argument5,argument6);

    if t {
        var x1, y1, td;
        d =  point_distance(x0,y0,mean(t.bbox_left,t.bbox_right),mean(t.bbox_top,t.bbox_bottom))+t.sprite_width+t.sprite_height;
        x1 = x0;
        y1 = y0;
        td = 0;
        
        while (d>res) {
            d *= 0.5;
            x1 += lx*d;
            y1 += ly*d;

            t = collision_line(x0,y0,x1,y1,argument4,argument5,argument6);

            if t {
                x1 = x0;
                y1 = y0;
                t2 = t;
            }
            else {
                x0 = x1;
                y0 = y1;
                td += d;
            } 
        }

        cx = x1+lx*res*0.5;
        cy = y1+ly*res*0.5;
        cd = td;
    }
    else {
        cx = argument0 + lx*d;
        cy = argument1 + ly*d;
        cd = d;
    }

    return t2;
}

[Edit:] switched out some code (faster now), split variable assignments