Legacy GM [UNSOLVED] Texture pointers and DLLs

[Binsk]

Hello, everyone.

As far as I can tell, GameMaker uses 'actual' pointers in two cases:
1. Buffer addresses
2. Textures

Now generally when I want to pass a lot of data to a DLL I'll store it in a buffer, get the address, and pass that address in. I can then easily open it up as an array and get / modify the data from there.

Now I've come across a case where it would be mighty convenient if I could pass surfaces into a DLL. As you may or may not know, there is no direct way to do this. The method I had been using was to copy the surface data into a buffer and pass the buffer. This would be fine if I didn't have to do it every step but since I need to constantly update it it kills the framerate.

I recently discovered that textures in GameMaker, aka. the *_get_texture functions, are pointers. Buffers are easy to use in DLLs because we already know what data they will contain (we have to define it in GameMaker). However I haven't the slightest idea as to what data type the texture pointers point to.

Is there anyone out there that would know what this data type would be and whether or not it would actually be usable inside a DLL?

Any help on this would be great, thanks. There isn't exactly any info about this in the manual.

 

[Binsk]

Thanks for the quick reply, Lonewolf.

Although that would be mighty convenient, it doesn't seem the case. I have created a 48x48 sprite that is completely white.
Passing the texture into a DLL and reading down the array as signed chars returns odd results. The first 24 values are as follows:
2, 0, 2, 0, 48, 0, 48, 0, 0, 0, 0, 0, 48, 0, 48, 0, 48, 0, 48, 0, 1, 0, 0, 0

I'm guessing it is not a base datatype, but I'll keep playing around.
If anyone else has any / any more insight that would be fantastic.

 

[BlueHarrier]

Hello, I know I'm almost 6 years late, but I just spent 3 hours trying to identify each value, and except for the last one, I've discovered every single one of them. They're not chars, they're uint8, but after further study, they turned out to be in couples, so they're uint16, in your case this sequence: 2, 2, 48, 48, 0, 0, 48, 48, 48, 48, 1, 0.

The structure looks like this:
1 - X origin of the optimised* sprite in the texture in pixels
2 - Y origin of the optimised* sprite in the texture in pixels
3 - Width of the optimised* sprite in the texture in pixels
4 - Height of the optimised* sprite in the texture in pixels
5 - Inverse horizontal offset of the sprite in the textures in pixels (from right to left instead of left to right)
6 - Vertical offset of the sprite in the texture in pixels
7 - Width of the sprite in world units
8 - Height of the sprite in world units
9 - Original width of the sprite
10 - Original height of the sprite
11 - Texture ID in the render engine
12 - I couldn't manage to find a pattern here, but seems to be related to how the sprites are place in the texture
* When textures are optimized, the transparent pixels that create the sides are removed in order to save some space in the atlas.

The most useful thing you may use from here is the Texture ID (11).