177 replies to this topic

[mechanikos]

A single API call can update GM data without the need to translate information.

Are you sure about that? A dll can change GM data from within the dll, without the dll ending and returning?

As I recall, such schemes has been discussed before, and rejected as being inherently destabilizing to GM.

I don't know though, I'd like to hear discussion about this.

[X-tra Fear]

To be honest, I think icuurd12b42 just pointed out some of the best reasons to use this library.



As for what you said, mechanikos, I'm really not sure.

[icuurd12b42]

A single API call can update GM data without the need to translate information.

Are you sure about that? A dll can change GM data from within the dll, without the dll ending and returning?

With this it can, before that you could not unless you know something I don't.

As I recall, such schemes has been discussed before, and rejected as being inherently destabilizing to GM.

I don't know though, I'd like to hear discussion about this.

The only destabilizing factore I can see is if GM7.2 comes out... You'd have to calculate a new offset for the functions lookup.

[X-tra Fear]

Oh, I think I forgot to say... you don't need to define an export in the newer version.
You can just put "export" behind any function, and your good to go after you include GMaker.h.

The only destabilizing factore I can see is if GM7.2 comes out... You'd have to calculate a new offset for the functions lookup.

Yeah, only thing I can see too.

Edited by X-tra Fear, 26 February 2009 - 01:40 AM.

[uuf6429]

That's easy though...we don't expect GM 7.2 (or whatever) any time soon. Plus, GM versions can be counted on one hand.

[WadeMcGillis]

To be honest, I think icuurd12b42 just pointed out some of the best reasons to use this library.

Another "best reason": You can now make a game more decompiler proof. Just put GML into the DLL and no one would be able to really know what code is being executed.

That's easy though...we don't expect GM 7.2 (or whatever) any time soon. Plus, GM versions can be counted on one hand.

HOW MANY FINGERS DO YOU HAVE?!?!?!?

[Marchal_Mig12]

I am trying to figure out whats the benefit of calling GM's functions through a dll but I can't. Could anyone tell me what results I can get from this?

Thanks,

Miguel

EDIT: Now I understand. Could it be possible to move an object in game maker's through the dll without getting this object's position from the dll and then updating the position?

Edited by Marchal_Mig12, 27 February 2009 - 06:01 AM.

[icuurd12b42]

EDIT: Now I understand. Could it be possible to move an object in game maker's through the dll without getting this object's position from the dll and then updating the position?

That would be the next BIG trick!!

[TheMagicNumber]

@Marchal_Mig12:
The benefit should only exist when using direct GML functions only. You can call functions directly without having to have the code interpreted then called. It should give some speed.

There is a massive difference between the functions and variables. Someone could try to use execute_string but they may say it's a bit slower. But have people forgot of the actual functions for this? The only issue I can think of is the local variables, they are object specific and need to be called from the object. It may be possible if it's called from the object.

variable_global_get(name)
variable_global_set(name, value)
variable_local_get(name)
variable_local_set(name, value)
etc.

[Marchal_Mig12]

EDIT: Now I understand. Could it be possible to move an object in game maker's through the dll without getting this object's position from the dll and then updating the position?

That would be the next BIG trick!!

That would! I guess it cant? What if I call move_bounce_all() function through the dll? Is the object going to bounce?

[icuurd12b42]

@Marchal_Mig12:
The benefit should only exist when using direct GML functions only. You can call functions directly without having to have the code interpreted then called. It should give some speed.

There is a massive difference between the functions and variables. Someone could try to use execute_string but they may say it's a bit slower. But have people forgot of the actual functions for this? The only issue I can think of is the local variables, they are object specific and need to be called from the object. It may be possible if it's called from the object.

variable_global_get(name)
variable_global_set(name, value)
variable_local_get(name)
variable_local_set(name, value)
etc.

Hmm. if that works then we are half way there...

[Marchal_Mig12]

GMPhysics could be improved alot using this new knowledge! Every DLL should use this feature if needed.

[X-tra Fear]

When I get home, I'll look at the structure of the sprites to allow us to load the sprites with DLLs, or sounds.

Maybe even look into the object structure, maybe get something out of that.

<maybe>
been working on a lot of things at the same time, so it may be awhile...

Edited by X-tra Fear, 28 February 2009 - 02:45 PM.

[icuurd12b42]

I just finished adding d3d_model_ generation in my GMModelEx.dll Thank you! The GMmodelFix application is now super fast... No more lag while editing... You can morph you models live now win gmmodelex.dll!

I am adding ds_list_add in GMFModSimple.dll to pass along Spectrum and Wave data... Finally going to be able to use this data live in a game!

Thank you and score_under!!

[TheMagicNumber]

A tip for anybody who will use this to call functions directly, it shouldn't benefit if you call a few functions, use it to replace a script or something as the DLL calling is still slow.

[icuurd12b42]

A tip for anybody who will use this to call functions directly, it shouldn't benefit if you call a few functions, use it to replace a script or something as the DLL calling is still slow.

Yes, a single API call is slower than a single function call in gm so make sure the code you move to the dll does a lot of stuff. Then you will reap the benifits.


here's an example that loops though a buffer array to fill a list

export double FMODSnapShotToDsList(double startpos, double size, double ds)
{
	if(size <1) {{FMODASSERT(FMOD_ERR_INVALID_PARAM);}}
	if(size >1024) {{FMODASSERT(FMOD_ERR_INVALID_PARAM);}}
	if(startpos <0) {{FMODASSERT(FMOD_ERR_INVALID_PARAM);}}
	if(startpos >=1024) {{FMODASSERT(FMOD_ERR_INVALID_PARAM);}}

	int endpos = (int)min(startpos+size,1024);
	int i = 0;
	float minv,maxv;

	minv = 9999;
	maxv = -9999;
	for (i=(int)startpos;i<endpos;i++)
	{
		//samplebuffer[i] = (float)i/size;
		minv = min(minv,samplebuffer[i]);
		maxv = max(maxv,samplebuffer[i]);
		ds_list_add(ds,samplebuffer[i]);
	}	
	return (double)(maxv-minv);   

}

The list is populated by an ealier function

GM

l = ds_list_create();
	FMODInstanceGetWaveSnapshot(instance,0,1024)
	FMODSnapShotToDsList(0,1024,l)
	i = 0
	repeat(1024)
	{
		value = ds_list_find_value(l,i);
		i+=1
	}

Here is an example of d3d model generation

d3d_model_primitive_begin(gmmodel,4);
			numpointssaved = 0;
			for (int i=start; i< end; i++)
			{
				if(numpointssaved>=nextsplit)
				{
					//write_line("1 0 0 0 0 0 0 0 0 0 0\r\n",f);
					//write_line("0 4 0 0 0 0 0 0 0 0 0\r\n",f);
					d3d_model_primitive_end(gmmodel);
					d3d_model_primitive_begin(gmmodel,4);
					nextsplit+=900;
				}
				fp1 = FACEPOINT(facepoints,i);
				//code x y x nx ny nz u v col alpha
				d3d_model_vertex_normal_texture(gmmodel, fp1->v.x+dx, fp1->v.y+dy, fp1->v.z+dz,
					fp1->vn.x, fp1->vn.y, fp1->vn.z,
					fp1->uv.x, fp1->uv.y);

				numpointssaved++;

			}
			d3d_model_primitive_end(gmmodel);

Edited by icuurd12b42, 28 February 2009 - 04:53 AM.

[uuf6429]

HOW MANY FINGERS DO YOU HAVE?!?!?!?

GM5.3a, 6.0, 6.1 and 7.0 => 4. It's enough for a 5 finger mammalian hand, no?

[PickleMan]

Nice. The only problem is: Why the hell would someone be using GM functions in C++ if they could eaisly make a faster version in C++, and why not just switch completely to C++?

Stuff like this is kinda distorting the original intention of GM. "...You can make a game without any code!..." "...Its aimed at beginners..."

If want to have a jello 3d model... you can't morph the points fast enough. So you move that code in a dll

If you want to fiddle a grid, average them to emulate wind... Again, move the code to a dll...

If you want to quick draw a surface biit by bit, morphing it so it looks like watter... Again GML is too slow... Move the code to a dll.

If you want to pass a laerge amout of data back and forth, a ds_list or map is the only way to go... You need to acces GM's data structure in the dll to do that.

If you don't see the use of this it's your lack of imagination. I've been needing this in the first GM dll I ever made. It's so obvious we need this from day 1.

This open up the possibility for GM addons that are 1000 times more powerful than a freaking dll with APIs passing a limited number of doubles and strings. A single API call can update GM data without the need to translate information... Like (right now) calling a API 3000 time to get 1000 x,y,z points...

I understand the uses, but don't you think that this is kind of defeating the point of Game Maker? Its a cool library, though.

[X-tra Fear]

I understand the uses, but don't you think that this is kind of defeating the point of Game Maker? Its a cool library, though.

Not really. ;P

[WadeMcGillis]

GM5.3a, 6.0, 6.1 and 7.0 => 4. It's enough for a 5 finger mammalian hand, no?

I believe there were many versions before 5.3a