177 replies to this topic

[X-tra Fear]

The Download link is down.

WHFF is having problems, so it should be back up soon... maybe days, but soon.

In the meantime, it would be great if someone could provide a mirror.

[icuurd12b42]

Create an account with host-a.net
or
http://www.windowslive.com

Free and stable

[X-tra Fear]

There, got it back up!

It's now hosted on my website, that isn't much of a site.
But it's up almost 100% of the time.

[icuurd12b42]

You can add GMFMODSimple.dll you your user list

[X-tra Fear]

You can add GMFMODSimple.dll you your user list

Done.

[paul23]

Well I spent some time looking into the the internal workings (I hope to learn C++ some day, and what's better than looking at code?) - But I'm wondering, isn't there a pretty obvious memory leak?
One of the constructors for GMVariable is:

GMVariable::GMVariable(char* a)
{
	char* n;
	n = (char*) malloc(strlen(a) + 5);
	*((unsigned int*)n) = strlen(a);
	strcpy(n + 4, a);
	type = 1;
	real = 0;
	string = n + 4;
	padding = 0;
}

It calls "malloc" to allocate memory, from the heap.. However I never see any "destructor"/"free" command.. - Shouldn't that be there somewhere? (I doubt free(string-4) would actually work?)

[icuurd12b42]

Well I spent some time looking into the the internal workings (I hope to learn C++ some day, and what's better than looking at code?) - But I'm wondering, isn't there a pretty obvious memory leak?
One of the constructors for GMVariable is:

GMVariable::GMVariable(char* a)
{
	char* n;
	n = (char*) malloc(strlen(a) + 5);
	*((unsigned int*)n) = strlen(a);
	strcpy(n + 4, a);
	type = 1;
	real = 0;
	string = n + 4;
	padding = 0;
}

It calls "malloc" to allocate memory, from the heap.. However I never see any "destructor"/"free" command.. - Shouldn't that be there somewhere? (I doubt free(string-4) would actually work?)

Yes, a few posts above, I mentioned he needs to add a destructor to free that. and yes, free (string-4) will work

Edited by icuurd12b42, 10 April 2009 - 09:46 AM.

[008008]

The download link still does not work....

[icuurd12b42]

The download link still does not work....

Download GMaker.zip

[X-tra Fear]

The download link still does not work....

Download GMaker.zip

Yeah, just fixed it. :/ Don't know why it screws up so much.

[icuurd12b42]

The download link still does not work....

Download GMaker.zip

Yeah, just fixed it. :/ Don't know why it screws up so much.

host-a.net and Microsoft sky drive are pretty good.

My zip also has the MSVC GameMaker.cpp BTW

[Wireless]

The best place to host is google pages, fast and unlimited host space

anyway, just a quick question. If you gonna make a dll that could use resources from GM, sprites etc. is it possible to use this library to get that to work?

[paul23]

What I can't stop wondering is wether there isn't any possibility to reduce the ammount of typing you have to do.. Currently for every function you have to type 6-7 more or less the same lines.. Wouldn't it be possible to have a macro do the loading for you - or use template functions?


Ow and -maybe a stupid question- but can you actually read/write GM (build in) variables in some way? (and not through functions/scripts)

Great library, I keep finding more and more uses for it!

[PickleMan]

The best place to host is google pages, fast and unlimited host space

No.

anyway, just a quick question. If you gonna make a dll that could use resources from GM, sprites etc. is it possible to use this library to get that to work?

Yes.

Edited by PickleMan, 13 April 2009 - 08:09 PM.

[yahn]

I've been looking through this topic a lot, but I have not actually peeked at the source (due to the Internet on my developing machine not working). Can this DLL, in fact, call any function available within GM? Is there anything in particular that does not work?

This seems too good to be true. I'm working on a project that I think could really benefit from this. A couple things that I'm particularly interested in that don't necessarily pertain to this DLL, but, relative to setting a variable in GM, how much slower would it be to call variable_local_set() from inside the DLL? I'm wondering because I would like to do this extensively. I could update everything pertaining to my DLL in a single call rather than have thousands of instances make a call from GM to update themselves. Would this be beneficial?

Edited by yahn, 13 April 2009 - 09:48 PM.

[PickleMan]

I've been looking through this topic a lot, but I have not actually peeked at the source (due to the Internet on my developing machine not working). Can this DLL, in fact, call any function available within GM? Is there anything in particular that does not work?

This seems too good to be true. I'm working on a project that I think could really benefit from this. A couple things that I'm particularly interested in that don't necessarily pertain to this DLL, but, relative to setting a variable in GM, how much slower would it be to call variable_local_set() from inside the DLL? I'm wondering because I would like to do this extensively. I could update everything pertaining to my DLL in a single call rather than have thousands of instances make a call from GM to update themselves. Would this be beneficial?

It can call any. It works by finding the function in memory, similar to that of calling a dll.

[halo shg]

Could this result in a breach of security? I mean, by knowing the DLL being used in an executable, and knowing it's calls, one could make a phony DLL that disguised functions actually steal the scripts and graphics, no? Game Maker was always poorly coded.

Otherwise, this seems like a good library.

[Yourself]

Game Maker was always poorly coded.

No it wasn't, you don't know what you're talking about.

[PickleMan]

It just has a couple of security vulnerabilities if the user lets it.

Its this dll that has the problems (with security)

[icuurd12b42]

What I can't stop wondering is wether there isn't any possibility to reduce the ammount of typing you have to do.. Currently for every function you have to type 6-7 more or less the same lines.. Wouldn't it be possible to have a macro do the loading for you - or use template functions?


Ow and -maybe a stupid question- but can you actually read/write GM (build in) variables in some way? (and not through functions/scripts)

Great library, I keep finding more and more uses for it!

It's only 6 lines, in its shortest possible form
GMPROC *pdraw_set_alpha = (GMPROC*) GetProcAddress("draw_set_alpha");
GMVariable draw_set_alpha(GMVariable a)
{
GMVariable args[] = { a };
return ExternalCall(pdraw_set_alpha, 1, 1, args);
}

I'm not sure if a macro or any templating feature would allow a single line definition that would do it all. How about you, gm member Yourself, any ideas?
Not sure the setup is optimal for speed either. I would trade number of line and ease of setup over speed myself. Though from what I gather calling a GM Function is not as fast as using a pure c/c++ solution (eg: don't use ds_list, that's for sure), so any optimisation is possibly overkill.

I've been looking through this topic a lot, but I have not actually peeked at the source (due to the Internet on my developing machine not working). Can this DLL, in fact, call any function available within GM? Is there anything in particular that does not work?

This seems too good to be true. I'm working on a project that I think could really benefit from this. A couple things that I'm particularly interested in that don't necessarily pertain to this DLL, but, relative to setting a variable in GM, how much slower would it be to call variable_local_set() from inside the DLL? I'm wondering because I would like to do this extensively. I could update everything pertaining to my DLL in a single call rather than have thousands of instances make a call from GM to update themselves. Would this be beneficial?

It's not a DLL, it is code you add to your DLL. I tried setting a local variable using this feature. It did not work. The context of the call is lost while in the dll it seems. Even if it did work, it would be too costly <assumption>, almost as costly as calling variable_local_set from GML. You can benchmark x = x vs variable_lical_set("x",variable_local_get("x")) and mesure the speed difference in GM. c++ or GML, the speed difference should give you an idea. It would be best to mirror the gm variables in a structure or a class in your dll if at all possible. You set everything once when the instance gets created that the dll will need to access. You can place all your data in a c/c++ list of structures and update all of the instance in one dll call. At that point, you may not even need GM instances either.

Could this result in a breach of security? I mean, by knowing the DLL being used in an executable, and knowing it's calls, one could make a phony DLL that disguised functions actually steal the scripts and graphics, no? Game Maker was always poorly coded.

Otherwise, this seems like a good library.

As the writer of a dll that uses the lib code, only you can place in malicious code to achieve this feat. No one can place himself between your DLL and GM to steal stuff (unless someone made a virus and tacked it to GM or your dll or the users's exe)... If you use a dll that someone wrote with malicious intent such as creating as a back door for other purpose... At that point I would worry more about what the dll does than it stealing my resources which I can do with print screen or any screen capture or sound capture software.

In any case the dll has to be trusted not to do bad things by the user of the dll. As the creator of a dll, you must provide trusted code. I include my source code in all my dlls for people to verify or even compile themselves. A dll can be a dangerous thing no matter what. Heck GML can be a dangerous thing. That's just the way it is.

It just has a couple of security vulnerabilities if the user lets it.

Its this dll that has the problems (with security)

I guess you meant "It's the dll that uses the lib that is the potential/intentional security risk".... Meaning the DLL creator/distributor that is the dangerous factor.

Edited by icuurd12b42, 14 April 2009 - 03:15 AM.