Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - YellowAfterlife

Pages: 1
1
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.

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

3
While that method is more efficient and fast, it already causes troubles with implementation, and will cause a lot more problems once the 'pixel-perfect' collisions will be implemented (if they ever will be).

4
Code: [Select]
// Median functions @ mathhnc.cpp ; mathhnc.h
double median(double x)           { return x; }
double median(double x,double y)  { return fmin(x,y); }
double median(double x,double y,double z) { return x > y ? x > z ? y > z ? y : z : x : y > z ? x > z ? x : z : y; }
double median(double w,double x,double y,double z) { return w > x ? w > y ? w > z ? median(x,y,z) : median(w,x,y) : y > z ? median(w,x,z) : median(w,x,y) : x > y ? x > z ? median(w,y,z) : median(w,x,y) : y > z ? median(w,x,z) : median(w,x,y) }
// { D&D functions @ actions.h
#define itype enigma::object_planar* const
#define ithis ((enigma::object_planar*)enigma::instance_event_iterator->inst)
// Gravity action. Tested; works
inline void action_set_gravity(double d, double g) {
itype me = ithis;
if (argument_relative) {
me->gravity += g;
me->gravity_direction += d;
} else {
me->gravity = g;
me->gravity_direction = d;
}
}
// Move Contact Solid action. Concept, might not work as intended for <1 values
inline void action_move_contact(double d, double m, int o) {
itype me = ithis;
double pr = 1; // precision
double dx = lengthdir_x(pr, d);
double dy = lengthdir_y(pr, d);
for (int i = m; i > 0; i -= (m != -1 ? 1 : 0))
{
if (!(o > 0 ? place_free(me->x+dx, me->y+dy) : place_empty(me->x+dx, me->y+dy))) return;
me->x += dx;
me->y += dy;
}
}
// }
As mentioned, action_move_contact might not work exactly like in GM, but its clearly better than nothing.

Pages: 1