DirectX 9 Implemented and Working! <Functions Can Now Be Written>

[Goombert]

Ahem, but can we release our games as closed source without breaking the GLP?

You will have to ask Josh about that.

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.

[TheExDeus]

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.

[Josh @ Dreamland]

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.

[The 11th plague of Egypt]

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.

Sorry about that.


My best bet would be the MPL license.
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

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. 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

[Josh @ Dreamland]

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.

[The 11th plague of Egypt]

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.

[Goombert]

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.

[The 11th plague of Egypt]

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!!!

[polygone]

http://files.enigma-dev.org/game/27/file/1/39a1c7/Source/Tetris.gmk

[YellowAfterlife]

lolololol, polyfag I just figured out why it aint working, draw_set_color(c_white); the default drawing color is black



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.

[time-killer-games]

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!

[TheExDeus]

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 and here. 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.

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.

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.

[YellowAfterlife]

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 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.

[TheExDeus]

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.