Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

[GMS1 bug; workaround] leaky arrays?

A topic by kuncendorfs created May 07, 2021 Views: 345 Replies: 6
Viewing posts 1 to 5
(2 edits)

Hello.

I'm on GMS14.

If I run this in VM everything appears to work fine, but, when compiled with YYC, program appears to leak memory on every received array.

Am I doing something wrong?

edit: I'm using fixed .dll that is not bound to debug runtime.

<object0.create>

state = lua_state_create();

lua_add_file(state, "test.lua");

lua_call(state,"fill");

<object0.draw>

var in = lua_global_get(state,"out");

<test.lua>

out = {}

function fill( )

    for offs=1, 5000 do

        out[offs] = math.random(0,255)

    end

end

Developer

What version is this on? Doesn’t seem to leak on 1.4.1804 YYC

(3 edits)

Latest version - 1.4.9999 r45042 stand alone (not Steam)

The same thing seem to happen with strings also but not with numbers.

edit: strings work fine with older version of asset: Apollo.gmez

edit2: same problem with dll from 'Apollo-GMS1.gmez' that needs debug runtime

edit3: this appears to fix the issue: in 'lua_global_get' replace

return lua_buffer_read(b);

with

var tmp = lua_buffer_read(b);

return tmp;


some GMS internal black magic I guess

Developer

GMS 1.4.9999 can be buggier than 1.4.1804 in some regards. Would have to check if there are any other spots that do return a_script()

Thank you!

I want to nag you some more about this extension, though.

- My understanding is that values are passed through LUA API and it adds type identifier to each value which then can be parsed on the other side. I couldn't get array numerical entries get identified other than '4' - float64. I tried math.floor() and & 0xff and just passing zeroes. But it was always f64. That's quite a bit of overhead. Is this API's doing? Or is there something I'm missing that can be done in Lua?

- So currently when array is received each value has to be filtered. I thought a neat thing to have would be a function in dll that would strip meta and just pass raw bufferlike data to GMS so it could be flipped to surface with 'buffer_set_surface' or dumped to a file with 'buffer_save' without further burden of processing in GML.

Developer
  1. The extension uses lua_type to identify how a Lua value has to be written. lua_tonumber returns a double. lua_tointeger also returns a 8-byte int64. I wouldn’t worry too much about f64 being used since every GML value (YYRValue in YYGML.h) is going to be 16 bytes anyway.

  2. The extension works on premise that returning values from Lua should not generate data structures that will have to be manually cleaned up (meaning that failing to do so at every single call site would allow for leaking memory). I think the only way to support this would be to create a lightuserdata that wraps a buffer data pointer to fill up from Lua.

(1 edit)

Ah ok, thank you!

edit: Strings did it for me. I did a little Mandelbrot zooming performance test and the best results were from GML(YYC)+Lua drawing with buffer_set_surface, which was about 7% faster than drawing with draw_point_colour and 25% faster than buffer_set_surface all in GML(YYC) without Lua. Uncompiled GML+Lua was ~400% faster than pure uncompiled GML