ENIGMA Forums

General fluff => Announcements => Topic started by: Goombert on July 28, 2013, 05:33:28 pm

Title: DirectX 9 Implemented and Working! <Functions Can Now Be Written>
Post by: Goombert on July 28, 2013, 05:33:28 pm
After trying this several times with DirectX 10 and failing, I decided to give DX one more chance to be a part of our game engine, and it finally worked with DX9. The headers and libraries are distributed with MingW for DX9 so no need to install the Windows or DirectX SDK, if you are on Windows you will simply be able to switch it under API settings and use it. Now of course not all functions have been implemented, the implementation status is listed below. This will increase the compatibility of ENIGMA on native Windows platforms and for those people Micro$hit likes to screw over with bad OpenGL support.

So we are now looking particularly for Windows users to help implement the graphics functions for DirectX. There's a lot of functions to be done, varying in difficulty so people from all skill-levels should be able to help. I am going to be writing a ton of the code as well, your help is going to be appreciated.

Currently Implemented:
 Sprites: Full support
 Backgrounds: Full support
 Models: Full support
 Primitives: Full support
 Tiles: No Support
 Fog: Experimental Support
 Transformations: Almost full support
 Projections: Full support
 Views: Experimental Support
 Curves: No support
 Standard Draw: Almost full support
 Lighting: Experimental Support
 Shaders: Limited or Buggy support
 Text and Font: Full support
 Particle Effects: No support
 Surfaces: Almost full support
 Texture: Limited or Buggy support
 Blend Modes and Color: Full support
 Vertex Formats: No support
Title: Re: DirectX 9 Implemented and Working! <Functions Can Now Be Written>
Post by: fervi on July 29, 2013, 03:21:00 pm
Yay

Now we need DX6, because I want to create games for Windows 98

Maximum trolling

Fervi
Title: Re: DirectX 9 Implemented and Working! <Functions Can Now Be Written>
Post by: forthevin on July 29, 2013, 05:03:00 pm
Very nice, having DirectX set up and working will make further development on it much easier. While it in principle ought to be enough to be able to use OpenGL, that may not be the best solution on Windows for a given game, and supporting DirectX will give them the choice of which graphics system to use. While it may be an extra burden, it can be expanded upon bit by bit, and with a future test suite over the graphics, all the tests that we write for the OpenGL graphics systems can be reused for DirectX, and vice versa, given that the interface for using the graphics system is the same between implementations.
Title: Re: DirectX 9 Implemented and Working! <Functions Can Now Be Written>
Post by: Josh @ Dreamland on July 30, 2013, 05:44:42 am
The intention is to keep the interfaces all but identical, forthevin. I believe it's in our best interest to encourage DirectX on Windows and OpenGL on Mac/Linux. The differences in behavior should be minimized, if not eliminated, to prevent any incidents with porting.

This will be necessary, anyway, for when we start "officially" supporting embedded systems.

Personally, though, I think DX9 Is a step in the wrong direction. Nothing written for it will be compatible with DX10 or 11.

DirectX11 would be my personal choice in target. It works on newer Windows service packs, and on the XBox One, which if anyone actually purchases, promises to support homebrew natively.
Moreover, DirectX11 has this (http://directxtk.codeplex.com/). It's an XNA-like layer over DirectX11. As far as I know, it's .NET free. So you could use its SpriteBatch class for a quick, efficient solution.

Note: All ENIGMA games which use DirectXTK will have to be closed-source due to intentional licensing conflicts by Microsoft.
Title: Re: DirectX 9 Implemented and Working! <Functions Can Now Be Written>
Post by: TheExDeus on July 30, 2013, 06:58:36 am
Well one reason why Rober chose DX9 is because MinGW already has it. I personally also don't want a requirement to install a 10GB sdk or something. Of course if the installation would be painless, then the problem wouldn't be that big.
Also, at least for now, we don't support anything that could use the new features. I personally don't have any use for DX anyway. OGL support is clearly good enough to even support FBO's on Intel Cards, so I don't have any problems with it. I would more gladly create an android port.
Title: Re: DirectX 9 Implemented and Working! <Functions Can Now Be Written>
Post by: Josh @ Dreamland on July 30, 2013, 07:06:48 am
Supposedly, thanks to the WINE team, it comes with DX10, too. There was just some difficulty using it, which isn't surprising.

Either way, if he's comfortable writing these functions for all of them, that's fine; the ones which are most used will naturally be the most maintained. I fear DX10 will basically never be used, but, que sera, sera.
Title: Re: DirectX 9 Implemented and Working! <Functions Can Now Be Written>
Post by: TheExDeus on July 30, 2013, 11:12:44 am
DX10 isn't really used in games either. It's always DX9 or DX11, never DX10. Probably because it didn't give that much useful features to substantiate the changes necessary to any big engine.
Title: Re: DirectX 9 Implemented and Working! <Functions Can Now Be Written>
Post by: Goombert on July 31, 2013, 02:08:41 am
Guys, hey I got the #1 reason we are going to use DX now, look at the updated screen shot, that is 50,000 draw_sprite calls at 30fps, OpenGL can't handle 15,000 on my pc at more than 12fps. That is utilizing DX's internal sprite batching class, please proceed with the DirectX vs. OpenGL debates. :P

Please merge pull request....
https://github.com/enigma-dev/enigma-dev/pull/283

Also to prove my point, this is the d3d blend modes and their OpenGL and Direct3D equivalents.
Code: [Select]
  bm_zero             =  1,  // GL_ZERO                  D3DBLEND_ZERO
  bm_one              =  2,  // GL_ONE                   D3DBLEND_ONE
  bm_src_color        =  3,  // GL_SRC_COLOR             D3DBLEND_SRCCOLOR    //only for dest
  bm_inv_src_color    =  4,  // GL_ONE_MINUS_SRC_COLOR   D3DBLEND_INVSRCCOLOR //only for dest
  bm_src_alpha        =  5,  // GL_SRC_ALPHA             D3DBLEND_SRCALPHA
  bm_inv_src_alpha    =  6,  // GL_ONE_MINUS_SRC_ALPHA   D3DBLEND_INVSRCALPHA
  bm_dest_alpha       =  7,  // GL_DST_ALPHA             D3DBLEND_DESTALPHA
  bm_inv_dest_alpha   =  8,  // GL_ONE_MINUS_DST_ALPHA   D3DBLEND_INVDESTALPHA
  bm_dest_color       =  9,  // GL_DST_COLOR             D3DBLEND_DESTCOLOR     //only for src
  bm_inv_dest_color   = 10,  // GL_ONE_MINUS_DST_COLOR   D3DBLEND_INVDESTCOLOR  //only for src
  bm_src_alpha_sat    = 11   // GL_SRC_ALPHA_SATURATE    D3DBLEND_SRCALPHASAT   //only for src

So like I said the graphics portion of Game Maker was designed around D3D, obviously because of the function naming as well, so this definitely will cut down on visual anomalies in games. I've also noticed the transform functions have the same behavior as one would expect in Game Maker.
Title: Re: DirectX 9 Implemented and Working! <Functions Can Now Be Written>
Post by: TheExDeus on July 31, 2013, 04:14:01 am
Quote
Guys, hey I got the #1 reason we are going to use DX now, look at the updated screen shot, that is 50,000 draw_sprite calls at 30fps, OpenGL can't handle 15,000 on my pc at more than 12fps. That is utilizing DX's internal sprite batching class, please proceed with the DirectX vs. OpenGL debates. :P
That is because we don't use any batching at all. But I do have a proposition for it here: http://enigma-dev.org/forums/index.php?topic=1380.0 (which no one seems to read). In managed to get 30FPS with 100k sprites. But it will probably be slower (or the same, maybe even faster, wtfk) in the final implementation. So I doubt that in proper implementation one is any faster than the other.

Quote
Also to prove my point, this is the d3d blend modes and their OpenGL and Direct3D equivalents.
No one ever doubted that GM was based on D3D.... because everyone know it's based on D3D.... even D3D functions have a prefix.. wait for it... D3D.

Quote
We already have GLES for other embedded systems
Sadly we don't. I would really want an android port, but the framework it requires (together with a shit ton of configuration for SDK/NDK) makes it all hard to do. Maybe I'll just try making GLES run on Windows (if that is even possible) and then try to make it work on another device.
Title: Re: DirectX 9 Implemented and Working! <Functions Can Now Be Written>
Post by: Josh @ Dreamland on July 31, 2013, 06:32:07 am
If you're getting 50,000 sprite draws at 30 fps, my guess is that you have the batching on at full power. What I mean is, try drawing an arm sprite, then drawing a torso sprite over that, then drawing another arm sprite over that. You'll probably be disappointed.
Title: Re: DirectX 9 Implemented and Working! <Functions Can Now Be Written>
Post by: Goombert on July 31, 2013, 07:22:40 am
Me and Josh did a few test cases and the sprite batch does properly organize depths, and in fact transformations can be applied to the sprites/backgrounds/text to turn them into 3D billboards like many people do in Game Maker.
Title: Re: DirectX 9 Implemented and Working! <Functions Can Now Be Written>
Post by: TheExDeus on July 31, 2013, 10:37:24 am
When I try to launch dx9 I get: Graphics_Systems/Direct3D9/Direct3D9Headers.h:25:19: fatal error: d3dx9.h: No such file or directory
I searched the mingw folder I found d3d9.h, but not d3dx9.h. Which MinGW do you use?

edit:
Quote
turn them into 3D billboards like many people do in Game Maker
And why can't you do this now in OGL? Do you mean just using d3d_transform functions to rotate sprites?
Title: Re: DirectX 9 Implemented and Working! <Functions Can Now Be Written>
Post by: Goombert on July 31, 2013, 05:34:14 pm
I am using the zip installer which comes with MinGW64 Harri, if that is the case, first try to install the DX runtime, then try to install the DX SDK and see which of those fixes it, but do it in that order, as I'd rather have people download the runtime than the SDK.

d3d9.h contains most of the rendering headers
d3dx9.h contains math functions, vector classes, and matrix transformation stuffs

There is also a lib for both of those which is linked, -ld3d9 and -ld3dx9

Quote
And why can't you do this now in OGL? Do you mean just using d3d_transform functions to rotate sprites?
No I was just ensuring everyone that the behavior has not been lost with this new sprite batching class.
Title: Re: DirectX 9 Implemented and Working! <Functions Can Now Be Written>
Post by: slojanko on August 01, 2013, 07:30:35 pm
This looks epic  :D :D :D :D :D :D :D :D :D :D :D :D :D
Title: Re: DirectX 9 Implemented and Working! <Functions Can Now Be Written>
Post by: The 11th plague of Egypt on August 05, 2013, 08:14:57 am
Note: All ENIGMA games which use DirectXTK will have to be closed-source due to intentional licensing conflicts by Microsoft.
Ahem, but can we release our games as closed source without breaking the GLP?

Seems like this topic shows up a lot recently... Any news?
Title: Re: DirectX 9 Implemented and Working! <Functions Can Now Be Written>
Post by: Goombert on August 05, 2013, 08:33:28 am
Quote
Ahem, but can we release our games as closed source without breaking the GLP?
You will have to ask Josh about that.
Quote
Seems like this topic shows up a lot recently... Any news?
I almost got texture binding fixed on models, I am working out a few kinks right now. I don't update this topic other than to update the status of implemented features in the original post.
Title: Re: DirectX 9 Implemented and Working! <Functions Can Now Be Written>
Post by: TheExDeus on August 05, 2013, 10:00:49 am
Quote
I don't update this topic other than to update the status of implemented features in the original post.
With "this topic" I think he meant licensing. I don't get why he posted here though.
Title: Re: DirectX 9 Implemented and Working! <Functions Can Now Be Written>
Post by: Josh @ Dreamland on August 06, 2013, 11:20:33 am
The people I contacted about licensing haven't responded. I'm basically giving up on them doing so; I figure I'll ask forthevin to email the people he was talking about earlier. The softwarefreedom people apparently aren't interested. :P
Title: Re: DirectX 9 Implemented and Working! <Functions Can Now Be Written>
Post by: The 11th plague of Egypt on August 07, 2013, 06:31:27 am
The people I contacted about licensing haven't responded. I'm basically giving up on them doing so; I figure I'll ask forthevin to email the people he was talking about earlier. The softwarefreedom people apparently aren't interested. :P
Sorry about that.


My best bet would be the MPL license (http://"https://www.mozilla.org/MPL/2.0/").
It's similar to the LGPL, but it works by file.

A file that's under the MPL stays under the MPL (modifications of it must be MPL).

A file can link to or include a file that's MPL, without becoming MPL.

If file uses copy-pasted code from a MPL file, it becomes MPL.

So, as long as you keep the user files separed from the Enigma files, you're good to go.

A quote from the FAQ (http://"https://www.mozilla.org/MPL/2.0/FAQ.html")
Quote
Broadly speaking, the scope of the MPL, LGPL, and GPL can be summarized this way:

MPL: The copyleft applies to any files containing MPLed code.
LGPL: The copyleft applies to any library based on LGPLed code.
GPL: The copyleft applies to all software based on GPLed code.

Here's an article by the FSF (http://"https://www.fsf.org/blogs/licensing/mpl-2.0-release"). It talks about compatibility.
The MPL explicitly allows relicensing under the GPL and LGPL.
You can go from MPL to GPL (or to the LGPL), without any problem.
You can't go from the GPL to the MPL, however, without a permit
from the other developers to relicense the code.

Good luck with the legalese. It's not that terrible, btw (Y)
Title: Re: DirectX 9 Implemented and Working! <Functions Can Now Be Written>
Post by: Josh @ Dreamland on August 07, 2013, 10:32:58 am
That'd give us the same problems we're facing now; we want people to be able to link, but not from a fork project that stole our engine and revamped it with proprietary code we can't use. The license needs to be tailored to only allow linking to it legitimately. We want to allow linking general-purpose libraries, but not libraries specifically written to improve a semi-proprietary fork of ENIGMA.
Title: Re: DirectX 9 Implemented and Working! <Functions Can Now Be Written>
Post by: The 11th plague of Egypt on August 08, 2013, 03:42:38 am
That'd give us the same problems we're facing now; we want people to be able to link, but not from a fork project that stole our engine and revamped it with proprietary code we can't use. The license needs to be tailored to only allow linking to it legitimately. We want to allow linking general-purpose libraries, but not libraries specifically written to improve a semi-proprietary fork of ENIGMA.
That would require lots of engineering, as well as licensing.
Like, keeping user code and engine core separed at all times. Before during and after compilation.
Even small things like including header files means merging code to some extent, and that's why the LGPL exists.
Title: Re: DirectX 9 Implemented and Working! <Functions Can Now Be Written>
Post by: Goombert on August 08, 2013, 05:17:45 am
Just want to update everyone we are not only utilizing DirectX for graphics but for input, audio, and other systems/extensions as well to provide maximum native utilization of Windows API's for the platform.
Title: Re: DirectX 9 Implemented and Working! <Functions Can Now Be Written>
Post by: The 11th plague of Egypt on August 08, 2013, 07:33:03 am
Just want to update everyone we are not only utilizing DirectX for graphics but for input, audio, and other systems/extensions as well to provide maximum native utilization of Windows API's for the platform.
As long as you wrap these native APIs so I can use a single codebase for Windows and Linux, fine.
Otherwise OMG stop!!! :o
Title: Re: DirectX 9 Implemented and Working! <Functions Can Now Be Written>
Post by: polygone on October 29, 2013, 06:14:36 am
http://files.enigma-dev.org/game/27/file/1/39a1c7/Source/Tetris.gmk
Title: Re: DirectX 9 Implemented and Working! <Functions Can Now Be Written>
Post by: YellowAfterlife on November 02, 2013, 09:43:09 pm
lolololol, polyfag I just figured out why it aint working, draw_set_color(c_white); the default drawing color is black

(http://oi40.tinypic.com/30wmcd4.jpg)

I don't know what I should do about that.
Default color being black is GameMaker behaviour. You could change it (which would totally make sense by the way), at a price of that small part of behaviour.
Also, if you're aiming for GameMaker compatibility, draw_set_color should not influence blending of sprites - it only applies to text and primitives in GM. draw_set_alpha was made to apply to sprites in GameMaker: Studio, but that does more evil than good (in terms of introduced possibility to turn half of your sprites invisible with a forgotten alpha reset).

Reading through forums, pretty cool additions lately. I would expect userbase to grow faster from here, with stability approaching amusing ranges.

Edit: also, do not ask about how I got a posting gap of two years here.
Title: Re: DirectX 9 Implemented and Working! <Functions Can Now Be Written>
Post by: time-killer-games on November 03, 2013, 09:27:44 am
Thanks for letting the developers know I'm sure they appreciate it. Also I strongly believe if you scrapped Tululoo Html5 game maker and migrated a lot of it's code into something that could be impliumented into I ENIGMA that would be in your best interest. ENIGMA already has all the same features as GM8.1 (except the obj_add and the other dynamic functions that no one uses).

Thanks to that we have features that GMStudio might not ever support such as Wavefront OBJ importing, Video playback, CD functiuons, etc. And if you ask me GMStudio's Ubuntu module is useless compared to ENIGMA because ENIGMA games are supported by pretty much all Linux platforms where as studio is limited to just Ubuntu.

Anyway the point I'm getting at here is if you help Robert and Josh make a Html5 export that would make enigma a lot more popular than it is right now and your Tululoo community would migrate over here and if you ask me I think you'd receive a lot more donations than you do right now since Tululoo exports strickly Html5 and no native application support.

Just something to consider, if you don't want to scrap Tululoo I understand I have no problem with that after all you've been working on it for almost two years now so I can understand why you'd be hesitant. :-)  one last thing, perhaps you could at least give Josh/Robert/ISM some coding tips on a html5 export or a peek or two at your tululoo code to help us out? If you don't feel comfortable with that either I totally understand,.

Sorry for being such a jerk at GameJolt BTW...
cheers!
Title: Re: DirectX 9 Implemented and Working! <Functions Can Now Be Written>
Post by: TheExDeus on November 03, 2013, 10:07:14 am
Quote
Default color being black is GameMaker behaviour. You could change it (which would totally make sense by the way), at a price of that small part of behaviour.
Not necessarily small. This is partly discussed here (http://enigma-dev.org/forums/index.php?topic=1576.0) and here (http://enigma-dev.org/forums/index.php?topic=1375). If we change the default color to white, then things like text will break and so on. So while it's possible, I am still not sure which will be better.

Quote
Also, if you're aiming for GameMaker compatibility, draw_set_color should not influence blending of sprites - it only applies to text and primitives in GM
We know that. That is the current behavior.

Quote
draw_set_alpha was made to apply to sprites in GameMaker: Studio, but that does more evil than good (in terms of introduced possibility to turn half of your sprites invisible with a forgotten alpha reset).
This at least is a lot less likely to break compatibility, as the default alpha is 1. So 90% of the stuff should work with this change (probably the reason they did it). We could probably do that as well. The problem with color blend and alpha blend not influencing sprites and backgrounds is that we need to use _ext to draw them blended. The _ext has scaling and rotation too, which means if you just want to draw 0.5 alpha sprite, you suddenly have to use a function which has cosine and sine + other calculations which are not needed. I had an urge to add a lot more drawing functions just because of this (like draw_sprite_color), but I didn't.

So we need to decide how we are going to do this (which is why I made the topics). Of course for compatibility we should have this as an option as well. We have all these compatibility options though, which gets cumbersome. Maybe we need a "Simple" and "Advanced" - so "Simple" would just have a compatibility options where you choose the GM version you want to be compatible with - and "Advanced" would allow you to choose more detailed.
Title: Re: DirectX 9 Implemented and Working! <Functions Can Now Be Written>
Post by: YellowAfterlife on November 06, 2013, 10:31:38 pm
Thanks for letting the developers know I'm sure they appreciate it. Also I strongly believe if you scrapped Tululoo Html5 game maker and migrated a lot of it's code into something that could be impliumented into I ENIGMA that would be in your best interest. ENIGMA already has all the same features as GM8.1 (except the obj_add and the other dynamic functions that no one uses).

Thanks to that we have features that GMStudio might not ever support such as Wavefront OBJ importing, Video playback, CD functiuons, etc. And if you ask me GMStudio's Ubuntu module is useless compared to ENIGMA because ENIGMA games are supported by pretty much all Linux platforms where as studio is limited to just Ubuntu.

Anyway the point I'm getting at here is if you help Robert and Josh make a Html5 export that would make enigma a lot more popular than it is right now and your Tululoo community would migrate over here and if you ask me I think you'd receive a lot more donations than you do right now since Tululoo exports strickly Html5 and no native application support.

Just something to consider, if you don't want to scrap Tululoo I understand I have no problem with that after all you've been working on it for almost two years now so I can understand why you'd be hesitant. :-)  one last thing, perhaps you could at least give Josh/Robert/ISM some coding tips on a html5 export or a peek or two at your tululoo code to help us out? If you don't feel comfortable with that either I totally understand,.

Sorry for being such a jerk at GameJolt BTW...
cheers!
Things aren't so simple, actually.

While code written in Tululoo looks like GML, it isn't GML. It's JavaScript. And, to tell you something, JavaScript isn't quite GML-ish. Variable scope can be a horror (problems related to this exist in Tululoo), and multiple code structures work very differently. As result, a fair bit of code preprocessing is required to permit scripting in GML (you can take a look at code generated by GMS for reference).

While I would like to do a number of improvements to program (either polishing current JS version or porting it to Haxe), I currently don't have enough spare time for that. Aiming for a full-scale implementation of GM functionality would take even more time, since Tululoo only covers a small overlapping subset of functions that it needs.

Regarding code reference, whole JS framework code can be previewed easily in export.js file in program directory. There are even some comments for curious ones.

But really, a GML+»JS converter is needed before starting an HTML5 module. Otherwise things end up pretty awfully.

Also, regarding Studio, exported binaries aren't restricted to just Ubuntu. It's just that some repackaging is needed (Russel answered (http://gmc.yoyogames.com/index.php?showtopic=574288&page=2#entry4237895) this a few times, I recall).

... which means if you just want to draw 0.5 alpha sprite, you suddenly have to use a function which has cosine and sine + other calculations which are not needed.
I kind of loose you here. Sine and cosine... for what? Shouldn't the draw_sprite_ext still include the simplest check to cut off cases where image is drawn without certain effects? E.g.
Code: [Select]
if (xscale == 1 && yscale == 1 && angle == 0) {
    if (alpha < 1 || blend != 0xFFFFFF) {
        // blitting with alpha/color blending?
    } else {
        // draw_sprite behaviour
    }
} else {
    // transformed drawing
}
We have all these compatibility options though, which gets cumbersome. Maybe we need a "Simple" and "Advanced" - so "Simple" would just have a compatibility options where you choose the GM version you want to be compatible with - and "Advanced" would allow you to choose more detailed.
That's actually a very good idea. Maybe have an advanced mode, but also provide a set of buttons to easily switch settings to emulate behaviour of certain GameMaker version. Having these automatically matched up when importing a project of each format would be user-friendly too.
Title: Re: DirectX 9 Implemented and Working! <Functions Can Now Be Written>
Post by: TheExDeus on November 07, 2013, 12:54:44 pm
Quote
Shouldn't the draw_sprite_ext still include the simplest check to cut off cases where image is drawn without certain effects?
It does not. This is current implementation:
Code: [Select]
void draw_sprite_ext(int spr, int subimg, gs_scalar x, gs_scalar y, gs_scalar xscale, gs_scalar yscale, double rot, int blend, gs_scalar alpha)
{
    get_spritev(spr2d,spr);
    const int usi = subimg >= 0 ? (subimg % spr2d->subcount) : int(((enigma::object_graphics*)enigma::instance_event_iterator->inst)->image_index) % spr2d->subcount;
    texture_set(textureStructs[spr2d->texturearray[usi]]->gltex);

    rot *= M_PI/180;

    const gs_scalar w = spr2d->width*xscale, h = spr2d->height*yscale,
    tbx = spr2d->texbordxarray[usi], tby = spr2d->texbordyarray[usi],
    wsinrot = w*sin(rot), wcosrot = w*cos(rot);

    const gs_scalar ulcx = x - xscale * spr2d->xoffset * cos(rot) + yscale * spr2d->yoffset * cos(M_PI/2+rot),
    ulcy = y + xscale * spr2d->xoffset * sin(rot) - yscale * spr2d->yoffset * sin(M_PI/2+rot);
    const double mpr = 3*M_PI/2 + rot;
    const gs_scalar ulcx2 = ulcx + h * cos(mpr),
    ulcy2 = ulcy - h * sin(mpr);

    const gs_scalar r = __GETR(blend), g = __GETG(blend), b = __GETB(blend);
    const gs_scalar data[4*8] = {
         ulcx, ulcy, 0.0, 0.0, r, g, b, alpha,
         ulcx + wcosrot, ulcy - wsinrot, tbx, 0.0, r, g, b, alpha,
         ulcx2 + wcosrot, ulcy2 - wsinrot, tbx, tby, r, g, b, alpha,
         ulcx2, ulcy2, 0.0, tby, r, g, b, alpha
    };
    plane2D_rotated(data);
}
This is also the behavior of GM (at least in GM8, which is the last one I have). There it also didn't matter if you rotated and scaled the sprite or if you just drawed it like it is. It actually didn't even matter if you used draw_sprite or draw_sprite_ext, as all of the sprite drawing functions were basically just wrappers for draw_sprite_general. At least speed difference is negligible.
The reason for that though, I think was the fact it used DirectX8. In directx you draw a sprite with 1 line of code. And I think you could draw it scaled and rotated with the same line.
It's possible that when you are actually using these functions to draw rotated and scaled sprites, then the 3 if checks could potentially slow it down (if drawing hundreds and thousands of sprites). Anyway, the best would be to give the right tools for the right job. So in this case different functions for color blending and alpha.

edit: But I guess when we implement things like draw_sprite_color, then draw_sprite_ext could just short circuit to that or draw_sprite/draw_sprite_transformed. I think the speed difference wouldn't be that big.

edit2: I just noticed we do 2 cos(rot) and 2 sin(rot). Probably should change that.