move_towards_point

[Josh @ Dreamland]

A motion_set that's five lines in GML isn't really worth porting. Those kinds of functions are more like blueprints or suggestions than code. It doesn't help me if you just take advantage of ENIGMA's scoping system to do things that are a pain in the ass in plain, general C++.

Though, with the new instance system, they're now much easier to produce.

[MrGriggs]

I would've thought writing code in GML for functions would add to the compile time, though. Or does it only need to be coverted once?

[RetroX]

GML functions are slower in nature because they use var.  But compared to the speed of GM, it's already loads faster anyways.

Besides, if you code something in GML, post it here, and someone will likely be able to convert it to C++ for you.

[MrGriggs]

Slow how? Takes more processing during run time? I thought the code was parsed straight to C++ at compile anyways? Or do you mean because of GML not being definitive in its types that it takes more memory?

So my initial thought was right anyways, that it's best to write the functions within C++ with the instance interator for Josh so that it doesn't have to be parsed during compile?

[RetroX]

Well, basic integers are handled quickly by the processor.  var has to check, at every calculation, what variable type is being used and how to handle it.  It's not a huge notice, but if you take an entire project and convert it from var to primitive types, you'll see a relatively decent increase in speed.

Post made January 27, 2011, 03:45:59 pm was deleted at the author's request.

[Josh @ Dreamland]

with (obj) direction=dir, speed=spd; isn't worth porting, considering the corresponding C++ is completely different.

[MrGriggs]

Well, basic integers are handled quickly by the processor.  var has to check, at every calculation, what variable type is being used and how to handle it.  It's not a huge notice, but if you take an entire project and convert it from var to primitive types, you'll see a relatively decent increase in speed.

Will defining our types before using them increase the speed at all, for example

int varname
string strname

so on and so forth.

To get the boost will we also have to include the variable type in the if statements and other such checks when referncing the varname
?

[TheExDeus]

Will defining our types before using them increase the speed at all, for example

Of course. The biggest speed increase is in for cycles like

Code: [Select]

for (int i=0; i<10000000; i++){}will work A LOT faster than

Code: [Select]

for (i=0; i<10000000; i++){}

To get the boost will we also have to include the variable type in the if statements and other such checks when referncing the varname
?

No, in c++ you have to set the type only when declaring them. When used in if checks and so on the type doesn't need to be set again. Unless you want to cast them as another type, like:

Code: [Select]

double d=1.23;
int i=1;
if ((int)d == i){}Dunno if ENIGMA allows this right now, but I also never really saw the reason to do that (unless in coding in c++ where functions can take only certain types of varaibles).

[MrGriggs]

Yeah, I know how C++ works, I just didn't know if the way ENIGMA compiled it would cause me to have to do this, thanks for clearing that up

[Josh @ Dreamland]

Indeed. I've managed to make variant work as fast as double, but double is still slower than int. Granted, they are hundreds (int thousands) of times faster than Game Maker, but best practice is to declare them. local int varname; will take care of all your woes.

You can stick a cast anywhere in an expression you like in ENIGMA. Just like ++, or !. Casts are just another unary operator.

[MrGriggs]

But the .gmk that declares the data types won't work with GM as well wil it? As GM does not allow type casting...

[Josh @ Dreamland]

Correct. Game Maker will complain, hence, ENIGMA is backwards-compatible.

[MrGriggs]

LOL, ahhhhhhh. Great!