Pages: 1 2 [3]
  Print  
Author Topic: DirectX 9 Implemented and Working! <Functions Can Now Be Written>  (Read 8776 times)
Offline (Unknown gender) YellowAfterlife
Reply #30 Posted on: November 02, 2013, 09:43:09 PM

Member
Joined: Apr 2011
Posts: 4

View Profile
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.
« Last Edit: November 02, 2013, 09:44:41 PM by YellowAfterlife » Logged
Offline (Male) time-killer-games
Reply #31 Posted on: November 03, 2013, 09:27:44 AM

Member
Location: Virginia Beach
Joined: Jan 2013
Posts: 1067

View Profile WWW Email
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!
Logged
Offline (Unknown gender) TheExDeus
Reply #32 Posted on: November 03, 2013, 10:07:14 AM

Developer
Joined: Apr 2008
Posts: 1886

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

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.
Logged
Offline (Unknown gender) YellowAfterlife
Reply #33 Posted on: November 06, 2013, 10:31:38 PM

Member
Joined: Apr 2011
Posts: 4

View Profile
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.
Logged
Offline (Unknown gender) TheExDeus
Reply #34 Posted on: November 07, 2013, 12:54:44 PM

Developer
Joined: Apr 2008
Posts: 1886

View Profile
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.
« Last Edit: November 07, 2013, 01:00:42 PM by TheExDeus » Logged
Offline (Male) Goombert
Reply #35 Posted on: November 17, 2013, 07:05:30 PM

Contributor
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 2988

View Profile

Just to update on this again, Direct3D9 now runs my Project Mario game as well, though very slowly.
Logged
Welcome to ENIGMO, the game engine built by fucking aliens.

Pages: 1 2 [3]
  Print