To be able to draw things at different layers, as if the object was at that layer. As it is, to have one thing under and another bit of the object on top of a middle one (like a sprite in a ship), we have to make two separate objects for the ship, and what if a game needs to do a lot of this, it'll double the instance count.
Something like:
draw_set_depth(-3)
// or
draw_set_depth(depth)
I completely agree, that would make layering so much easier
It's been mentioned in other topics that this is not only extremely difficult to do, but virtually impossible. The way drawing works, everything is drawn to the current buffer (i.e. the screen or currently-set surface) as soon as the drawing code is executed. Tell me, then, how you'd handle drawing something like this:
draw_set_depth(0);
draw_text(10,10,"One");
draw_set_depth(5);
draw_text(10,10,"Two");
You can't; by the time "Two" is told to be drawn, "One" is already in the buffer. There's only two ways to get around this: the first is to essentially create a new drawing surface each time the depth is changed, and draw to the correct surface, then sort the surfaces by depth and draw them in order to the buffer. I imagine that'd be quite a memory hog. The second way is for GM to pre-process all code, looking for drawing functions, and then prioritize the drawing functions by draw depth before executing anything. And that would be incredibly difficult to do, as well as incredibly slow.
So that option is an almost irrefutable "no" and is 100% not a small change.
Another note (unrelated to the above): for those who want clamp(), you do realize that clamp(val,min,max) = median(val, min, max), right?
Anyway...my feature request, which I have no idea how difficult it would be to implement: something along the lines of surface_set_alpha_from_surface(). This would be like sprite_set_alpha_from_sprite(), only with surfaces; currently the only option when this is needed is to create a temporary sprite from the surface, call sprite_set_alpha_from_sprite, draw it to the surface, then delete the temp sprite. It's pretty processor-intensive and quite slow to do, especially considering that the sprite_set_alpha_from_sprite() is slow to begin with. There shouldn't be a need to add to that by forcing us to create resources only to delete them immediately after transfer to a surface.
Like I said, I don't know if that would be difficult, but would it not just be basically copypasta from the sprite-based function with some relatively minor modifications?
-IMP