![\"Smile\"](\"http:\/\/shadowcovenant.com\/blog\/wp-content\/uploads\/2012\/12\/wlEmoticon-smile.png\")
<\/p>\nThis is one of those posts that have a bit of everything, so no decent title for it\u2026 <\/p>\n
Anyway, as you might have seen in the Spellcaster Studios blog<\/a>, me and Rincewind gave up on the Indie Speed Run, mainly because of scope issues\u2026 We went a little wild with it, Rincewind because of lack of 48-hour compo experience, and me because I thought that without needing to do graphics I could do much more\u2026<\/p>\n Anyway, it was a good exercise, and I\u2019m definitely finishing this one, not because it is brilliant, but it\u2019s great to figure out bugs on SurgeEd and SurgePlayer, which I used for the game. Already figured out some nasty bugs which would have taken a lot of time to fix on the \u201cGrey\u201d scripts, specially one that only seems to manifest in specific conditions\u2026<\/p>\n If you\u2019ve been following this blog, you know I\u2019m using Lua<\/a> to drive the game logic, and specifically LuaJIT<\/a>, and I found an odd behavior\u2026<\/p>\n The offending piece of code was something that tested a condition and acted on that:<\/p>\n function do_something(param) test is a function declared on the FFI, that returned a bool:<\/p>\n ffi = require("ffi") bool test(const char* str);<\/p> ]]<\/p><\/pre>\n Which had a C counterpart like:<\/p>\n return b; Simple enough\u2026<\/p>\n Problem is, \u201cchange_object\u201d was never reached\u2026 First I thought it was the \u201cdo_some_test\u201d function that was failing, and I added some tracing to it (writing to the logger) with the output, and it turned true eventually\u2026<\/p>\n Then I added some tracing in the \u201cdo_something\u201d function, and mysteriously, it started working properly\u2026 After a lot of tests, I found that if I used any function that called normally bound functions before the \u201cffi.C.test\u201d call, the system worked properly\u2026 But if I added FFI based functions, it wouldn\u2019t work!<\/p>\n This was driving me crazy\u2026 then I had a silly idea\u2026 \u201cbool\u201d is a C++ type, not C type, so I changed the declaration of the C function (not the FFI declaration) to \u201cint __declspec(dllexport) test(const char* str)<\/font>\u201d, returning 1 if \u201cdo_some_test\u201d was true, and 0 otherwise\u2026 And now the system worked properly!<\/p>\n So, I arrived to the conclusion that you can\u2019t output \u201cbool\u201d directly from the C code (although you can declare it that way on the FFI declaration, to get a proper bool and not an int). I imagine the problem was the size of a bool and the stack manipulation of LuaJIT, which caused the system to access corrupted memory (that was probably zeroed before being used, and that\u2019s why the function apparentely always returned \u201cfalse\u201d, although the C output was \u201ctrue\u201d).<\/p>\n Anyway, 2 hours of my life getting to the bottom of this\u2026 Had to change all the functions that return a bool to return an int instead\u2026<\/p>\n Anyway, on other news, take a look at this Hamnasya<\/a> game\u2026 It\u2019s a cross-media kind of game, where you\u2019re reading a book, but you can affect the outcome and fight battles \u00e0 l\u00e1 RPG\u2026 <\/em>Very cool stuff indeed, and has an excellent trailer:<\/p>\n
if (ffi.C.test(param)) then
change_object() end\nend<\/p><\/pre>\n
ffi.cdef[[<\/p>extern "C"
{ bool __declspec(dllexport) test(const char* str)\n { <\/pre>\n bool b=do_some_test();<\/pre>\n
}
}<\/p>
<\/p><\/blockquote><\/pre>\n\n