Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

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.

  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.